When it comes to an enterprise architecture framework, there are a wide range available to use. Horizontal ones such as TOGAF or Zachman, and vertically flavoured ones such as eTOM for the telecoms industry and BIAN for the banking industry. In all cases, they are useful and can provide value, but in every case, they are there to assist you, not to act as the driver for how to do enterprise architecture.
Many architecture initiatives fail because of a reliance on such frameworks. They either get cancelled or fail to deliver the expected business benefits, with teams becoming too wrapped up in the detail of capturing, populating, or forcing a frameworks’ approaches.
When selecting a framework, remember that you are using something that everyone else is too, so there is no competitive advantage, which is fine when dealing with non-competitive aspects of your business. However, when supporting innovation or business transformation, thinking beyond the standard frameworks will be required, so be flexible. In fact, this flexible approach is at the heart of how to successfully utilise a framework.
Frameworks are guides and suggestions, not methods and standards. Any framework you consider will need to be applied in both superficial and in-depth ways at the same time. Look carefully and always ask yourself if you really need to do this or populate that. Often it is simply enough to capture and store information in a repository – you can always go back and connect that information to other things later, or add more depth as business value dictates.
Lastly, don’t get caught in the trap of saying “we are doing TOGAF or Zachman; therefore, we are doing enterprise architecture.” Often, when I come across this, I find that people are doing IT architecture, not enterprise architecture – with most often the business architecture piece being done elsewhere in the enterprise. In which case, efforts to bring the two together are more important than worrying about a framework.
Read the whitepaper, “An Enterprise Architecture Communications Framework – Three Ways to Have Business Conversations About Technology,” for more ideas and insights.
Three Actions to Help Avoid the “Framework” Traps
- Don’t Let the Framework Drive Your Architecture. Many organisations start their enterprise
architecture efforts by choosing a framework and tool first, this is a mistake. By taking a tool and framework approach, you risk trying to frame all business or IT needs in terms that fit the framework, and indeed risk using language your colleagues may not understand. Instead, focus on the business outcomes and accept that your business may well need a combination of frameworks to best express their needs. By accepting this, you will also find that your tool needs change – no longer will it be sufficient to have a direct framework to tool match; instead, you will want to be able to manage multiple types of frameworks, and the interconnectivity between them. - Think Context and Communication When Using Frameworks. Frameworks are, for the most part, not designed to be complete or end to end. They are intended as a reference tool to frame questions, highlight gaps in thinking, or act as a means of filing information for future use. The ideal use of an enterprise architecture framework is to provide context for the work being undertaken and to act as a means of communicating issues, challenges, opportunities, and risks. When selecting a framework or frameworks, think about what and how you will need to communicate – be aware that different audiences have diverse needs. Don’t make the mistake of talking IT or technical terms to business folks. You should also remember that most of the enterprise architecture frameworks you come across have started out as IT architecture frameworks, so be cautious.
- Consider Capability Models Instead of Frameworks: From a business facing perspective, consider whether taking a capability management approach might be more effective. Business capability models have meaning and value when talking with the business, and can replace frameworks in many instances. A business capability is in effect a composite view, under which we might have data, process, organisations, and IT capabilities. By taking a capability based approach, you can reduce the overhead of framework in areas where it delivers minimal value and hide complexity from people who don’t need it. You can then choose a framework that is well suited to your IT needs without compromise and simply connect the two together.
