All this complexity, risk, and opportunity need to be intimately understood as it relates to business. That is precisely how enterprise architecture came to be. Enterprise Architecture (EA) was born out of the need to manage complexity by organizing the business, or enterprise, into comprehensible views that provide visibility into how the components of the enterprise were connected and worked together.
The problem with enterprise architecture as a concept was that there needed to be some way to organize, classify or catalog these components. This taxonomy, or ontology, not only needed to be comprehensive, it needed to be scalable, and more importantly, portable. In other words, businesses didn’t want to completely “reinvent the wheel” every time there was a change in the market, the operating model, or even a change in employees. So frameworks were created. Besides, in the enterprises of today, digital transformation, technological disruption, and business agility have forced frameworks and enterprise architecture to evolve.
The formalization and codification of Enterprise architecture into a framework includes the description of the object using terms and concepts that make up the business. The framework also includes the definitions of those terms or concepts; a taxonomy, which categorizes those terms or concepts; a method, which describes the use of this taxonomy; a common vocabulary, enablers, or capabilities, which define how these concepts and methods are implemented; and objectives or outcomes of these implementations. This collection of management tools, processes, components, and key performance indicators (KPIs) makes it possible to render the enterprise using comprehensible, digestible views, thereby enabling the business to see itself as it is, as it could be, and how it progresses to the anticipated future state.
The framework provides the mechanism and the rules for how components are connected and interact, as well as how these connections are presented for consumption for decision-makers. The framework ensures consistency and reliability so that decision-makers not only know how they can consume this information but that they can trust in the validity of the data.
With the need for an EA framework understood, the question becomes: “what Enterprise Architecture framework to adopt”? understanding the evolution of EA frameworks will provide some context for better making that decision.
When the topic of EA frameworks comes up, all EAs pay homage to the pioneer of EA frameworks, John Zachman, who in 1987 while working at IBM*, developed the Zachman Framework. The Zachman Framework is really more of an ontology than a framework, but it is the go-to for the classification of descriptive representations (models) that constitute the enterprise architecture. The classification uses the six primitives (who, what, why, when, where, and how) to describe these models.
Later, in 1990, John Zachman teamed up with Samuel Holcman where they founded the Zachman Institute for Framework Advancement. In 2008 this institute was dissolved, Samuel Holcman went on to found the Enterprise and Business Architecture Center of Excellence, and John Zachman, in 2012, acquired the FEAC Institute where he incorporated executives from the Zachman Institute, the Federal Enterprise Architecture Framework (FEAF), the Finnish Enterprise Architecture Framework (FEAR), and the Department of Defense Architecture Framework (DODAF / DOD Architecture framework).
Over the last thirty years, one Enterprise Architecture framework has risen to become the most popular EA framework. That framework is The Open Group Architecture Framework or TOGAF. The Open Group was created in 1988 to form a consortium that seeks to enable the achievement of business goals through the development of open, vendor-neutral technology standards. The Open Group grew to over 650 active members, who create standards for the field of computer engineering. Through this effort, the Open Group created ArchiMate, a model that breaks down systems into active structures, passive structures, or behaviors.
TOGAF is currently in its tenth version, but the most widely recognizable feature of The Open Group’s TOGAF is the ADM, or Architecture Development Model. This model uses a cyclical approach to the development of architecture. The cycle consists of developing a vision; defining the business, application, data, and technology domains; planning; managing change; deploying; and governing the architecture while maintaining the requirements as a central focal point. The ADM outlines and classifies specific deliverables associated with each of the phases.
There are many Enterprise Architecture Frameworks, but some popular frameworks over time include:
There are many other frameworks: DODAF, The Common Approach, FEAF, MODAF, DNDAF, NAF, and UAF to name a few. Each of these has a specific orientation and is used by organizations to accomplish a standardized, consistent approach to developing an enterprise architecture that is consumable by the business or organizations they support.
Every industry vertical has its own specificities, and not surprisingly, there are frameworks that address EA for these. ACORD (Association for Cooperative Operations Research and Development) is specific to the insurance industry. BIAN (Banking Industry Architecture Network) is specific to banking, MMOSA for manufacturing, and on and on.
One organization that is focused specifically on business architecture and the development of reference models for common areas that span all industries, as well as industry-specific reference models, is the Business Architecture Guild (The Guild). The Guild developed the Business Architecture Body of Knowledge (BIZBOK) which provides a comprehensive framework for business architecture in general as well as basic, industry-specific reference models that are easy to implement.
Creating an enterprise architecture is an arduous task, but it can be facilitated by using an Enterprise Architecture framework, however very few companies actually deploy a complete EA framework. Due to the exhaustive nature of these frameworks, implementing a complete framework is expensive and resource-intensive. Not only must the framework be implemented, but it must also be maintained.
For these reasons, most companies adapt a framework, or even cobble together parts of different frameworks, in order to meet the needs of their business and provide value. In these cases, EA frameworks are used more than guidelines instead of rigorous standards and practices. Selecting the right framework concepts or practices is important in ensuring that the company will get value from enterprise architecture and that practitioners will utilize the framework. Understanding the context behind EA frameworks is essential in helping to make that decision.
Knowing how Enterprise Architecture frameworks progressed to where they are now, their strengths and weaknesses, and how the strengths of each one can best be applied will provide information that will allow businesses to adopt or adapt an EA framework that will provide the complete visibility needed to help the business manage the complexity inherent in business today.
One of the most common complaints of the traditional enterprise architecture function is that it does not keep up with the pace of change. It does not facilitate agility. The development and adoption of the Agile methodology have done more to force enterprise architecture to change its approach than any other force in the business. Businesses must be able to rapidly change course, account for technological disruption, develop new capabilities, or enhance the customer experience of existing capabilities.
Fortunately, recent technological advancements have enabled the automation of architecture processes. Enterprise architects can now focus on exploring emerging technologies and innovation, build reference architectures for these, and help set and achieve strategic business objectives. To do this, though, enterprise architects must understand more than just technology. They must understand the business and how technology enables that business.
Agile methods solved some very specific problems. Projects had very high failure rates. Either the stakeholders were not getting what they expected, or time to value was not keeping up with the rapid pace of change in the marketplace. Also, many projects experienced heavy technical debt, causing enormous downstream costs when technologies were no longer viable and had to be updated. The results were inevitable immobility.
Changing the organizational structure by breaking the pyramidal hierarchies and focusing on interactions between individuals more than on processes and tools, changes could be more rapidly implemented thus allowing rapid changes in direction and development of user-friendly functionality. This organizational revolution did not come without risk. Small agile teams may be able to make rapid changes and adjust to meet changing requirements, but the absence of the traditional pyramidal structure means that the big picture is no longer seen. The collection of teams loses the perspective of a common goal and simply iterates on details that no longer contribute to the value of the original effort.
There is no argument against a need for agile thinking. Due to rapid technological advancement, where barriers to entry of new products in the marketplace are virtually non-existent, and where market shares are frequently redistributed, there is a strong need for a variable adjustment. This variable comes in the form of Agile @ Scale. One of the most popular examples of agile @ scale is SAFe (Scale Agile Framework). SAFe was designed in 2011 by Dean Leffingwe. This framework has shaken up traditional architecture. Not only does SAFe integrate with architecture frameworks, but it also allows the application of the methodology to larger groups that can work effectively without dispersing and according to an overarching plan. The purpose of SAFe is not to manage a project but to build a product. The product is decomposed into functionalities or capabilities instead of requirements. This provides a faster customer feedback loop and avoids the costs of delayed product launches.
In the current transformative environment, companies are experiencing disruption and modernization in not just product offerings, but in management and organization as well. Employees now operate in an enterprise rife with complex systems, horizontal and matrixed communication channels, and stakeholders who do not work with traditional mechanisms of hierarchical authority.
The command and control management espoused by Taylorism has been challenged by new methods of problem-solving that have manifested in new management and organizational structures.
These methods have led to the transformation or elimination of traditional roles such as business analyst and project manager. The shift to more design thinking has led to a growing interest by business unit employees in the concepts of enterprise architecture. This has contributed to the decentralization of the enterprise architecture function and the relegation of the enterprise architect to the role of a coach in the art and/or science of enterprise architecture.
Another transformation of enterprise architecture is already underway, the expansion of enterprise architecture beyond the confines of IT. Enterprise Architecture is permeating the business. This expansion stems from business people who know that for all intents and purposes, their companies are technology companies. This also means that for business to function at a high level, it is necessary for architects to have a deep knowledge of technologies, know-how these technologies are applied to business capabilities and functions, provide a master repository of architecture components and relationships, and maintain a common architecture methodology.
Businesses will always need enterprise architecture, but enterprise architecture will need to adapt to the new models for organization, management, and especially product development. Customer-oriented, modular design is speeding up time to value and enterprise architecture frameworks must be able to facilitate this type of approach. Enterprise architecture frameworks must also be extensible.
New advancements in the integration or layering of risk and compliance onto the enterprise architecture have proven to be catalysts for the evolution of EA frameworks. Companies want to be able to assign risk to components where risk exists. These risks need to be aggregated by the system, process, organization, capability, product, etc. The same can be said for regulatory requirements. With the advent of privacy law, enterprises need to understand where data starts, moves, is processed, consumed, and stored. Application of risk and compliance further the comprehensive scope of enterprise architecture.
So yes, traditional enterprise architecture frameworks need to be renewed to accommodate scaled agility, risk, compliance, innovation, etc. Enterprise architecture frameworks must enable the development of MVPs (minimum viable products). Most importantly, enterprise architecture frameworks must provide that convergence of all aspects of the enterprise.
Now, enterprise architects need to become business partners that account for all components, perspectives, and aspects of the enterprise and provide a method that helps every stakeholder understand not only the area in which they operate but also the enterprise picture of where a company is, where it wants to be and how it will get there. With it, enterprise architects will become trusted advisors helping their organization to become more lean, agile, and resilient.