Introduction: Our Perspective
We are introducing this column to explore the transition that is occurring in business: managing complexity that exists in the business environment with enterprise architecture. Our premise is that a business has either an explicit or implicit enterprise architecture. For example, an organizational chart is one explicit representation of an architecture component, which is part of a larger architectural rendering of an enterprise. Another explicit architecture might be the depiction of the business’ value chain of business processes being used, also considered to be part of the larger architectural rendering. Implicit architectures are all too often NOT made explicit, which causes rigidity, chaos, entropy, and complexities that impact the effectiveness and efficiency of doing business. All of these renderings and their understanding are subject to skeptical review.
The “Skeptical Architect” can assume various positions on different architectural topics and perspectives in business. For example, there are a lot of roles related to architecture(s). We expect business professionals to use architecture for direction and structuring of the enterprise. We also expect business analysts to focus on the development of business components and business architects would be concerned with the business’ ability to operate successfully. Then, the data architect should be concerned with the basic understanding, meaning, format, and consistency of data to ensure interoperability of information and data throughout the business. Finally, Management Information Systems, the Information Technology organization, or IT management should certainly focus on IT’s structure, processes, and services while IT architects focus on driving digital interoperability required for today’s electronic business. Who defines these roles and what constitutes a best practice?
Today, the problem is the number of divergent opinions surrounding what constitutes an architecture as a discipline. As a result, we have multiple methodologies, multiple artifacts, and multiple claims of value to the extent it dilutes the value of architecture as a discipline. Consultants, vendors, and academics all profess to have the “Silver Bullet” or “Rosetta Stone.” Therefore, we maintain the position of a “Skeptical Architect.”
Goal of This Column
Given that many of us are skeptical architects, our goal to provide a forum for realistically assessing and providing insights about the discipline of architecture. A secondary goal is to provide a better understanding of the business impact and value of architecture to the enterprise.
Here is a “dirty dozen” starter set of questions that we hear from clients and architects:
-
When and why do you need an architecture methodology?
-
What’s wrong with the way we’ve been doing it?
-
Which graphical representations fit the organization best?
-
Is architecture becoming a formal discipline such as engineering? Are there multiple disciplines necessary as in engineering?
-
Who is the ultimate consumer of architecture – the client, management and the leadership, or the worker?
-
Where is architecture applicable in delivery of products and services?
-
Do we know enough about architecture to make it a discipline?
-
What kind of analytics are necessary to deliver good architectures?
-
Are there a set of principles for architecture development such as between science and engineering?
-
When is architecture required to support the business’ development?
-
When is an architecture complete?
-
How do we know when we have a quality architecture?
It is in this spirit that we seek to provide a platform for proactive discussion on the value of architecture(s) to various audiences who are engaged in developing, delivering, and supporting enterprise architecture.
Architecture, Wherefore Art Thou?
There is a profusion of terms that are used to describe ‘architecture’ today. The terms depend on whether you are on the business side or the IT side of the fence. It is time to understand these terms better and perhaps resolve how they fit together and relate to each other.
‘Architecture’ as applied to organizations is replete with confusion and contradiction. Start with the basic term used….architecture… should we say business architecture (the business focus) or enterprise architecture (the IT focus)? Both terms (and a few others) have proponents and detractors, definitions, interpretations and the ‘correct’ viewpoint. If the ‘architecture frameworks’ are examined (e.g., The Open Graph Architecture Framework [TOGAF], Department of Defense Architecture Framework [DODAF], etc.), we see that they are mainly methodologies. The exception is the Zachman Framework, which is a real framework and the progenitor of the term enterprise architecture. Methodologies are designed to get the artifacts needed to build a computer-based, automated system. And yes, they are linked into the business but that may not make them business architectures. Methodology is good as it gives steps for getting the work done. Here are two assertions about architecture terminology to consider:
-
Business architecture – The primitive components (categories) of a business (organizations, locations, processes, decisions, systems and so on) identified and instantiated with occurrences, relationships between the instances of a category (primitive or like models where the instances are all form the same category) and eventually relationships across 2 or more categories (composite or unlike models where instances are form multiple categories) such as a process model with swim lanes. Methodologies that support business architecture are open (general artifacts like matrices and flow and trees across all categories) and have analytics that permit the analysis of impact of mergers, acquisitions, divestitures, consolidations, systems and other actions that impact the structure of the business itself. In terms of the Zachman Framework, business architectures focus on the first two rows overlapping the third.
-
Enterprise architecture – A combination of primitive categories and primitive models (e.g., entity model) and composite models (e.g., data flow) that form the requirements for a computer-based automated system. These models form the structure of what is now called ‘the digitized’ business. These models include a linkage into the business usually via processes and, in many cases, strategies and other parts of the business. Methodologies that support enterprise architecture are closed (but extensible within the methodology) and designed to produce the deliverable artifacts that are needed to define a system and the relationship of that system to parts of the business. In terms of the Zachman Framework, for example, these methodologies focus on the lower three rows with tentacles up to the first two rows. A better name might be “Enterprise IT Architecture.”
If these look similar it is because, in reality, the ‘enterprise architecture’ is a subset of the ‘business architecture,’ although the terminology seems to imply the opposite. There is clearly an inconsistency in how we name these architectures. Naming usually follows the discipline that uses the architecture. As a result, what really is an ‘enterprise IT architecture’ has become the term ‘enterprise architecture’. It is time that we sort out this terminology use.
There are methodologies on both the business architecture side and on the systems side. In the case of business, there are more than 65 management disciplines of which about 60 are documented in the book Key Management Models (van Assen, van den Berg and Pietersma, Prentice Hall, 2nd edition 2009). These management disciplines are enterprise wide or focused on particular aspects of the enterprise such as functions (e.g., HR, Finance, etc.) or concepts (e.g., Value Chain, Value Based Management, Balanced Scorecard and so on). IT has yet to achieve this volume of methodologies. Surprisingly there are no IT methodologies or systems methodologies included. In fact, the only mention of technology is for such things as technology forecasts that might include IT. Nor is there any mention of enterprise analysis as a methodology to work with business architecture. IT has yet to achieve the volume of methodologies (and tools) available to business managers.
Systems and related methodologies are extensive in the types of models and how they are grouped into various methodologies. These methodologies follow a historical chain based on methods, tools and ideas that have emerged from software development maturity over the last 50 years. These range from basic flowcharting methods to system development lifecycle approaches, information engineering to object approaches, and finally to the TOGAF and other methodologies we have today. These all represent how requirements for a system are gathered, how a system is built and how it connects to the business.
With the Zachman Framework dealing with primitives, and work done in enterprise analysis that deals with variations of lists of primitives, models of primitives and simple business composite models, we have an overarching approach to integrating the business and the IT views.
All this points to a need to articulate some idea of a taxonomy of architectures and a better use of terms.
It would be useful to clear up the use of terms and give some idea of the structure and relationship of architectures we work with today. In all fairness, IT was first to look at an enterprise-wide view and hence adopted the term ‘enterprise architecture.’ So, there is a lot of intellectual capital invested in the term and it may be difficult to change. But, it’s necessary to define the scope of the terms to avoid ambiguity. For example, the term organization in the European Union and the Middle East is synonymous with the use of the term enterprise in the U.S.
Our thought to distinguish this difference is a simple suggested starter structure:
Notice that the organization architecture is either implicit or explicit. The term Organization Architecture is neutral and can apply to both public and private organizations. Effective enterprise-wide IT architecture needs to be explicit since it provides the knowledge of how the organization’s automation is delivered. The enterprise-wide IT architecture includes multiple types of architectures: application, data, communications, and infrastructure (including hardware, middleware, operating systems, database management systems, etc.).
Executive leadership and management need a clear precise terminology to understand the implications of architectural efforts. A structure like this allows for simple communication of the different architectures over time. Two key points we’re making about the communication of architectures are that they should:
-
Be simple and direct
-
Provide insight into the implications of business change
