In an earlier blog post I said that each profession has its unique way of doing things, and that when applying TOGAF® the key thing is to “think” like an architect! The first step is to think holistically, and to do this you need to take into account the views and viewpoints of all stakeholders. But what other steps can you take to think as an architect?
TOGAF defines a view here as “the representation of a related set of concerns,” which is all very well, but what is the best way of creating this? Again, the key point is to remember to think like an architect! And fortunately there are many things in the TOGAF documentation to help you. In this blog I’m going to give you a few more pointers to put you in the right direction.
Before I list some of the key things that will help you to think like an architect, I want to stress that TOGAF doesn’t really make a clear distinction between using architecture techniques, as opposed to using techniques from other management disciplines.
TOGAF actually refers to many techniques that come from other disciplines. For example, it relies heavily on stakeholder management, risk management, business scenarios, communications plans… even capability-based planning, which are commonly used by other professionals such as analysts, strategists, project planners, or business managers. The key difference is one that TOGAF doesn’t emphasize enough. These are all useful techniques, and they are useful to many different professionals, but when an enterprise architect uses them they must relate, in some way, to architectural thinking. The key difference is that when you use stakeholder management, business scenarios or capability-based planning you need to think like an architect.
In a rough order of priority, here are my top three tips on how TOGAF can help you think like an architect if you:
- Use architectural language. You need to become familiar with the terms defined in TOGAF. You need to spice your conversations with these words. Of course you need to use them appropriately, and don’t confuse your audience with unfamiliar words. But do use them to guide the conversation towards an architectural way of thinking. In my story about the meeting at the start of this blog, that would include separating out the alternative views and viewpoints of each type of stakeholder, and using these to emphasize that, from an architectural perspective, all views have to be addressed.
- Refer to the Architecture Development Method (ADM). The ADM provides the bulk of the TOGAF documentation, and yet surprisingly few enterprise architects refer to it very often. The trick is to use it to guide conversations and debate – don’t use it rigidly and don’t keep forcing it on others. Use it instead as a reminder of the balance between the architectural understanding of an enterprise (phases A to D) and practical considerations about how the enterprise will use investments, resources and solutions to improve the architecture (phases E to H). So often, as in my example, the debate centres on the latter phases. Decisions are made about opportunities and solutions (phase E), with little or no consideration of the architecture vision (phase A), or the current or potential business, information systems and technology architectures (phases B, C and D).
- Apply a core set of principles. Principles are often overlooked, but they are arguably the simplest and easiest EA technique to apply. Even if there are no principles already defined, it is pretty easy to come up with a starter kit to help guide architectural debate. For example, does your enterprise prefer to buy or build? Does it prefer to have integrated or standalone components? Gradually extend these simple principles to cover more complicated or partisan concerns, such as whether architectures are common across business units, or how projects share resources and costs.
Use the tips and ideas that I have given here and it will help you to focus on being an architect. The key point is to use architectural techniques in preference to those from other disciplines.