8 years, 6 months ago

The Language of Business

IT has spent a lot of time and money chasing the “language of business,” trying to nail it down, trying to find a way to communicate with those who don’t want to know about computers or software or even why you have both of those things in the first place.

You’ve seen how the IT community has launched wave after wave of propositions that mostly make no sense to business leaders. Standards bodies that form around notations, training sessions, the analyst houses make proclamations about their proclamation strategy — you have to say something.

But it is really a lot simpler than that in the final presentation. Its about time and money. You know, the thing that IT has used to try to learn the “language of business.”

8 years, 7 months ago

Cloud Computing requires Enterprise Architecture and TOGAF 9 can show the way

Enterprise Architecture is necessary regardless of changes to underlying technologies. If managed properly, Enterprise Architecture will iterate and adjust to the winds of change. Client/server, SOA, RFID, Cloud, and other technology developments should be considered as styles, but Enterprise Architecture is at the heart of change. Cloud computing should have little impact on Enterprise Architecture.

It is the role of the Enterprise Architecture team to:

· Investigate if any style is simply hype or whether it holds real business value

· Understand the benefits and risks of a specific style

· Communicate these to Business and IT

· Develop an adequate governance framework

· Align the “style” with business requirements

· Give guidance for sustainable innovation

If Cloud computing does not take Enterprise Architecture into consideration, it will result in “spaghetti clouds” (aligned with “spaghetti architectures”).

Cloud computing is often characterised by: virtualised computing resources, seemingly limitless capacity and scalability, dynamic provisioning, multi-tenancy, self-service and pay-for-use pricing. Enterprise Architecture can help to make the shift to cloud computing smooth.


For organisations focusing more on Technology Architecture, Cloud computing could be a “big hit”. But for businesses that want to successful adopt cloud computing in a way that aligns to their business strategy, Enterprise Architecture is imperative (refer to above diagram).

Cloud computing may be a fit when the core of internal Enterprise Architecture is mature. This means:

· As recommended in TOGAF. well defined and layered:

o Business Architecture

o Application Architecture

o Data Architecture

o Technology Architecture

· Well defined interoperability (ADM Guidelines and Techniques)

· Low level of security agreed (during the Architecture Vision)

· Web as a target

· Costs issues

· New products and services

Cloud computing may not be a fit when the core of internal Enterprise Architecture is immature. This means:

· Business, Application and Data architectures are tightly coupled

· Low level of interoperability defined

· High level of security required

· When applications have IPAs (Information Provider Applications) with only proprietary interfaces

· When solutions are legacy

Where there is could be a good fit, a TOGAF iteration should then be “Cloud Architecture aware”. The Enterprise Architecture team drives the programme and works collaboratively with both the business and the IT department.


In the Preliminary Phase we should consider the addition of a step related to the creation of a strategy for the consumption and management of cloud services (public/private clouds, semantic management, security, transactions). The governance framework also needs to include the processes, roles and responsibilities related to cloud services and operations. At this stage, we need to identify who in the business owns the cloud from both a user and service provider management perspective. New principles may be created referring to the Cloud when the organisation has a fairly mature Enterprise Architecture (maturity model) in order to fully take advantage of the Cloud.

During Phase A, you may use a Business Scenario where you would identify in a workshop what are the business problems, business Requirements and identify a potential business solution. Stakeholders in this workshop may come from Business and IT Operations, Procurement, PMO, Data Center, Development, COO/CIO/CTO. Interoperability will be an important element of the phase. The Enterprise Architecture team will collaborate with the business to understand and scope the needs; align them with the Strategic Enterprise Architecture (bringing to bear the existing technological capabilities that can satisfy those needs thereby promoting sharing, reusing or building new ones if needed). Given the relatively low barrier to entry, in the scenarios where the Business is not sure of the viability of their proposal, they could go straight to the Cloud instead of “experimenting” before solidifying their requirements. The result of this is that the business may embark on a path of no return. To avoid this, make sure that the Business Scenario is complete, only refer to business solutions without referring to any architecture style (as this will be discussed during Phase E) and signed off.

Start the architecture considering Phase B, C and D.

At that stage, it is be recommended that you consider a Cloud Reference Model. This is a description of the appropriate Cloud industry standards, the dimensions of the Cloud problem space, and the decisions and choices that apply to a Cloud computing for an organisation. A Cloud reference model, reference architecture and reference implementation approach is an accepted approach for planning and implementing Cloud computing. Different Cloud Reference Models can be considered such as those published by

· The Open Cloud Consortium

· The Cloud Security Alliance

· The Cloud Computing Reference Model (CC-RM) and Reference Architecture framework from AgilePath

· The Accenture Cloud Reference Model for Application Architecture with its 7-layers. Like the OSI Model for networks, this Cloud Model is layered to separate concerns and abstract details


There is also an on-going initiative by the Open Group to deliver a Cloud Reference Model.

The Security activities from TOGAF will have to be applied to all phases taking into account the company’s Security strategy. The TRM should be extended with cloud services.

In phase C: Data Architecture, Data integration, in particular may be an issue for cloud computing as it pushes information back into siloes, that IT may not have direct access to. It is also recommended to determine Data and privacy classification and to prioritise the risk criteria of what goes in the cloud and what stays on-premise.

During phase E and F there is a need to understand the Cloud resources which may exist or not. A new step will also be dedicated to identify candidates’ services in the Cloud.

Instead of now having to provide standardized ROI or cost-benefit analysis justifying the products that need to be bought or charge-backs that need to be agreed upon upfront for shared assets, the Business can provide operational expenditure outlines and may go out to the Cloud to source their requirements. No surprises with CapEx, decreased new product introduction training line item expenditures (many products are “standards “which means, lots of documentation and books available, e-learning, etc.), different charge-back agreements between Finance and Business Units (the organisation may have accesses to the service independently from his internal structure), in short, no need to conform to existing enterprise-wide Reference Architectures to meet individual project needs. In relation to this, the recent Open Group white paper “Building Return on Investment from Cloud Computing” is a valuable source of information.

During Phase G, activities may also include the relocation of:

· Business processes (Process-as-a-Service)

· Applications (Application-as-a-Service)

· Data (Information-as-a-Service and Database-as-a-Service)

· Technical services (Storage-as-a-Service and Infrastructure-as-a-Service).

· Security and operations implementation will have to be taken into consideration during the relocation. Security can also be considered as Security-as-a-Service.

The following diagram summarises the additional activities or concerns which should be considered in the ADM:


Below is a diagram which maps the various Cloud services to the TOGAF Metamodel.


The development and deployment teams would now be sourcing from and conforming to the Cloud API and services, without the Enterprise Architecture team becoming policeman, enforcing the reference architectures or corporate standards at various checkpoints (compliance and dispensation activities will remain for internal new systems). With overarching cross-project oversight not relevant anymore, each project would tend to work in its own Cloud development sandbox, party engendered by the partitioning paradigm of the Cloud itself.

Barring some exceptions, traditionally the Enterprise Architecture team has not been relevant to the Operation side of the organisation, but with the Cloud, even that seems to be disappearing. The Cloud providers will furnish the relevant tools for management and reporting and take away the onerous tasks of patch management, version upgrades, high availability, disaster recovery and the like.

New technologies styles are exciting, but using technology styles just for the sake of technology does not bring a real value. Technology use should be driven not by its “coolness factor”, but rather by business requirements and an underlying Enterprise Architecture such as TOGAF. Moving some applications to the Cloud can make some infrastructures go away, but badly designed solutions won’t be improved by relocating to the Cloud.

8 years, 7 months ago

Gaming, Visualization, Simulation and Optimization: A New Reality for Enterprise Architecture

  I think that the push for considering an alternative means to engage in EA is, indeed, already underway. In organizations who treat “people as strategy” (e.g., SEMCO, Whole Foods, HCL, Topcoder), wherein people are give broad self-directed control of creating and executing strategy in real time, the notion that one will “translate business vision […]

The post Gaming, Visualization, Simulation and Optimization: A New Reality for Enterprise Architecture appeared first on Philip Allega.

8 years, 7 months ago

Summary of the Business Architecture Working Group’s (BAWG) Nobel Prize Case Study

The Nobel Prize Case study workshop was conducted & presented at the Open Group Conference in Amsterdam (2010)The session was led by Harry Hendrickx – CTO at Hewlett Packard.It was an investigation into whether business architecture can be described using natural language rather than any form of modelling language that requires learned semantics (meaning).This post is my extract of the

8 years, 8 months ago

Adrian Grigoriu

Adrian Grigoriu’s Enterprise architecture framework definition. This is a extract of Adrian’s www.ebizq.net blog post "An Enterprise Architecture framework definition". It is a very enlightening post by Adrian at a time when it is (rightly or wrongly) quite fashionable to bemoan the use of frameworks. 

1. EA Process: the EA development process and Best Practices for:
EA team organization 

8 years, 8 months ago

The A-Z Guide to Being an Architect

"An A-Z Guide to Being an Architect" by Mark Bloodworth and Marc Holmes is a lighthearted article outlining a number of key attributes of architects. An extract is below. Is there any important attributes missing?
A is for Advocate
“I think you’ll find that you really don’t want to do it like that.”
See also: Abstraction, Agile, Acrobat, Availability, Analysis, Applications
B is for

8 years, 8 months ago

Highlights of Len Fehsken’s "Re-thinking Architecture

This link [http://is.gd/g55wp] is a very interesting read about the scope and nature of enterprise architecture that helps to clarify a very widely misunderstood (because it is still embryonic) discipline.

It was written by the Open Group’s Len Fehsken and is called "Re-thinking Architecture."

Highlights for me were:

"This discipline is young enough that the idea that we already have all the

8 years, 8 months ago

Gartner Symposium/ITxpo, 2010: Let’s Talk Enterprise Architecture

It’s Symposium season.  We actually began in South Africa at the end of August and in Brazil in September.  We continue this coming Sunday-Thursday in Orlando and then Cannes, France, Japan and Sydney, Australia, to conclude this years largest gathering of CIOs and IT leaders in the world.  For me, and my colleagues in enterprise […]

The post Gartner Symposium/ITxpo, 2010: Let’s Talk Enterprise Architecture appeared first on Philip Allega.

8 years, 8 months ago

IT Market Clock is Here: Enterprise Architects Get Ready, Get Set, Get to Work!

Enterprise architects use metadata repositories to indicate the enterprise state of the items stored within.  Gartner’s IT Market Clock plots the current state and predicted lifecycle of IT products or services within a marketplace.  Enterprise architects will benefit from communicating the lifecycle positioning on internally held assets versus the marketplace perspective, as well as be […]

The post IT Market Clock is Here: Enterprise Architects Get Ready, Get Set, Get to Work! appeared first on Philip Allega.

8 years, 8 months ago

The Rhetoric of “EA is Dead” is Dead: EA has Arrived at the Leadership Table

In Gartner’s recent report, IT Metrics: Office of the CIO Staffing Report, 2010 , we noted that: The top-ranked function employed or implemented within the OCIO (Office of the CIO) is enterprise architecture, with 76% of respondents reporting a full-time equivalent (FTE) response to this role So, why so much angst over whether EA is “dead”?  […]

The post The Rhetoric of “EA is Dead” is Dead: EA has Arrived at the Leadership Table appeared first on Philip Allega.