Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
In this eighth posting we will cover the topic of Enterprise Architecture Tooling. First we will explore the question what capabilities effective Enterprise Architecture teams need from tools, and list some characteristics that tools need to have in order to efficiently support Enterprise Architects. In the second portion of this blog we will address best practices that Enterprise Architecture teams can use to fully leverage the power of Enterprise Architecture tools.
Enterprise Architecture Roadmap for Success: part eight; Tooling
From previous postings in this series it has become clear that Enterprise Architecture has many aspects, and that the specific set of aspects to focus on greatly depends on the approach that an organization takes with respect to Enterprise Architecture. For example more strategic aspects in a top-down approach and more operational aspects in a bottom up approach.
But in general we could state that Enterprise Architecture is always about knowledge and communication. Enterprise Architecture brings together various perspectives, enabling integrated analysis on the current and future state of the architecture of the enterprise. This results in valuable knowledge that greatly enhances decision making, whether on a strategic or more operational level. This knowledge not only needs to be efficiently managed and maintained, it also needs to be communicated to the right stakeholder at the right time, and even more importantly: in the right format. An essential aspect in Enterprise Architecture is stakeholder communication. Enterprise Architecture has a diverse audience including business and technical backgrounds, and each of the stakeholders needs to be addressed in a language that is clearly understood.
This gives us directly a number of essential qualifications for Enterprise Architecture tools: rigidity when it comes to the management and maintenance of knowledge, and flexibility when it comes to the analysis (ad-hoc, what-if, etc.), presentation and communication of the knowledge to diverse audiences.
So what you are looking for is a tool with solid repository capabilities, and flexible modeling and analysis functionality:
In the tooling business there are many vendors, some of them claiming to offer one-stop-shop Enterprise Architecture solutions. Given the diverse functionality that Enterprise Architecture needs, and the myriad of approaches organizations take on Enterprise Architecture based on their priorities, a one-size-fits-all solution does not often seem the best choice.
Take for example document management capabilities to support Enterprise Architecture governance on the one hand side, and multi-faceted ad-hoc model querying to support complex design decision making on the other hand. When trying to cover both in one tool you don’t usually get the best of the both worlds.
Often it is better to select a small number of specialized tools that can be aligned so that together they support the full spectrum of capabilities that Enterprise Architecture needs. This can sometimes be found in a “tool suite” from one vendor. But if the organization wants more flexibility to choose the best tool, they usually end up with tools that support open standards so that they can be easily aligned with other components in the organization specific Enterprise Architecture tool set.
Enterprise Architecture Repository
TOGAF’s description and depiction of the architecture repository gives a good overview of what the architecture content is that needs to be created, managed and maintained in an enterprise architecture environment. The architecture landscape often consists of descriptions using models to express the architecture on various levels: strategic, segment, and capability. Other model content includes solution architectures in terms of building blocks, and a library with reference models. The models are based on the organization specific meta model. Other types of data in the architecture repository include architecture requirements, a library of standards, governance data and data describing the architecture capability itself.
The architecture repository is often a conceptual thing rather than a physical implementation on a single database. Often, a set of tools are in use in an organization to support various processes and management of various types of data. The tools are aligned, e.g. based on the structure suggested by TOGAF, so that together they form a complete solution supporting the Enterprise Architecture capability.
In this final part of this posting we want to address the actual use of Enterprise Architecture tools. In our practice we sometimes see organizations looking for off-the-shelve solutions that “do” Enterprise Architecture for them. It may sound as an open door, but in our opinion a tool should support enterprise architects so that they don’t have to bother about simple, straightforward, and activities with an administrative character. In that way, they can focus on the real design challenges that the organization faces: the activities with which Enterprise Architecture actually adds value to the organization. Talented and intelligent enterprise architects are those who ask the right questions, and who can reduce complexity with smart models. Tools should make the life of these architects easier by being flexible, supportive, and not imposing all kinds of cumbersome activities for simple tasks. Some Enterprise Architecture tools claim to automate the intelligent design work, and that Enterprise Architecture automatically “happens” once installed on the companies’ servers. In practice this is rarely the case. Effective architecture is all about the right architect using the right tool in the right way, or as we sometimes say: a fool with a tool is a still a fool making faster disaster.
Enterprise Architecture Fool with a Tool
If you’d like to know more, please contact the authors directly at firstname.lastname@example.org / email@example.com, or leave a comment. The next post in this series is about using consultants for building Enterprise Architecture practices. It is scheduled to be posted between 11th and 15th of March.