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

An Enterprise Architecture framework definition

user-pic
Vote 0 Votes
Continuing one of my own recent posts: "the question is for us if we do need an EA framework... We do because the framework embodies, in a structured manner, the long experience of the many of us and our companies... The framework saves a lot of effort and costs since it leaves the architect focus on own Enterprise issues. It makes the EA development predictable and repeatable. And ensures that professionals are certified against a single standard."

But can we talk about Enterprise Architecture frameworks without defining them? Apparently we can, quite garrulously, in some fora, with little closure nevertheless.
If we do not agree on what EA is, it consists of and what its scope is, how can we say what EA can achieve; can EA aligns IT to business or facilitate strategy specification and execution? And if we don't agree on an EA definition how can we agree on an EA framework, which should be the EA backbone? How can we make sure that we achieve similar outcomes using different frameworks?

A popular opinion is that we don't even need an EA framework. It is typically uttered by professionals superior in the knowledge that they alone know how to do it, but you don't, that they know how to answer, let's say, the W questions while you don't.
They really guard their experience for competitive advantage but that favors them in the relation with the customer, who often live in expectation and doubt till, at the end, they see the results, whatever they are. And then it is too late for the customer to say "no way". In fact these professionals sell their reputation, assuming they have one, in a way consultancies do. But it is also true that some attempt to guard their IP coming from a hard won experience. But how can we progress in the field if nobody shares successful case studies and methods? How do we know whether EA pundits talk about the same EA? The probability is that they don't having not even the definition in common.
In any case I'll share my views here and on my site: http://www.enterprise-architecture-matters.co.uk/home

I begin with the critique of existing "frameworks" to explain why we need to move on. In the first place they are too many and few of them deal with the same aspects of EA. There is also an ever stronger current of opinion that they became obsolete, that we may need a new generation framework. Nothing great have been achieved in using them and nothing significant has been added for a long time now.

Zachman's is called a framework but some say it is an ontology; in truth it is mainly a method of analytic thinking used more for scoping and selling EA than anything else.
TOGAF is a process (ADM), buried under plenty of additional and often disjoint information, hard to read and use.
FEA is a US federal program, a process (FSAM) and a set of a few common EA views that should bind together the EAs developments in each government agency. Is there enough commonality though to achieve that? I don't think FEA is called a framework any longer. FEAF was, but it might be also obsolete.
DODAF starts with a solid metamodel, which is public, but then most of the work is obscured from public view.

But what is a framework or what should it be?
"The most common method of creating an Architecture is to use a framework to break down and categorize the various parts of the architecture; this approach allows focus on design while retaining the overall context within which the object is being designed." That was Zachman's. According to this, Zachman's matrix is not a framework since we assemble the parts in a matrix (the same, no matter what Enterprise) rather in our own EA.

In my view, an EA framework is the architecture of the Enterprise Architecture, that is, the meta EA. And it would consist of the common elements and their links that could describe any EA. But a framework should be complemented by development process, reference models (for a typical Enterprise structure for instance, IT infrastructure etc) and design method (design artifacts in interconnection).

Let me elaborate. An EA method should consist of
1. EA Process: the EA development process and Best Practices for
* EA team organization
* EA governance, team and program organization
* Tools to measure maturity, value created and assess EA business case

2. EA Framework, the meta EA consisting of the specification of
* Key EA framework elements/patterns
* Metamodel showing the EA entities and relationships
* Key Views like Location, Information, Security, Financial, Performance etc

3. EA (Reference) Models
* Generic Business Architecture, reference functions/capabilities map
* Typical IT Applications Map
* Generic Infrastructure architecture
* Typical organization design charts
...
4. EA Design method consisting of
The key EA artifacts and design sequence using metamodel & framework elements

More, next time. But a preview can be seen on my web site
http://www.enterprise-architecture-matters.co.uk/home
Questions time.

11 Comments

| Leave a comment

Good posting. You may be interested that ISO/IEC 42010 (internationalization of IEEE 1471) proposes requirements for a common way to define various architecture frameworks, so that users and enterprises, can choose a framework best for their purposes, or even mix-and-match elements from various frameworks. See: http://www.iso-architecture.org/ieee-1471/docs/ISO-IEC-IEEE-latest-draft-42010.pdf

The standard is in draft stage; comments appreciated!

Many frameworks, not just DODAF, obscure their information. This might be parts of the definition or even simple things like the change proposals and rationale as they develop. This is probably not a product of any of the frameworks but is more likely a product of the culture of the organizations to which each is tied. Large organizations and fears of IPR, competition etc. are the more likely motivations.

This was partly why we released TRAK under open source licenses (via sourceforge) - and, yes, this allows release with attribution to all hose involved. We believe that the framework should be user-led rather than specifiers-led as isntraditionally the case. It also has to be better to involve users in the definition as none of us are experts on our own but collectively we might just stand a chance. It's also better if the decision-making, traceability and rationale is fully in the open where anyone can see it.

TRAK is a pragmatic and systems-centric framework based on MODAF. It is simple, domain-free and conforms to ISO 42010 in the way that it is specified and the way that consistency is controlled. The metamodel easily fits on a small piece of paper and is in 'plain English'!

More information is at and and a third party overview is on Tom Grave's blog at


user-pic

Rich, ISO/IEC4201 while proposes a competent definition for architecture, unlike many other attempts, it does not describe Enterprise Architecture. In a way ISO/IEC 4201 is more general and as such would lack the information specific to an EA.
In other ways, the standard is defined for technical systems, more or less, and as such it lacks the human dimension.
It also lacks the concept of resources, function, flows... But I may be wrong.
You might have checked FFLV on my web site. It describes Functions in relationship to Flows, resource layers and Views which I initially defined as planes (cross-sections in the FFLV cube). One may use FFLV as a a standard for enterprise architecture, at least. It adds a lot to the existing standard.

Furthermore people require a development method as well nowadays.

Nic,
Honestly, I didn't quite agree with concept of fixed Views in TRAK, if I remember well. It is very limiting. There should be an unlimited number of views.

ISO/IEC 42010 is intended to be a foundational document. The definition of architecture is designed to encompass software architecture, systems architecture and enterprise architecture, without being limited to any of those domains.

architecture: fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution

where "system" may be any of: enterprise, system of systems, product line, application, or any other aggregation of interest...

Software and systems architects seem to emphasize the elements and relations; enterprise architects seem to emphasize the principles. All aspects seem essential.

Critical to the very nature of architecture of a system of interest is Its Environment. Many would claim if you are not taking account of the Environment, you are not doing Architecture.

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."
It's that wide spectrum stance that seems to make it widely used by enterprise, system and software architects.

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.

The Standard does not define functions, flows, resources, or any other constructs. The intent is that these are defined in viewpoints or by frameworks. Different systems and enterprises will require different constructs and notations. Ideally, we as a community, start to get these useful notations "on the shelf" for all to use, as has occurred in mature engineering disciplines.

The intent for ISO/IEC 42010 is to allow the (enterprise|system
|software) architect to construct the appropriate infrastructure and then produce descriptions of architectures of interest.

Thus you'd construct a set of viewpoints that capture the concerns, such as resources, flows, evolution, etc. The primary focus for ISO/IEC 42010 is to tell you what has to be in a description, and not to tell you how to actually do any particular 'kind' of architecture. Thus the primary contribution is the ontology for how to talk about architecture descriptions and architecture frameworks (that in large part exist to produce/drive descriptions of architectures.)

It's relatively easy to represent/model RM-ODP, Zachman, DODAF, etc, using the ISO/IEC 42010 ontology. One thing you learn when you do this are some of these existing frameworks probably need to add information to their own definitions to make them more usable for describing architectures. In particular, picking on DODAF, you can model this as a set of Operational/System/Technical 'viewpoints', but you need to clearly identify the set of stakeholders and concerns that each viewpoint should address. And this is A Good Thing, since my experience with DODAF is that it's often used to produce a lot of data that then goes hunting for relevance, rather than being grounded in "Here's who wants this product, and here's what they intend to do with it when we produce it."

Very good post. I am always seeking for well suited frameworks and I have recently discovered a very interesting work done by a public group. It is called "PRAXEME" and their ambition is to build a public method for Enterprise Architecture. In addition, since it is an open group all their work is accessible and shared on internet.
If you are interested, here is their main page:
http://www.praxeme.org/index.php?n=Main.HomePage?userlang=en

Here is a white book where they summarize their approach:
http://www.praxeme.org/uploads/Syllabus/SLB02-EN.pdf

Rich, not sure where this came from. TRAK does not say anything about the number of views being fixed - but the number of viewpoints (specifications for view types) definitely is.

Have I missed something?

Seems daft replying to self but for whatever reason the links I thought I'd added don't seem to have some through. I might have been something I missed.

The relevant links are:

TRAK metamodel - http://trakmetamodel.sourceforge.net
TRAK viewpoint - http://trakviewpoints.sourceforge.net

and Tom's blog article:

http://weblog.tomgraves.org/index.php/2010/08/14/trak-trains-and-ea/

Rich, it might be the intent(?) to not explicitly address human aspects but by default if the modern definition/understanding of a 'system' is adopted within 42010 then this will include both humans and machines etc. - and the trick is defining what your system of interest is (as always!).

I was always taught that in system design you always had to consider what lies outside the system of interest - to do the job properly you have to consider all the possible interactions (wanted or unwanted) between the system of interest and everything else - this is where the expression 'residual world' came from.

Although 42010 is useful and essential in trying to get some much-needed standardisation (see http://trak-community.org/index.php/wiki/Architecture_Framework_Comparison), I don't think having to identify stakeholders for each viewpoint is overly useful - yes, stakeholders should be identified but having done this myself for TRAK you inevitably end up with pretty much the same set of stakeholders for each viewpoint definition. I think this is because in modern company management we're all asked to play multiple roles. For example, although in my job my usual role as 'systems engineer' is dominant I have to empathise and assume the role of 'project manager', 'safety engineer' , 'designer', etc. [A job may have many roles]. The main thing is that 42010 forces you to think / identify the stakeholder(s) and what they might want from the architecture task.

Aligning the established frameworks such as DODAF etc to 42010 is far more than just a terminology exercise. They use, for example 'viewpoint' to mean a collection of views - not as a specification for a view (42010). They mostly don't have a specification for any view or at least it's so vague that architects can and have interpreted them in such different ways that it's impossible to exchange the end results - this is why the tool vendors collectively forced standardisation from the bottom up via the UPDM (to add the standardised constraints missing from what should be the defining documents).

With the exception of some parts of MODAF there are very few rules for consistency. This is one of the 2 big things brought by 42010 - the need to properly specify each view content and the need to specify rules to make the architecture description consistent.

They all mix 'architecture' and 'architecture description' which is particularly confusing when you get to the All Views - where you should document what you've learnt from the 'architecture description' and what this means for the 'architecture'.

DODAF has its roots with the underlying DADM (data model) and my suspicion is that the motivation is to populate the DADM which results in different outcomes/processes to those if you were trying to understand or describe a system. For example I think the data model requires a level of completeness and detail that isn't necessary to get a system successfully into service. This is where engineering/being "good enough"/risk at an acceptable level comes into play. It's also worth noting that the Systems Views in DODAF 2 are now deprecated and the instruction is to use the equivalently names Services Views. Quite how you can not need to describe a real implementation and how you can equate a system with a service is beyond me.

It isn't at all an easy thing to move towards 42010 compliance and the dependencies between DODAF, MODAF, NAF and DNDAF both at a high level and also in the tool-imposed notation constraints via the UPDM mean that you can't just unilaterally change something on one side. Names involve semantics - they're not just labels.

The human aspects are definitely a part of Architecting. It is not the intent of the standard to be limited to only technical aspects. This has been true since the beginnings of IEEE Std 1471 (2000).

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