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.