|
Without a framework, in general, it is impossible to have predictable and repeatable outcomes. Without it, every EA development may take a different path with different outcomes; EA would not deliver to expectations. Each and every EA may have different components and views. Two EA teams would come at very different results for the same Enterprise. Without a framework there can be no true metamodel to describe the Enterprise entities and enable navigation. The framework reflects the definition and scope of the EA.
A framework, according to whatis.com, is "a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure"
Stakeholders' views should all feed and fit back into the framework where they belong, once completed. Otherwise we end up with a simple folder of unrelated, unnavigable artifacts whose sum does not reveal the whole. This is the usual case. Impacts of change could not be analysed. The IT alignment to business, a chief aim of EA, would not be achieved then.
A framework like TOGAF describes a few already known layers, a simple process and its deliveries. It does not show how to mount the parts in the whole and how to navigate from one view to another to analyse dependencies.
It is not a complete framework. And it is very hard to use because of its size.
Zachman does not specify how to model the What, the How... views or navigate between them ... although there are composite views. It tells you to do them but now how to document them. POLDAT and its variants look more like a list of views rather than a framework.
An EA framework represents the architecture of the EA, that is the meta-architecture of the Enterprise, i.e. an EA structure with hooks where components fit back in, like the chassis where the car parts mount on.
An extend framework has to cover not only the structure, operation, and layered resources but the development process, governance, value measurement, ... all aspects of the EA. You do not have to do this framework work again and again. Such a framework would enable navigation.
Let me expand:
* a high level philosophy (Why, How...) to scope, explain and sale EA (like Zachman)
* the business and process map for any Enterprise (like SCOR, VRM...) for business architecture
* the key layers/domains we need to describe (business, technology...)(like FEA(F))
* a method of modelling the architecture(like structured design, OO/UML) and metamodel DODAF is good at that.
* a process with deliveries at milestones (like TOGAF)
* a governance like FEA
As an architecture is a blueprint not a thousand pages, a Single Page Architecture concept is also useful to start with Architecture reference maps/templates for business, applications and technology architectures would be extremely desirable because the EA architect can focus then on the specific Enterprise rather than building EA frameworks, with mixed results at that.
I use such a framework called GODS.
Only registered users can write comments.
Please login or register. |
