To do Enterprise Architecture, we do need recipes, don't we?
Closing Date: 19 October 14
Started on: 19 August 14
Participants: 2
The diversity of outcomes we have in EA today is bewildering not only for our stakeholders and customers but for our colleagues, fellow practitioners, recruiters and enterprise executives. But each and every one of us, still speaks with conviction about our own true EA.
It all starts with the never agreeing definitions and scope. But, in the end, it all comes down to our methods. A rebellious prevalent opinion is that we don't need methods or frameworks.
But we do, as much as we need recipes when cooking.
A recipe would help one take advantage of the past experience and work. Not only ours. Recipes deliver predictable and comparable results faster and reduce the risks and costs of experimentation for both customers and practitioners. They deliver to expectations.
Cooking, for instance, needs recipes because people want to know what they are about to eat, no surprises there. Because people want edible outcomes rather than experiments. If they like the outcome they would like to cook it themselves. They need as such the recipe.
Recipes have been used since the dawn of time because they eliminate the need to experiment and re-invent. They embed lessons learnt.
That's why we need cookbooks.
Celebrity cooks are good but are more about socializing the art. The cookbook is for us all.
Same with EA. An EA architect that starts to experiment with the delivery of an EA in a company, does that at own peril. The run of the mill architect needs an EA framework.
The job is to describe the enterprise rather than how to describe it.
But because there is so far no single definition of EA and no clear scope, various professionals are tempted to define EA to their convenience either as strategic "glue", or business model... or stories to tell... and only rarely as what it is, an architecture, that is an integrated enterprise blueprint that illustrates the enterprise structure and operation.
Not every architect is keen to re-invent though his own way through the EA. In fact, when each and everyone tries that on his own, they usually fail. EA as a whole fails as such, while customers suffer and EA as a discipline disappoints once again.
That's why we need EA frameworks. To deliver credibility and predictability. To save costs. To reduce risks.
Unfortunately, most frameworks are different in nature, scope and deliverables. Zachman is an ontology (according to the man), that is a definition of the components and relationships in a domain. It does not specify any delivery. In fact it is so general that EA is just a particular case. If you fill in the matrix you still get out a matrix rather than an integrated EA.
TOGAF is mainly a development process plus a collection of tools. That is, it is not a recipe in that you put your ingredients in and then follow the cooking process to get the same or a similar dish. Most of the time the outcomes are and look different and are seldom consumable by our end customers.
Archimate is mostly a metamodel,… DODAF is an OO methodology at heart… Current frameworks have very little in common. Besides, most are incomplete: either ontologies, processes, metamodels...
These approaches are not even frameworks in the true sense, in that they are not recipes where you put the ingredients in and follow the cooking process to get the saute.
We need a proper EA recipe, an EA framework to reduce the diversity of definitions, scope and outcomes and deliver EA to expectations each and every time. We need results not debates on what EA is.
It all starts with the never agreeing definitions and scope. But, in the end, it all comes down to our methods. A rebellious prevalent opinion is that we don't need methods or frameworks.
But we do, as much as we need recipes when cooking.
A recipe would help one take advantage of the past experience and work. Not only ours. Recipes deliver predictable and comparable results faster and reduce the risks and costs of experimentation for both customers and practitioners. They deliver to expectations.
Cooking, for instance, needs recipes because people want to know what they are about to eat, no surprises there. Because people want edible outcomes rather than experiments. If they like the outcome they would like to cook it themselves. They need as such the recipe.
Recipes have been used since the dawn of time because they eliminate the need to experiment and re-invent. They embed lessons learnt.
That's why we need cookbooks.
Celebrity cooks are good but are more about socializing the art. The cookbook is for us all.
Same with EA. An EA architect that starts to experiment with the delivery of an EA in a company, does that at own peril. The run of the mill architect needs an EA framework.
The job is to describe the enterprise rather than how to describe it.
But because there is so far no single definition of EA and no clear scope, various professionals are tempted to define EA to their convenience either as strategic "glue", or business model... or stories to tell... and only rarely as what it is, an architecture, that is an integrated enterprise blueprint that illustrates the enterprise structure and operation.
Not every architect is keen to re-invent though his own way through the EA. In fact, when each and everyone tries that on his own, they usually fail. EA as a whole fails as such, while customers suffer and EA as a discipline disappoints once again.
That's why we need EA frameworks. To deliver credibility and predictability. To save costs. To reduce risks.
Unfortunately, most frameworks are different in nature, scope and deliverables. Zachman is an ontology (according to the man), that is a definition of the components and relationships in a domain. It does not specify any delivery. In fact it is so general that EA is just a particular case. If you fill in the matrix you still get out a matrix rather than an integrated EA.
TOGAF is mainly a development process plus a collection of tools. That is, it is not a recipe in that you put your ingredients in and then follow the cooking process to get the same or a similar dish. Most of the time the outcomes are and look different and are seldom consumable by our end customers.
Archimate is mostly a metamodel,… DODAF is an OO methodology at heart… Current frameworks have very little in common. Besides, most are incomplete: either ontologies, processes, metamodels...
These approaches are not even frameworks in the true sense, in that they are not recipes where you put the ingredients in and follow the cooking process to get the saute.
We need a proper EA recipe, an EA framework to reduce the diversity of definitions, scope and outcomes and deliver EA to expectations each and every time. We need results not debates on what EA is.
This challenge is listed under
IT Security & Architecture
Community
Related Posts:
Initiator
2 Suggestions
Mario, we seem to agree on frameworks at industry level.
But, if we can find frameworks for specific industries, then an overall generic model for is just one step away. One can abstract the common parts of these various industry specific frameworks to form an overall higher level generic enterprise model.
In fact, Value Chains are, in essence, the common top level generic activities of any enterprise. After all the companies of the world do the same thing, Source, Produce, Sale, Market, engage with customers, partners and other institutions and manage their own resources.
Besides the same basic organisation and processes are in use in most, if not all industries. Take for instance the functions of governance, HR, Finance, IT, operations, Sales, Customer Service, Marketing, Procurement, Strategy... or processes such as Order to Cash, Concept to Product...
And in fact, all enterprises appear to have four basic functions: - Governance (directing and coordinating the enterprise), - Operations (product delivery), - Development (enteprise further development) and - Support (manage own resources) (GODS).
Here is a proposed one page generic/reference business architecture that works for most industries https://www.youtube.com/watch?v=yYP9RpVTLXA
It works in conjuction with existing process maps as well. It has to be customised for your enterprise.
While we already have process maps, we need such a business architecture model because an enterprise framework is more than a process map as you pointed out, in fact. A business architecture is about the integrated view of the structure, behaviour, information, capabilities...
and a process comparison of a few existing business maps to the above generic model http://www.bptrends.com/publicationfiles/03-11-2011-ART-Comparion%20of%20business%20modelling%20approaches%20to%20GODS-Grigoriu-ph.pdf
All very interesting points, Adrian. My perspective is that to arrive at a true one-superset-fits-all framework would be quite challenging because the patterns of data flows, business process flows, storage and other processing may vary quite a lot from one industry to another. For this reason, I would think that it may be possible to arrive at one framework, but only at the industry level. This would mean that we'd have industry-specific business process frameworks first, from which a common EA would be derived.
I view Oracle's PIPs (Process Integration Packs), part of their AIA, as an attempt to achieve something like this, although PIPs target the end state based on the AIA, which is their big picture EA.