on Enterprise Architecture

I have been reading Andy Winskill’s blog on his suggested Elevator pitch for Enterprise Architecture - ‘Enterprise Architecture is about the identification and realisation of Competitive Advantage‘.

I think this is an excellent pitch that has the benefit of being concise and focused on the business language  of senior executives.

My own elevator pitch is ‘Enterprise Architecture is the bridge between strategy and execution‘.

To expand on this pitch, I usually point people towards the excellent ‘Enterprise Architecture as Strategy‘ book by Jeanne W Ross et al.

I also sometimes describe EA as a realisation of the System 4 (focusing on strategy/future/intelligence) in Stafford Beer’s Viable System Model.  Or as a combination of System 4 and System 3 (focusing on audit/control/governance).  This doesn’t work so well as an elevator pitch unfortunately as most people are not familiar with Stafford Beer’s work and will just give you a blank pitying look…

Today I returned to the Sparx Systems web site to see what was new and was pleased to discover that the Enterprise Architect tool can now be extended with a new MDG technology add on for the TOGAF 8 Architecture Development Method, in addition to the previous add on that was available for the Zachman Framework.

The Enterprise Architect tool is already a great tool and this add on is sure to be popular. TOGAF is increasingly mentioned as a desirable skill in job specifications for Enterprise Architects.

http://www.sparxsystems.com/products/mdg/tech/togaf/index.html

Of course, now that the Open Group has adopted the Archimate  Enterprise Architecture modelling language standard, the next add on I’d like to see is one for Archimate.

For a long time now I have been recommending that organisations use the TOGAF ADM as the basis for their Enterprise Architecture Development Process and best practices, and to also use Archimate as the basis for their Enterprise Architecture Framework and the metamodel of architecture elements that need to be developed.

Archimate presents a unified way of modelling enterprise architectures, integrating the architecture domains for Business Architecture, Information Architecture, Application Architecture and Infrastructure Architecture in a way that makes the models easy for decision makers to understand and read. Archimate also includes a big focus on Services within the various architecture domains, which supports the adoption of Service Oriented Architecture approach. See http://www.archimate.org/content/afbeeldingen/concepts.gif and http://www.archimate.org/content/afbeeldingen/archimate_example.gif.

I recommend the Archimate book. See http://tinyurl.com/69gx72

Anyway, the reason that I’m prompted to mention Archimate again is that good news today is that the Open Group has announced their intention to adopt ArchiMate as an independent standard for enterprise architecture modelling and analysis.

See http://tinyurl.com/5es67c

The combined use of TOGAF and Archimate is one step towards increasing the maturity of the EA discipline.

I predict that the next step in this EA maturity story will be the alignment of COBIT with Archimate and TOGAF.

There is a paper available to COBIT members that looks at the mapping from COBIT to TOGAF.

You know it makes sense!

In his latest post, Karthik Vijayakumar looks at the definition of Solution Architecture, see  http://blog.karthikvijayakumar.com/2007/11/solution-architecture-how-is-this.html .

My view is that a Solution Architecture includes the same views and disciplines as Enterprise Architecture, but with a different and much smaller scope, different context and focuses on a different time period.

Enterprise Architecture is concerned with the enterprise as a whole at a group or corporate level. This is a broad and shallow view and covers all programmes, projects, solutions in the organisation. Enterprise Architecture is primarily modelling the future (target state) architecture vision for the organisation, over the next 3 - 5 years. In terms of the Zachman Framework, and Enterprise Architecture model will focus mainly on the top two rows of cells.

Solution Architecture is typically only concerned with a single business solution, within a single business domain, being developed or aquired by a single software development project. This is a narrow and deep view.  In terms of the Zachman Framework, a Solution Architecture model will focus mainly on the bottom three rows of cells. A Solution Architecture addresses the immediate current business needs of a particular business area or business function.

Once the development project is closed and the Solution has been delivered into the live production environment, the Solution Architecture model is harvested by the Enterprise Architects (who take ownership of it) and used to update the current state enterprise architecture models. In this way the Current State Enterprise Architecture models are kept up to date.

Many organisations today are establishing an Enterprise Architecture (EA) business function.
However the knowledge about enterprise architecture concepts, framework and processes within many organisations is still quite limited and at a low level of maturity.
Very often there is a good understanding of the technology and infrastructure architecture domain and to a lesser extent an understanding of application architecture domain, but not a good understanding or experience of the Enterprise Architecture discipline as a whole.

The concept of Enterprise Architecture has evolved considerably from John Zachman’s original work in the 1980’s on his Framework for Information Systems Architecture.
The Zachman Framework has provided the basis for many more recent enterprise architecture frameworks and associated processes that are now available, but is not always the preferred or appropriate choice.

According to many surveys, the majority of organisations usually choose to create their own EA framework rather than adopt any existing one.
The reasons for this vary, from the requirement to support a service oriented architecture, object orientation and component based development viewpoints, to a simple desire to use a different terminology that is tailored to the concepts and ‘language’ used within the organisation.

I have created an Enterprise Architecture Wiki (http://iea.wikidot.com) to provide my clients and other organisations with a common reference for the main Enterprise Architecture concepts, frameworks, processes and best practices that can be used today to create a tailored Enterprise Architecture.

My approach is based primarily on my experience using various existing best practices for Enterprise Architecture including: Archimate, COBIT, TOGAF, FEAF, EBA, Zachman and Information First.

In association with this EA Wiki, I am also developing an EA Process using the Eclipse Process Framework (http://www.eclipse.org/epf/) .

Once I have developed the initial content, this EA Process will be published as a web site linked from the EA Wiki and be available for download.

What, I wonder is the definition of a ‘Capability’.

This word seems to have emerged recently as a new buzz word. Wherever I’ve seen it used, nobody ever seems to bother actually defining what it means or what it’s relationships are to other EA concepts. Where does ‘Capability’ fit in the EA meta model?

Examples that I’ve seen of a ‘Capability’ are indistinguishable from a Business Function or a Business Process (or an elementary business process or activity).

So is a ‘Capability’ some kind of business process that one is ‘capable of carrying out but don’t actually implement yet’?

Or is it trying to define an unknown unknown business process as Rumsfeld might say?

The nearest to a definition that I have found is at http://en.wikipedia.org/wiki/Capability_Management.

What do other enterprise architects define  a ‘Capability’ as?.

In his recent blog at http://4thresource.evernden.net/  Roger Evernden asks ‘would you change the Zachman Framework?’.

Recently Zachman and Locke have been doing great stuff to update the Zachman Framework themselves and it always sounds great at conferences, but it isn’t enough I think.

Their problem is that is it has been a good earner for them and since it is now their brand they can not be seen to change it too dramatically.

My general thinking is that an EA framework is multi dimensional (perhaps at least the 8 dimensions introduced in the book ‘ Information First’) and that the Zachman Framework presents one of many views that are useful.

I think the main issue is that many people find the language of ZF doesn’t match the names they use for deliverables in their own environment.

Also ZF is seen as too theoretical and formal, which puts many people off.

Many are looking for a quick win, keeping it simple, just good enough, just in time. However in real life the devil is in the detail and a more complex solution is needed.

The Zachman Framework talks about primitives and composites. The primitive information is what is classified in the Zachman cells. However most people produce complex composite deliverables as long documents whcih relate more to what Zachman calls the composites.

What needs to be changed I think is to add an orthogonal view of the Zachman Framework that just shows the composites. A mapping between composites and the deliverables promoted by Prince 2, OGC and other project management processes would be a good start.

I’ll post some of my other thoughts on the Zachman Framework later on.

Nick Malik from Inside Architecture says:
Enterprise Architecture is not about “building solutions right”

Enterprise Architecture is about “building the right solutions”

In the ideal world the EA team is a peer to the business areas and the IT department. It should report to the strategy & planning team or the CIO.
Most EA teams are seen as part of IT, and the business managers think that they are just there as jumped up technical design authorities.

I use a military analogy to communicate about EA. The EA team is the equivalent of the intelligence and planning teams. The politicians and generals are the bsiness users and business managers who need the intelligence group to provide intel, make decisions and plan the future target vision and guide the execution by the troops on the ground which are like the delivery project teams.
Building the solutions right is like using the best equipment and the best tactics.
Building the right solutions is like having the right strategy and being in the right place with the right equipment in order to actually win the war and beat the enemy.

Enterprise Architecture encompasses a number of Architecture Domains.

The four primary ones that everyone usually agrees on are the

• Process Architecture (also known as Business Architecture) ,

• Information Architecture,

• Application Architetcure,

• Technology Architecture (also known as Infrastructure Architecture).

However, one thing I notice is that many EA Frameworks and papers about EA only like to show three primary Architecture Domains.

What is this fixation on the number three?

These three Architecture Domains are typically broken down into further sub-Architecture Domains, but it’s often the Information Architecture that loses out and is either relagated as a subordinate to the Business Architecture or the Application Architecture.

TOGAF identifies Business Architecture, Data Architecture, Applications Architecture and Technology Architecture but then goes on to combine Data Architecture and Applications Architecture as Information System Architecture, resulting once again in three primary Architecture Domains.

The Dynamic Enterprise Architecture (DYA) defined by Sogeti still has only three primary Architecture Domains and places Application Architecture as subordinate to Information Architecture.

The Archimate is a useful framework because it shows the Information Architecture cutting across the other three primary Architecture Domains, as well as sub-Architecture Domains that distingish between Service (behaviour) and structure.

I prefer to talk about all eight primary Architecture Domains given them equal importance.

These are:

• Strategy & Principles Domain
• Products & Business Service Domain
• Process Architecture Domain
• Organisation Architecture
• Information Architecture
• Application Architecture
• Technology Architecture
• Performance Architecture

The result of having these eight Architecture Domains is that within an EA team each of these domains will be managed equally, and Information Architecture in particulary will not lose out.

Models  &  deliverables in each of these Architecture Domains are then further classified using categories based on the Reference Models in the FEA Framework.

• The FEA Performance Reference Mode, PRM is then used with the Strategy & Princiepls Domain and the Performance Architecture Domain.

• The FEA Business Reference Model is used with the Process Architecture (business process) models.

• The Service Component Reference Model (SRFM) is used with the Application Architecture models.

• The FEA Data Reference Model is used with the Information Architecture models.

• The FEA Technical Reference Model (TRM)  is used with the Technology Architecture models.

Hopefully as the EA discipline evolves, there will be increasing standardisation of how EA is structured. The Archimate EA language is a good start but needs to continue evolving.

I’m trying to define good meta model for Enterprise Architecture.

The Archimate meta model is a good starting point,
see the Archimate Resource Tree (http://www.telin.nl/NetworkedBusiness/Archimate/ART/index.html) for details.

It is open to use, but perhaps is not yet known to the world at large, outside of the Netherlands.

Are there any other Enterprise Architecture meta models ?
What is the meta model for the Zachman Framework for instance ?

Many tool vendors do publish some meta models for their tools.
One issue I find is that very often there is a suite of tools from the same vendor, for example one for Business Process Modelling, another for UML modelling, another for Data Modelling and so on.
These individual meta models often are not integrated and many concepts end up being represented in different and overlapping ways.

Interesting questions are:

• How is the information in a business process model related to classes in a UML class diagram?
• How are different modelling levels represented ?
• How are Business Processes related to Services and to Applications?
• How are different scenarios (current, target) represented?
• How are strategy and performance concepts related to the other concepts ?

Increasingly companies wanting to develop an Enterprise Architecture are also looking at a Service Oriented Architecture approach.

Consequentially one of the deliverables that needs to be defined in the Enterprise Architecture Framework is a Service Catalogue.
In fact there are two kinds of Service Catalogue that often get confused in casual conversation, an Application Service Catalogue and an Organisation Service Catalogue (or Business Service Catalogue).

Application Service Catalogue:
This is located in the Application Architecture column of the EA Framework and defines the Application Services (i.e. those Services that are performed by software applications, implemented as web services, and typically invoked in composite applications using a Process Orchestration).
These Application Services form part of a Service Oriented Architecture approach to building composite service based applications.
Generally I identify the Service Oriented Architecture as the main part of the target architecture vision.

Organisational Service Catalogue:
This is located in the Organisation Architecture column and defined those services that are provided by people or organisation units.
Often these are called ‘Business Service Catalogues’.
Organisations typically identify these Organisation Services as a result of decomposing their Functions into Business Units and then considering what those Business Units do.
If the Organisation Services are well defined, regarded as non-core commodity services, then they can often be outsourced.

In summary, Application Services belong to the Service Oriented Architecture and Organisation Services belong to a Service Based Business approach.

Of course a high level composite Service can include both an Organisation Service and a set of Application Services…

An Enterprise Architecture Framework need to be very accessible.
I have found that find the original Zachman Framework matrix can be too complicated for some people.
In most cases I find that people accept the columns based on the six questions, who, what , where, how, when and why.
The column names are not always understood.
There is confusion about all the rows and in which cell to put the ings such as User Interfaces, Use Cases, Objects, Classes, Components and Services.
The original Zachman Framework betrays its Information Engineering legacy and needs updating.

Does a class belong in the Data or Function Column ?
Where does a Service belong ?

If we distinguish between an organisational service (performed by people) , an application service (performed by a software application) and an infrastructure service (performed by the hardware and infrastructure platform), then should we put each of these services into a different column ?

How do we map strategy aspects and the architecture discipline ?

In response to this I have created a matrix with two dimensions:

• Levels of Abstraction {Strategy, Architecture, System and Operations}

• Architectural Perspectives {Information Architecture, Process Architecture, Application Architecture, Technology Architecture, Organisation Architecture and Performance Architecture}

I have found this to be more aligned with organisation view points and common terminology.

The question is at what level should a high level service be created. The component that provides the service should not be at the level of an EJB, but something larger. A business function (like ‘Financial Management’) is too large a concept. This would break down into a number of Business Processes (like ‘Create Account’ or ‘Reconcile Budget’). This seems better, but I don’t really want to create a business process as a service. I think a service should be more like a operation on an object. The service component or architectural building block that provides the service should still work like a large object. So the answer is to map the business processes not down to elementary business processes but to shift the approach and map them to use cases. A business use case represents a dialogue across the system boundary and consists of a number of activities, that retrieve information and cause changes to the system’s state. These activities are perhaps rather like ‘features’ in Feature Driven Development (FDD). So long as these feature are not too low a granularity, then they will suffice as candidate services. Also with this thinking, the use cases should be primary ones and not be refined with secondary ‘includes’ and ‘extension’ use cases.

Togaf has the concept of super services so I’ll go and look at these now.

It’s interesting that almost every resource on the web immediately equates Service based architecture with Web Services.
I’m trying to define the basis concepts, principles and benefits at the business and strategic level before getting into the technical details.

More later.