There is something special in every discipline – things that are not covered by other branches of learning. As EA practitioners we are selling ourselves short whenever we overlook or play down these unique aspects of our profession.
The question also comes up in client engagements: what is it that enterprise architecture provides that I can’t get from IT, or BPM, or strategy planning?
So what is it that makes the field of EA distinctive or unique? Here are 5 ways in which EA is distinctive and inimitable – they are the topics that are uniquely addressed by EA:
- Complexity
- Architecture
- Time
- Adaptability
- Differentiation
To make it easy to remember them, and because architects always like a good acronym, these five topics can be contracted as “CATAD”.
Let me explain why it is so important to play up these five unique aspects of our profession.
Complexity
Of all the disciplines used in management, business and IT, EA is the only one that covers everything! Every single component that makes up an enterprise has the potential to be architected. Successful EA covers management components like strategy, organization structures, personal skills and competence, and capabilities; it deals with business components such as products, services, processes, events, and rules; and it handles technical components such as applications, interfaces, software, communication networks, and computing hardware.
This is a vast territory! Covering all these components makes EA a very complex discipline. Good enterprise architectures need to be familiar with management, business and IT; they must be able to work with a wide variety of stakeholders at all levels within and outside of an enterprise.
The only way to manage this complexity is to have techniques that allow us to consider the enterprise architecture holistically while also being able to break it down or segment it into manageable chunks. The enterprise architecture is a representation of an enterprise – which is seen as a system, or more accurately a system of systems. This is why effective EA practice explains the constraints or capabilities of a system enterprise by demonstrating how architecture components and their organization limits or enables the strategies or needs of an enterprise.
It is because of the inherent complexity in an enterprise architecture that we need techniques such as strategic themes and vectors to guide large numbers of disparate projects towards an overall architectural vision. EA also has to be good at explaining the various alternatives available for sustainable architectural evolution so that decision makers can prioritize, understand trade-offs, choose one option over another. And it is because of this complexity that architects need to be masters at using viewpoints and views to present the architecture to each stakeholder in a way that makes sense to them.
Architecture
The second topic may appear to be either too obvious or it may look as though I’m trying to dodge the question! But the main subject matter for EA is architecture – in particular, enterprise architecture.
Far too many enterprise architects overlook this simple point: I’ve come across many “architects” who are doing IT development, but there are even more architects who don’t explicitly make the connection between stakeholder concerns and the architecture! Unless you spell out exactly how the architecture limits, constrains or enables the needs of the enterprise, you are not architecting. Without a clear, overt, plain explanation of how the architectural context fashions and produces the concerns of stakeholders, we are simply gathering requirements!
Architecture frameworks are so important because the subject matter of EA is architecture. This is also why your architecture framework must be tailored and adapted to meet your specific needs. Each enterprise architecture is unique; it may have components that are similar or identical to those in other organizations, but their configuration and use is totally distinctive (see the last of my five unique topics). And so architects must produce architecture frameworks that match that uniqueness and that are suitable for addressing stakeholder concerns.
This is very different from other disciplines where a general management framework is often applied in all situations – think of Michael Porter’s Value Chain Model, or the Business Model Canvas. By contrast, an enterprise architecture framework should always be customized to correspond with the enterprise architecture.