TOGAF ADM reactive

The Reactiveness of the TOGAF Architectural Development Method (ADM)

Published: October 14, 2014
Share on:

Recently a client raised their concern that the ADM was too reactive. They felt that by following the ADM they were always waiting for a stakeholder to raise a Request for Work (in the Preliminary Phase) instead of taking a more proactive stance by suggesting works that needed to be done.

This is an easy mistake to make. One of the weaknesses of TOGAF is that there are many things hidden in the shadows. There is a lot of good EA practice in the TOGAF documentation, and this is all highly visible – it’s out in the bright sunlight! So if you are relatively new to enterprise architecture and using the TOGAF documentation as your guide, you are likely to closely follow step-by-step in the path of the ADM.

It’s a bit like visiting a city for the first time and exploring it using a simple guide book. You are likely to see the most popular sights, but you may not really get to “know” the place well. You may accidentally stumble across some interesting back streets, or discover some of the special places known to locals and knowledgeable visitors. But on your first trip you are only going to come back with a first impression of the real place.

Accredited Training Courses

With TOGAF it is the things that are not written down – but that an experienced enterprise architect knows – that cause the most confusion or problems with first time users. In this case, following the process of the ADM it would certainly appear that the architecture team are sitting around drinking coffee and waiting for a sponsor to walk through the door with a bunch of concerns.

But EA isn’t, and shouldn’t be, like that! A good enterprise architect has insights and ideas drawn from their specialist knowledge and using their unique professional skills that should certainly be a key contribution to architectural initiatives. Here are the main places, hidden in the shadows of the ADM, where the EA team should be proactive:

  • The first point is that although you might be using the ADM for the first time, the process of architectural change will already have been going on, and probably has been for some time. The only difference is that the enterprise is starting to follow a particular methodology for architecting.What the ADM doesn’t emphasize is the need to find out more about what architectural changes have taken place in the past, and what architectural changes are currently ongoing. Finding this out is your first clues to being proactive.
    • Ask what future options did earlier initiatives create? For example, the introduction of a data warehouse might be an opportunity to re-architect senior executive key performance measures.I recently worked with a company that had badly defined measures with conflicting figures coming from different sources; so when senior execs got together from different divisions it was impossible to compare future business projections! The recent purchase of a data warehouse to help marketing was a great opportunity to suggest improvements to key performance indicators.
    • Ask what didn’t go so well in the past? One company had tried to rationalize the application landscape without any real architectural insight. The result was rather random, upsetting business users when useful functionality was unexpectedly removed. Again – a great opportunity to propose a truly architected simplification.
    • Ask what artifacts are already available? For example, one company had tried enterprise architecture previously, but abandoned it after a few years.When they set up an EA team for the second time, they didn’t know about valuable catalogs of some key components, such as applications or processes. They also didn’t know that the company had bought useful industry reference models from a vendor, and some considerable cost!
  • The next thing is to make sure that your role is not purely passive. Certainly you need to have sponsors; of course you need to address genuine stakeholder concerns. But you don’t need to only listen. Instead, build on what you are hear:
    • TOGAF talks about stakeholder “concerns” and architecture “requirements”, but it doesn’t emphasize enough how important it is to translate concerns into an architectural understanding. To do this means explaining a concern in terms of the limitations and constraints imposed by the current architecture, and the possibilities and options provided by a target architecture.As soon as you relate constraints and options to architecture components and their structure you open up a proactive debate about possibilities, and many of these will not be within the original request for work.
    • TOGAF has a whole phase (A) devoted to creating an Architecture Vision and producing a Statement of Work. But again, if you simply follow the ADM it looks as though this is a very passive request and response.In fact this is a great opportunity to be more proactive. This can be done in many ways – by thinking creatively and not just providing an out-of-the-box response; by seeing beyond the immediate concerns and showing how they can be addressed in the short term while introducing future architecture options that could be developed later; or by seeing opportunities for collaboration with other stakeholders and developing a combined response that gives more than was expected.The key thing is that a good Architecture Vision is exactly that – a vision: farsighted, imaginative, ambitious, and marvelous. It can go beyond the immediate request, because that can still be met as a Transition Architecture on the road-map to a greater Target Architecture.

I could go into more detail, but I’m hoping that I’ve opened up some ideas for using TOGAF in a positive and proactive way. EA should never be simply reactive!

More Free Resources