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.


Enterprise Services

30 September 2004

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.

%d bloggers like this: