EA and intelligence Corp

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 and SOA

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...

Enterprise Architecture Framework

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

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.

What is Service Based Architecture ?

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.