Understanding Enterprise Architecture complexity

Nick Malik of Microsoft posted recently that

“For years, we've been living with Zachman and now TOGAF as commercially available EA frameworks, but honestly, they don't address the problems faced by large organizations with respect to complexity.”

This got me thinking about some of the pros, cons and limitations of the traditional frameworks used in Enterprise Architecture (EA).

This isn’t a comprehensive review but I’m going to briefly discuss three frameworks and their limitations in this blog, before I talk a little about OBASHI™ - my company’s own framework for capturing Business and IT related information.  Each framework details how information can be categorised, organised and presented to form the basis for governance and change.  The three traditional frameworks have some key differences which I’ll highlight below. 

Zachman Framework

Zachman provides the ability to define an enterprise in a highly structured way, by using a 6x6 two dimensional matrix to classify components of the enterprise:

Horizontal: The horizontal cells of the framework are based around common questions: What, relating to data; How, relating to function; Where, being the Network or location; Who, identifies people or identities; When, pertaining to times; and Why covering motivation.

Vertical: The vertical cells relate to the stakeholder groups:  Planner, details the scope (Contextual); Owner, defines the Business Model (Conceptual); Designer, documents the System Model (Logical); Builder, the Technology Model (Physical);  Implementer/Subcontractor, shows detailed representations (out-of-context); and Worker, detailing functioning enterprise instances. 

When filling in the framework each cell must be aligned with the cells immediately above and below it, and all horizontal cells must also be integrated. This gives the immediate indication and assessment of the alignment between the IT portfolio that is currently being analysed and the business.

Several software solutions are available to assist with the storing and manipulation of the information gathered by consultants. The output from such solutions is generally formed around the Zachman model itself.

Zachman, unfortunately, is reliant on a high degree of subjective data which is very granular in it analysis, and that is never a great combination.  Trying to obtain a consistent model from multiple architects is a problem commonly summed up as: one architect’s “How?” is another architect’s “Why?”

The Open Group Architecture Framework (TOGAF)

TOGAF is “a detailed method and a set of supporting tools for developing an Enterprise Architecture”, developed by members of The Open Group Architecture Forum. TOGAF centres around four types of architecture which it sees as subsets of an overall enterprise architecture:

Business Architecture: defining the business strategy, governance, organisation and key business processes.

Data Architecture: describing the structure of an organisation’s logical and physical data management resources and data assets.

Applications Architecture: describing a blueprint for the applications systems deployed, their interactions and their relationships to the core business processes described in the Business Architecture.

Technology Architecture: a description of the logical software and hardware capabilities which are required to support the Business, Data and Application architectures. For example, Networks, IT infrastructure, middleware, standards, etc.

The Open Group is a non-profit organisation, but is backed by some major companies within the IT world.  IBM, EDS and HP are all members of TOG and seek to promote tools and services based around TOGAF, thus raising its profile within the EA arena.

What is unclear, however, is how TOGAF fits with other frameworks endorsed by these companies.  Much of the work currently being advocated by these companies, such as SOA, is inherently “bottom-up” and how the “top-down” nature of TOGAF fits with this model is ambiguous.  (Personally, I believe SOA should be pursued through a top-down approach – but that’s a subject for another blog).

TOGAF requires tailoring to suit a particular enterprise and therefore requires strong knowledge of the methodology and the business model.  Finding a team with such qualities can be difficult.  Obtaining sanction to bring such a team onto the project requires much political will by a key influencer at a senior level within the organisation.

Department of Defense Architecture Framework (DoDAF)

DoDAF is a framework used by the US Department of Defense as a standard way to organise EA or SA (Systems Architecture) into consistent and complementary views. The US DoD insists that this framework is used on all major weapons or technology system procurements.

Central to the classification of artefacts (objects) within DoDAF is the concept of interoperability which is organised into a series of levels.

There are four basic views which can be applied to the artefacts:

All View (AV): provides descriptions of the entire architecture, and defines the scope, purpose, intended users, environment etc.

Operational View (OV): this view is unique to DoDAF systems and describes everything necessary to achieve a DoD mission such as tasks, activities, I/O, rules, command–control-coordination relationships.

Systems View (SV): provides system components, networks, logical data models, sequence activity timelines etc.

Technical Standards View (TV): allows for extraction of current standards and future standards.

DoDAF has been developed to deliver an incredibly rich environment of documentation.  In order to evaluate tendors submitted during the procurement process every known item about an artefact must be catalogued and quantified in terms of speed, performance, interface requirements and applicability to a given task.  Due to the nature of the types of systems to be specified for the DoD, DoDAF is an extremely complicated and rigorous framework to adopt.

There are a number of tools available which allow you to gather and report the wealth of data required to fulfil the DoDAF specification.

Conforming to DoDAF can be extremely man-hour intensive and therefore costs can prove a barrier to adoption into the business.  Where DoDAF is a necessity for business development, such as in the defense industry, costs must be factored into the specific project which requires adoption of the framework.

I have discussed these frameworks because they highlight how Enterprise Architecture is split into three camps:

a) Static Models: Zachman is a structural framework which is static and can be used to classify artefacts.

b) Dynamic Models: TOGAF is a process model which is dynamic and requires to be configured to each implementation.

c) Hybrid models: DoDAF and derived frameworks are extended to cover artefacts of special interest to a particular vertical market.

Adoption of any of these three frameworks requires buy-in from the business in order to succeed. Enterprise Architecture is an ongoing process, not just a one-off exercise and as such there has to be a healthy commitment shown by the business.  And this is where there can be a problem with these and other frameworks.  There requires such an initial investment of not only money, but corporate will to succeed, that often other corporate prizes are within easier reach.  Enterprise Architecture is just too much of an overhead.

What is needed is a lighter weight framework which is easy to apply, which can be focussed as necessary at particular target areas of the business, and which provides a rapid payback to the organisation ... the so called “low hanging fruits”, ripe and ready to be picked.

OBASHI™

My company’s framework OBASHI™, combines essentials from all three of the frameworks discussed above.  It provides a static modelling environment based around six layers into which artefacts (or elements as they are known within OBASHI™) can be placed.

In order to take full advantage of the simplicity of the OBASHI™ approach my company had to design a new modelling technology.   This Stroma® software automates the six types of relationships that exist within OBASHI™:

1) Connection: elements can be explicitly connected to show a direct and bi-directional coupling.

2) Dependency: elements can be explicitly connected uni-directionally to show how one element is dependent on another.

3) Layer: An implicit relationship which exists between all elements within a particular layer (for example, Ownership, Systems, Business Processes).

4) Spatial: an implicit relationship which is formed between elements which are placed above or below each other, such as Business Processes placed under a particular Owner.

5) Sequential: an explicit relationship denoted by a list of elements in which adjoining elements in the list have a connection relationship, i.e. a string of connected elements.

6) Zone: elements within a prescribed geographic area are implicitly related to each other.

The entire model can be formed from one or more (usually many) diagrams created using the OBASHI™ methodology.  We term them Business and IT diagrams (B&ITs).

The horizontal and vertical position of elements within a B&IT diagram shows alignment, much in the same manner as Zachman, but with a more flexible relationship modelling capability. Elements can exist on any number of B&ITs, and thus form complex relationships with many other elements while still being easy to understand on each individual diagram.

Process modelling, work flow and data flow can be superimposed onto and across the OBASHI™ layers using sequential relationships to show how business processes utilise and are underpinned by IT.

As each element in OBASHI™ is based on an object, hybrid items can be created to reflect the needs of any particular vertical market.  Each element can reference external documentation and core information about the physical or logical item it represents.

The models and methodologies used by Enterprise Architects tend to reflect the scale, complexity, breadth and depth of the Enterprise being modelled.   For this reason there are often different views which can project the model in a meaningful way to different stakeholders.  OBASHI™ only requires two such views.

Firstly, the B&IT View, where the Business and IT diagram input mechanism also serves as the graphical output.  Secondly, the Dataflow Analysis View, which highlights the interaction between all of the artefacts used to perform a task (or sub task).

OBASHI™ facilitates diagrams which are clear and simple to understand by all levels of an organisation, not just the trained architects which created them.

Using OBASHI™ and Stroma® it is easy to see and communicate complexity and how IT supports any part of the business. This allows business and IT to talk the same language – a prerequisite to bridging the understanding gap between business and IT.

© Paul Wallis 2007.  All rights reserved.

Comments

[Nick Malik]

Very interesting. It is clear that this mechanism helps you illustrate relationships and perhaps demonstrate alignment. What isn't clear from your description is how well the OBASHI mechanism helps you cope with complexity.

Can you ask your tools, for example, how many systems you have in your portfolio that serve the purpose of "invoice generation?"

Can you ask your tools how many independent line-of-business processes are mapped to "assign purchase order to invoice?" Can you see how they are distributed (by geography, culture, business unit, profit center, business program, customer class, etc.)

Can you compare different processes in different lines of business between enterprise-wide business event boundaries? Can you model them to see which ones perform better with respect to time, reliability, cash flow, resource utilization, or error rate?

Can you see what logical activities tie your business processes to your applications? Can you see the business object referenced to acquire data during those activities?

Can you display the list of applications in your portfolio that are tied to a set of logical activities? Can you map the overlaps between them with respect to the features needed to service those activities?

Can you illustrate changes in your portfolio process, features, or technologies over time? Can you animate the changes in a display, collecting specific changes within the bounds of a series of future state projects?

Can you group logical activities into service endpoints by business object, role, process, network or geographical attribute? Can you generate QoS requirements from the relationships?

Can you constrain your service interaction patterns to a list of standards? Can you track and identify the existing services in your infrastructure and rate them on metrics of conformance?

Guess what? No one can. The list of questions I ask above cannot be answered by any tool that I am aware of... so if yours doesn't answer them all, don't be discouraged.

On the other hand, if you are working with a team of folks working to develop a tool, please encourage them to investigate these questions.

The world needs better EA tools.

Thanks for sharing.
--- N

[Paul Wallis]

Thanks for the comments, Nick. These questions really make developers stop and think about why the business needs to use Enterprise Architecture. You've touched on some very important topics, many worthy of a blog entry in their own right, but allow me to go through them one by one to see how close we get with OBASHI and Stroma.
..........
Q) Can you ask your tools, for example, how many systems you have in your portfolio that serve the purpose of "invoice generation?"

A) Yes. And what’s more any Applications, Systems, Hardware or Infrastructure upstream or downstream of Invoice Generation are also available for interrogation.
..........
Q) Can you ask your tools how many independent line-of-business processes are mapped to "assign purchase order to invoice?" Can you see how they are distributed (by geography, culture, business unit, profit center, business program, customer class, etc.)

A) Yes. You can be as granular as you wish when creating the model. As models can be a mixture of physical, logical or both you can map items to geographical locations too.
..........
Q) Can you compare different processes in different lines of business between enterprise-wide business event boundaries?
Can you model them to see which ones perform better with respect to time, reliability, cash flow, resource utilization, or error rate?

A) Stroma copes with the enterprise wide business boundaries, but the meta-model would need to be changed to handle the error rates. The good news is that that is more about how the model is configured rather than functionality. That’s where the similarities to TOGAF’s dynamic models come in.
..........
Q) Can you see what logical activities tie your business processes to your applications? Can you see the business object referenced to acquire data during those activities?

A) Yes and Yes. That is a key part of OBASHI and the Stroma software which controls the model.
..........
Q) Can you display the list of applications in your portfolio that are tied to a set of logical activities? Can you map the overlaps between them with respect to the features needed to service those activities?

A) Yes, and once again, Yes.
..........
Q) Can you illustrate changes in your portfolio process, features, or technologies over time? Can you animate the changes in a display, collecting specific changes within the bounds of a series of future state projects?

A) OBASHI does allow you to map future states to see and report against the impact onto the model. As for the animation, the colour of any impacts are animated to show what is affected.
..........
Q) Can you group logical activities into service endpoints by business object, role, process, network or geographical attribute?
Can you generate QoS requirements from the relationships?

A) OBASHI was created to allow all elements within the model to be logically grouped, so yes to the first part. The QoS requirements is a little trickier, however, but the rules engine in Stroma could be configured to assist here. Stroma has the ability to traverse the model using the six different types of relationships mentioned in the article, gathering information or meta-data en route which is used to change what and how it reports.
..........
Q) Can you constrain your service interaction patterns to a list of standards? Can you track and identify the existing services in your infrastructure and rate them on metrics of conformance?

A) D'Oh, you got me on the last one!

[Johan den Haan]

Very interesting approach! The way your framework is organized and how elements can be linked looks very nice.

I have one question: how can you define principles in your framework? You seems to use architecture only in a descriptive way, but I think the prescriptive notion on architecture can also be very useful. By prescriptive I mean principles reflecting business policies and guidelines restricting the design freedom in a certain domain.

For more explanation see http://www.theenterprisearchitect.eu/archive/2007/06/01/architecture_principles_formal

-Johan

[Paul Wallis]

Hi Johan,

Thanks for the comment, and I read with interest your views on formalising the principles of Architecture.

I'd mentioned briefly in the article about the Stroma software which utilises OBASHI, and it is here where we capture and relate information about the policies, guidelines, SLAs etc.

We use the OBASHI diagrams to capture how assets support business processes. Once we have the OBASHI diagrams we can superimpose dataflows to show how the assets interact.

These interactions can be aggregated to give a view of the services which IT delivers to the business.

At any point in this abstraction we can attach supporting documentation, guidelines, SLAs etc. This could be at an individual asset level, dataflow level or even at the Business Service level.

This allows us to add even more contextual information to the diagrams, and capture principles governing the delivery of services. Although not formalised to the extent you are advocating in your post, the associations within OBASHI are flexible and could readily support a formalised notation.

Cheers,

PJW

[Kevin Mc kay]

Very informative article. Thank you for your efforts.

[Piet Jan Baarda]

I've just started reading your blog. As a first reaction I would like to point you to an article I just wrote titled "The business does not exist!". It presents the need for being aware that there is no such thing as "the business" and you'd better be aware before making any suggestions on improving the IT situation for an enterprise. I general it is a big mess, this article may illuminate some aspects of the explanation. See:

http://www.via-nova-architectura.org/files/magazine/Baarda3.pdf

Cheers, Piet Jan Baarda