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.