We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Enterprise Architecture Matters

Adrian Grigoriu

Discussion on the Enterprise Architecture framework definition and ISO/IEC42010

user-pic
Vote 0 Votes

Since the post on the EA framework definition has raised discussions (please read comments to previous blog) I'll post this article separately to respond to concerns expressed, since it is worth clarifying the points of view with wider participation. Please chip in.

Rich wrote "the Standard does not define functions, flows, resources, or any other constructs. The intent is that these are defined in viewpoints or by frameworks".  

True, ISO/IEC42010 does not attempt to be an architecture framework.

A framework helps you build and decompose a system; the framework represents the meta architecture, that is the architecture of the architecture. Bu what does a framework consists of? As an (meta-)architecture, a framework should consist, according to the ISO42010, of the common elements of a system (that is architecture), in interconnection.

I found these elements to be the Functions, Flows, Layers & Views. Any system could and should be described by these elements.
The Functions describe the structure, the Flows the behaviour of the system, the Layers, the physical resources (implementing Functions and Flows) and the Views, the many angles the stakeholders see the Enterprise from which, put together and properly aligned, form the EA.  

Rich also wrote "You are incorrect that the Standard is limited to "technical" dimensions and lacks the human dimension. The Standard, and its predecessor IEEE Std 1471:2000, have taken a "wide-spectrum" stance on Architecture since the beginning. In 42010, an architecture description must address the stakeholder concerns relevant to the system of interest. By definition, these include those system concerns that "pertain to any influence on a system in its environment including: developmental, technological, business, operational, organizational, political, regulatory, or social influences."

Well, nothing to disagree with, except that the 42010 standard, being more general, does not have to take into account the fact that people are part of an Enterprise system, not only part of the environment since humans are not only stakeholders but resources of an Enterprise.

People form a separate Layer of the FFLV framework three layers: Business (logical), Technology and People (Implementation). And the People architecture is part of EA. Ana as an observation, a system, in my view, should be described by both a logical and an implementation (physical realization) architecture.

Does the ISO/IEC42010 standard differentiate between the logical and implementation architectures?

Rich added: "The goal of the Standard is NOT to define an architecture development method, but provide a foundation on which users and enterprises can define such methods in a coherent manner."

In the EA space,  Spewak's, TOGAF... are mainly about the EA development process. Because of that most professionals would expect such a development process to be The framework. And the process is useful indeed. I'll just say that such a process should come with an extended EA framework. Agree, that should not be the case for the ISO/IEC42010 standard.

I found 42010 useful in defining what architecture is since many associate EA with a strategy process alone. Still, EA is architecture in the 42010 sense. I also found the views concept to be useful even though rather ignored in the EA developments; my initial concept in FFLV was "planes" since I represented the framework as a cube (three dimensions: Functions, Flows, Layers+Views) where planes looked like CT scan cross-sections in the body of the Enterprise. If you need to see the BI architecture, just select a cross-section in the technology layer.

I felt the need to develop an overall EA approach that contains

* definitions and EA framework 

* EA architecture reference models (to ease up the modelling of the Enterprise) 

* the EA design that shows the key design artifacts that map on framework and use the metamodel elements. 

* the EA development process

You'll find this "EA approach" on my website illustrated in four A3 posters (The Framework, The Process, The Models, The Design) each containing lots of diagrams. This work is meant to be public under a Creative Commons license: essentially, you can use it for any purpose and add to it, if you mention the author. 

This EA method, compressed in posters, is meant to contain everything an EA architect needs to do its work with, from business case modelling to the strategic transformation process, EA organization, site, governance, maturity assessment, framework, reference maps and models, metamodel, reference business architecture... 

Let me know your views.

2 Comments

| Leave a comment

There are so many architecture frameworks today, it was never the intent to describe another one in the Standard. ISO/IEC 42010 is not an architecture framework, instead, it attempts to define the primitive elements from which architecture frameworks are constructed: stakeholders, concerns, model kinds, viewpoints and the correspondence rules connecting those elements. The goal of this is to give users a way to compare and contrast frameworks when choosing one, and perhaps even allow mixing-and-matching of framework elements to create new frameworks suited to specialized needs in Architecting.

Each framework defines its own ontology. Some use functions, flows, etc. others may focus on services and transactions, etc. Each of these is an "architectural concern": important to one or more stakeholders.

The human aspect is essential to Architecting and is frequently an architectural concern. Therefore most frameworks will deal with this concern through one or more viewpoints, or their models.

Similarly, "logical" and "implementation" dimensions of a system are recurring architectural concerns. Most (bot not all!) architectures will need to delineate one or both of these, using the familiar notations. E.g., a "reference architecture" may be very strict about logical relations, leaving implementation to others. A system-of-systems architecture may focus on implementation of cross-system exchanges, but never detail the logical reasons why two systems might talk ... When both (logical and physical concerns) are in play, it is important to make sure there is a strong relationship between the two (see for example rules in RM-ODP and in Kruchten's 4+1).

Rich, you wrote that "ISO/IEC 42010 is not an architecture framework, instead, it attempts to define the primitive elements from which architecture frameworks are constructed...and the rules connecting those elements" and then you say that "Each framework defines its own ontology."

But "the primitive elements from which architecture frameworks are constructed + their connections" form the ontology of a framework!

Then, the questions is, does the standard cover the ontology of an architecture framework or not?
If yes, is there a single architecture framework ontology, as in the standard, or more as in each framework coming with its own ontology?

I would say that, if the standard has in scope the elements of a framework and their interconnections then, it should cover the ontology of the framework.
And, there should be a single basic architecture framework; otherwise the same system would look very different when described by various frameworks and ontologies. That's what happens today, in truth.

This is the problem I perceive with the standard; it ventures into the framework ontology territory but it stops half way, covering stakeholders and Views but not much else.
That's why people, after seeing the standard, feel the need to continue the work to create a framework.

In the standard, Views are supposed to cover everything else, even frameworks! A framework should not be a View of of a system coming with its own ontology even though it may currently be so. There are more "frameworks" out there (few have ontologies) but they only cover aspects of an EA framework. In fact they are Views as you say. But the state of frameworks art is needy and we know that now. That is what I attempted to debate here.

Any View of a system should be built on the Architecture Framework ontology elements not the other way around.

Services and transactions mabe just an "architectural concern" as you say, but they could be expressed as Functions and Flows, the elements of the basic EA framework.

If "logical" and "implementation" dimensions of a system are recurring (!) architectural concerns" they should be part of the standard because "Most (bot not all!) architectures will need to delineate one or both of these" - as you wrote, they are recurring, as such they are patterns, and thus they are part of the framework elements.


Leave a comment

Adrian Grigoriu blogs about everything relating to enterprise and business architecture, SOA, frameworks, design, planning, execution, organization and related issues.

Adrian Grigoriu

Adrian is an executive consultant in enterprise architecture, former head of enterprise architecture at Ofcom, the spectrum and broadcasting U.K. regulatory agency and chief architect at TM Forum, an organization providing a reference integrated business architecture framework, best practices and standards for the telecommunications and digital media industries. He also was a high technology, enterprise architecture and strategy senior manager at Accenture and Vodafone, and a principal consultant and lead architect at Qantas, Logica, Lucent Bell Labs and Nokia. He is the author of two books on enterprise architecture development available on Kindle and published articles with BPTrends, the Microsoft Architecture Journal and the EI magazine. Shortlisted by Computer Weekly for the IT Industry blogger of the year 2011.

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT