www.aim.nl

English version


Nederlandse versie

Steven's weblog

Anyone can take information from this weblog as long as (s)he refers to it origin properly.

 

August 1st, 2006: Observation on TOGAF ADM 8 and 9

The following text contains a number of observations on TOGAF versions 8.1.1 (september 2005) and 9.0.1 (july 2006). It is not meant to be a full comment, it is merely a number of observations and general remarks. Feedback is very welcome.

 

TOGAF and ADM is ......

TOGAF is the The Open Group Architecture Framework, a combination of Enterprise and IT Architectures. It has 3 main parts:

  • The Architecture Development Method (ADM) is the process and method to create the component architectures (from initial vision to a full specification of the architectures, implementation and governance of the completed architectures). ADM has 9 (version 9 has 7) phases (see the figures below).
  • The Enterprise Continuum is the set of architectures, building blocks and products which are used to create the enterprise architectures. The Enterprise Continuum consists of all the architectures, standards, reference models and deliverables that make up the enterprise architecture.
  • The Resource Base encloses best practice tools and techniques which are used to guide and create the architectures in the Enterprise Continuum.TOGAF has a resource base of simple tools and techniques to support the ADM cycles. These range from templates for principles, business scenario tools, skills frameworks, case studies and mappings to other architectures.

The usual way to develop with TOGAF is to start with the basic foundation architectures and build on them until the organisation-specific enterprise architecture is fully defined. The architectures then guide the selection and development of the products and solutions for the organisation-specific business operations and infrastructure solutions. There are alternative ways, like working on a part of an organisation, or filling the architectures in cycles for (for parts of) an organisation.

 

TOGAF Version 8.1.1 --------- Copyright: The Open Group --------- TOGAF version 9.0.1

The pictures above represent processes for TOGAF Architecture Development. On the left the process of TOGAF version 8.1.1 (september 2005) is given, on the right the brand-new (july 2006) process of TOGAF version 9.0.1 is given.

 

My observations

Observation 1. Practical use of the Architecture Development process

Application development has been around since the beginning of Information Technology (1939-ish). Real methods for application development are developed since the 60's. The ADM processes are not meant to develop applications (although I talked to someone who said it is for application development), the ADM process is meant for Architecture development.

TOGAF talks about a Business Architecture (in practice a model of the use of information systems), an Information Systems Architecture (applications and data) and a Technology Architecture (the information technology itself). These Architectures (in fact these are sub-Architectures) are respective views on/models of the business, the information systems and the (information) technology. ADM is meant to create and maintain these architectures.

It was mentioned an architect will usually work on a part of all architectural issues in an organisation. Furthermore it is strongly advised not to try to create the architecture first time around, but to start with a part (usually a part of the part of an organisation one is working on), and to let the content "grow".

This first observation is on proving the added value of the TOGAF approach to an organisation when you start with ADM. Call it the general business case. In my opinion it will be a hard case to make, and prove. Let me give you some of my thoughts (without trying to be complete):

  • The ADM process is not going to enhance or add to the existing functionality (the existing services) of an organisation. So there is no direct added value for the users (today this usually includes nearly everybody in the organisation) in starting with ADM.
  • The TOGAF architectures contain a large number of details to be written out to get to a complete model/view/architecture. This will take time, usually a lot (probably a number personyears) to set up. And it will never be finished, because things change all the time.
  • Applications ought to be properly documented. This should also be true for implementations of data, systemsoftware, hardware, network, security, system management etc. The question is to what extend the TOGAF, in fact, rewrite and regroup this documentation? This should be examined carefully, mainly for the Information Systems and the Technology Architecture.
  • What is the real use of a full description of the TOGAF Architectures for the organisation itself? Due to the amount of (IT) details in the Architectures it will be much to technical for the organisation to read and use.
  • ...

So: why should an organisation start this work? Technology changes fast. Because the TOGAF architectures contain a large number of technology related issues and description, the content of the TOGAF architecture change a lot. With the problem you will always be late in changing the description/model/architecture documenting the current IT infrastructure. This is why is a tough case to put to a business/organisation during a Preliminary/Initiation who have to pay for it all.

Observation 2. Architecture planning (TOGAF 9.0.1)

Again: what are we talking about? Is this the information plan or the project plan to better the current IT-services for an organisation? Well, it is not. The ADM phases are developing the Architectures; the Architecture Planning phase is to plan this development. One could look at a "during" and at an "after":

  • During the Architecture Development we should have "growing" content of the TOGAF architecture. There ought to be a good relation between the informationplan/projectplan and the work in the ADM phases, otherwise the resulting descriptions of reality in the Architectures will not fit to reality (current and target) itself.
  • After. In fact there is no after, because as soon as the Architectures are ready changes will be happening and you will need to change te content again.

In both cases the planning processes for application and architecture development should be linked together closely, preferably in some kind of rhythm together. The activities, of course, are quite different.

Observation 3. Architecture Vision

The Architecture Vision phase is meant to create a vision of the future enterprise architecture. Reviewing existing enterprise vision, strategy, goals and drivers TOGAF tries to understand the future enterprise. First-cut "drawings and designs" of the enterprise architecture will be able to show the business what the IT support will look like in the future.

Architecture Vision is combination of terms usually referred to as a pleonasm. To me architecture is a shared view on a reality. In line with this definition, Architecture Vision is a vision or view on architecture. For this reason combining the terms Architecture and Vision is double. You may, for instance, have an (IT-)Infrastructure Vision. This would in fact be the Architecture of the IT infrastructure, the IT architecture.

The Architecture Vision is described as the architect's "elevator pitch" - the key opportunity to sell the benefits of the architecture development to decision makers in the enterprise. So: find purpose, benefits etc. to sell this activity (keeping in mind what was said in observation 1).

Now this is in fact IT-vendor talk: you need to sell to an business/organisation that it should spend a large amount of money to buy Architectures. This is way off what it should be; and it clearly states the enormous gap between business and IT. Architecture ought to be a shared view on a reality. If such a view is shared by the right people, incl. the decisionmakers, in the organisation, they will try to find vendors to get the solutions they want because they know what they want.

This is very different situation for IT-vendors. If these people really have and share the right views, practice learns that the solutions they want will be much smaller in terms of, predominantly, money then what they are used to today. The general feeling in businesses today is that they have much to much functionality (call them services), while they still lack a large number of services they really need (but somehow can't get). And when they know what they want because they have the right view/architecture, they can and most certainly will downsize their IT-infrastructure by factors. Needless to say their architecture/view is not be the IT-based Enterprise and IT-architecture of TOGAF.

TOGAF goes even further. It states that key elements of the Architecture Vision are enterprise mission, vision, strategy, goals and drivers. In the eyes of the strategic business manager this means IT-professionals/architects are (re-) documenting his/her strategic business issues, and call it/use it to have an Architecture Vision. Such a strategic business manager will most probably frown at such an effort coming from the IT-community because IT is a means, one of the capital goods (be it an important one).

If I interpreted the term Architecture Vision for what one would expect it to be, I would say it would be the shared view of the higher managers/"decision makers" (above tactical level) on what needs to be done. If this is true I would not dare to start the ADM process before this vision is shared by the right people in the organisation first. True, this may take months, even years, but to start such a large amount of work like ADM I would think twice before pushing ahead without it. But this is not what is meant by Architecture Vision in TOGAF/ADM and that is worrying.

Observation 4. Architecture Development (combines the Business, Information Systems and Technology Architecture phases)

These phases are for the work itself: the filling of the architecture "matrix". Current situation as well as target situation. Let's get a level deeper into the TOGAF/ADM definitions/descriptions:

  • Business Architecture: is a prerequisite to do IT-work. You hope it is already available, if not, according to TOGAF, IT-professionals will create the new enterprise's business architecture covering the business process, services, function, organisation and strategies. In (IT-) practice the Business Architecture is a necessary means for demonstrating business value of subsequent Technology Architecture work to "key stakeholders". In terms of TOGAF it needs to be there to know what "architecture" needs to be there to support the organisation.
This is quite different from the description that says a Business Architecture is there to know how people, means etc. work together to achieve the goals the organisation wants to achieve by its strategy. In conclusion: it better be available before a TOGAF/ADM activity starts.
  • Information Systems Architecture; is made up of the Data Architecture and the Application Architecture that support the Business Architecture. TOGAF states one can start with either, as long as both Architectures are completed (current and target). So we are talking about the model of the software and the databases/files (current and target).
  • Technology Architecture; the technology architecture forms the foundation for the target IT infrastructure. In TOGAF this is described in by far the most detail, and reading this shows this is the real basis of TOGAF.

In TOGAF 8.1.1 Architecture Development consisted of 3 phases, and TOGAF 9.0.1 opens a better possibility to order the work in your own way.

2 observations:

  • Business Architecture. I miss the real Business Architecture. This ought to be developed and maintained by the business itself, outside IT. This is the real context, while the Business Architecture in TOGAF only contains the information that is needed to determine the IT-services and the alignment of IT to the business.
  • (enterprise) Information Architecture. I miss the view of the organisation on their information as a corporate resource. The knowledge developed that way is the basis for the development of services themselves, and in fact contains the specifications one needs to do that.

In conclusion to these observations: the TOGAF Business Architecture is really a IT-Business or Business-IT Architecture. For the same reason it would be better to talk about an Enterprise-IT or IT-Enterprise Architecture. The reason is that TOGAF operates (and is developed to operate) on the (IT-)supply side.

This opens discussions about a real Business or Enterprise Architecture: the view on the business or the enterprise itself, demand-side. Not by IT-professionals, but by business professionals. Also on the demand-side there ought to be an Information Architecture, as described above. This last architecture will enable a business to control investment in and exploitation of IT as a means, a capital good. These are not the realm of the IT-vendor.

Observation 5. Architecture Transformation and Architecture Deployment

During these phases the specific solutions architecture and implementation plans to migrate from the current state to the new enterprise architecture are determined, including a governance framework. Any procurement and development planning decisions are made. It is ensured that the development work remains consistent with the architecture specifications and delivers the requirements of the sponsor and stakeholders. At the end of this phase business value for the business operations should be realized.

When one tries to combine the notions of these phases with the application development phases it is difficult to understand what is done.

Developing Architectures will create versions that need to become "operational" (Transformation and Deployment). Architectures as defined by TOGAF are descriptions/models/views/... etc. So, with a new version we are making a new Architecture = description/model/view operational. Observations:

  • For one of the Target Architectures this is difficult. The changing of a target architecture means we are going to a different future. This will change the thoughts about the future of the organisation, or, better, it introduces a changed description/model/view of an organisation on its future because its view is changed. In all cases: it will also change investments in this future, and therefore change application development and maintenance. How this is done exactly is not clear.
  • For the Current Architecture this is a bit strange, to say the least. A Current Architecture describes what we have, and the new description should "of course" be better then the one we have. The problem I see is that we cannot keep a Current Architectures up-to-date because reality changes. That's like riding with a GPS system in your car, and using a 10 year old map: the country is still there, but it has changed and the system will have you driving old roads that may not be there any more.

Now: changing a reality must also lead to changing the way the reality is described. A Current Architecture describes a current reality. If the documented current IT is documented, what more do we need to change in our Current Architectures? This sounds very double.

This all goes to the core of my observations: the added value of TOGAF to a documented IT-infrastructure. And the added value of detailed target Enterprise en IT Architectures in a fast-changing IT-world. All IT-supply side. Practice tells me demand side architectures will minimize the amount of work to be done on Enterprise and IT Architectures next to a documented IT-infrastructure.

Observation 6. Architecture Best Practices Management

Documenting best practices and managing them is always a real good idea. Like Deming's Circle Plan-Do-Check-Act and, first and foremost, to be able to learn from successes and mistakes.

Observation 7. Requirement Management

To me this is a very strange phase/activity. In my mind it should be what it is all about, but reading TOGAF it is not really the case. Requirements are defined for Architecture Development, not for Application Development. Requirements for Architectures are much less important then requirements/specifications at investment/application level. Surely there will be rules you need to abide by to get from a current to a target Architecture, but the translation in rules of what a business wants and needs to support it is of much more practical importance.

This activity is about requirements for the creation and development of Architectures. TOGAF 8.1.1 tells us about Requirement Management "not a static set of requirements, but a dynamic process whereby requirements for Enterprise Architecture and subsequent changes to those requirements are identified, stored, and fed into and out of the relevant ADM phases".

Requirements from and for Architecture Development: a kind of Meta requirements? This is becoming very academic. Why should we have such explicit requirements for Architectures, while Architectures describe the current and target "Infrastructure". The changes that must be made to go from current to target/future can only be subject to requirements/specifications, but these are not the requirements meant in TOGAF/ADM.

A step further. Mainly in the 80s (and 90s) we have, in fact, tilted our thinking about IT-infrastructure from vertical to horizontal. Before we had stovepipes, hardware next to hardware, each more or less dedicated as a platform for information systems. Now we have an IT-infrastructure where we really do not know (because it is in fact irrelevant) which hardware etc. we use.

At the end of the 90s up till today we have tilted what TOGAF calls the Information Systems. Because we were busy with alignment and the effectiveness of IT in the organisation we came to talk about Information Systems Architecture. In fact we moved away from application stovepipes to application or service landscapes. Again, tilted from vertical to horizontal thinking.

There is a third step. We are able to tilt our thinking about requirements/specifications: from requirement/specification stovepipe, to a complete landscape or what the organisation wants and needs. In fact specifications are definitions and boundaries on the information an organisation needs and wants. Suppose we can talk about the information of the organisation, and what we want with and of it. In fact we are developing and managing our knowledge of information as a corporate resource, and from this knowledge base we can derive the relevant rules etc. to create the requirements/specifications we need for new investments/developments. This is what we can the Information Architecture.

The Requirement Management activity comes close to an Information Architecture, but its description is quite different from this kind of demand-side Architecture. In TOGAF Requirement Management contains requirement for the Architectures. I really do miss the direct added value of this for organisations, because this ought to be a standard exercise, and therefore an academic one.

Wrapup

As a wrap-up a number of more general observations:

  • TOGAF presents itself as a method developed by IT-vendors to deliver "Architectures" as a product or service that organisations and businesses can buy. It is a method on the IT-supply-side because it is about creating a framework to supply IT-solutions.
  • The TOGAF Business Architecture is not a Business Architecture as an organisation ough to see it. Your view on a business cannot be IT-based, because there is much more important "business" knowledge you need then the knowledge of IT as a means, a capital good. Demand-side. The goal of the Business Architecture cannot be limited to determine the support and organisation has and want to have of their IT. That is also why a Business Architecture is the view of the "business" specialists, not in terms of IT. TOGAF discusses a IT-Business Architecture.
  • The (enterprise) Information Architecture is missing. Demand-side, see above.
  • The TOGAF Enterprise Architecture is in fact an Enterprise IT Architecture. Supply-side.
  • Thinking as a strategic/tactical business manager it will be very difficult to accept TOGAF because its added value will be difficult to determine. In my opinion business managers who really know what Enterprise and IT Architectures are all about will really hesitate to invest in the ADM activities.

One more observation: a question

Lets consider the following: suppose we work for an organisation with:

Question: what is in TOGAF that is not already available in the above situation?

Let's look at this in more detail:

  • We have the current TOGAF Business Architecture because the business knows what they want, and have.
  • We have the target TOGAF Business Architecture because the business knows what they want.
  • We have most of the current TOGAF Information Systems Architecture and Technology Architecture because our IT-infrastructure is documented well.
  • The organisation knows about their information, so that part of Requirement Management is filled.
  • The part of the Requirement Management that contains the rules to get from the current TOGAF Architectures to the target TOGAF Architectures may be ill-defined or even missing, but, as said before, I think this is in fact mainly an academic excercise.
  • The business knows what it wants in the future, so the strategy, goals, drivers etc. for the target Information System Architecture and the target Technology Architecture are known, or can be made known in a minimum effort.

In fact only the details of the target Information System Architecture and the target Technology Architecture are not known. Now lets think from the business perspective: if what is needed is known, to what extend should we document the future applications, data and technology architectures outside of what is doing during the creation of these changes of the infrastructure themselves?

Let's re-formulate this question. When we know what we want, is it interested to do an exercise to design the future solution when the future solution is not introduced (yet)? Suppose you do this, what would be the use of such an investment? At the time you want to buy IT-infrastructure the state of the art technology will most probably be different from today, so our Architecture will need to change accordingly. Is this a useful exercise to do?

In the building industry, a wise Dutch architect Prof. Geert Bekaert said (somewhat free translation): "Architecture is not innocent, not without danger. It has the fundamental task to open up the reality, our reality to be able to create new and adventurous, uncertain opportunities. These opportunities will not create themselves, they need to be thought of like architectures". Every rule we put in effect helps us to form ideas about a new reality. But each rule also restricts what we may do. Because the IT-reality rapid change it is wise to only keep to the rules that are really the basis for our business, rules that really cannot be broken. Call them (business) principles. Re-think these rules regularly, because these may change in time. Every other rule, most design criteria etc. should not be made a principle. They are too volatile and may change with each new technology. Writing these kinds restrictions down too early will restrict your business in the longer term, and will reduce flexibility and agility.

Back to our question: if what is needed is known, how far should we document the future applications, data and technology architectures outside the creation of these changes of the infrastructure themselves? Is the answer: Not further then absolutely necessary until we really are going to change our IT-infrastructure?

Keep in mind that everything we put down in a target architecture limits our freedom to change to real different and effective solutions. This answer would mean TOGAF may be a good exercise, but do we really want to tell businesses to invest in the amount of detail it involves beforehand? It seems highly debatable.

Closing remarks

I am convinced The Open Group is a good forum of IT-vendors to have, and I really applaud their openness in bringing up and discussing issues. The above (and the following) is meant in this atmosphere, and I hope, although the content and conclusions are different from what is discussed in The Open Group, it will add to the development of thought in a positive way.

The Open Group presents itself as a vendor- and technology-neutral consortium. To me the consortium is a typical IT-vendor community, working on and from the IT-supply-side. It is very admirable of IT-vendors to make neutral agreements/standards to create order in the chaos of the IT-industry today.

Neutral is the word here, not independent. Neutral means that parties agree on a solution/standard. Independent means people are looking for the best professional solution, without taking commerce, business and the current status of product and services on the market into account. Now, neutral is difficult but at the end of the day: do-able. Independent is much more fundamental, and for that reason much more difficult. I do not expect anything independent will be presented by The Open Group. Neutral brings you a long way, and for that reason the efforts of The Open Group must really be applauded.

So The Open Group is a group of IT-vendors, working supply-side. There is a discussion on whether The Open Group should develop approaches (ideas, methods, techniques, tools etc.) for the demand-side. To go into that field would be a bad decision. In the past decades there were many attempts, and, as far as I know, all of them failed. Let me put it this way: better be (or become) a very good (or even the best) IT-vendor, then try to enter a quite different area and become a mediocre business and/or information consultancy. Doing both is in fact impossible because it will bring business problems and ethical issues with customers IT-vendors do not need or want.

An answer to the question put forward on Monday July 17th by Mulholland and Van Gelder of Capgemini in Miami: Development of real business concepts and issues and of true Business Architecture, demand side, is already done in other communities. It is true information science, also demand side, is more or less in its infancy. But this is also developed in other communities. Surely it would be great for IT-vendors to have proficient business and information in sales situations from the demand side. This would enable them to satisfy the needs of their customers/stakeholders better because they know what they want, and are able to formulate this need to their solution providers like their IT-vendors.

Connecting as consortium of IT-vendor to these other communities and not trying to do the work on demand-side yourself would be a really great idea. This would be the way to go for The Open Group. The Open Group may even try to stimulate the growth of these communities if they are hard to find, or are in a real infant state of development. Connecting and stimulating, not dictating or heavily influencing of course.

As an advice to The Open Group: stay and work on the IT-supply side as you are doing today, and enable IT-vendors in your consortium to be or become excellent in what they do is a perfect goal. This could really make a difference in this world if it is done in the open way you are already used to, today.

 

But I may be wrong! So: feedback is very welcome.



Do you have a reaction to the above? Please send it to me:
Your name:
Your E-mail:
Your reaction:
                               

A/I/M bv is able to help you develop and manage your information as a corporate resource. Want more information?


Copyright 1996 - A/I/M bv.®

Last changes: February 2nd, 2007

Architecture, Information & Management bv
Postbus 85142, 3009 MC Rotterdam
Fax: +31/0 84-223 95 44
Mobile: +31/0 6-533 22 595

 

You forgot to fill in your name