Enterprise Architecture Requirements
Globalization, increasing regulation, and faster cycle times demand that an organization has the ability to quickly change its business processes. Business agility is becoming a strategic necessity. One of the key methods to achieve business agility is to have a well defined enterprise architecture. According to research conducted by Jeanne Ross, Peter Weill, and David Robertson in their book, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution (2006),
“Companies with a foundation for execution supporting an operating model (e.g., well defined enterprise architecture) reported 17 percent greater strategic effectiveness than other companies—a metric positively correlated with profitability. These companies also reported higher operational efficiency (31%), customer intimacy (33%), product leadership (34%), and strategic agility (29%) than companies that had not developed a foundation for execution.”
However, for many companies, the term architecture has a negative connotation. Many companies have questioned the value of their architecture initiatives and viewed them as IT theory isolated from business reality. This is unfortunate, but there are several reasons why defining architecture has been nothing more than a worthless training exercise for many companies. The two main reasons are that the enterprise architectures are not connected at the top with an operating manual and not connected at the bottom with a solid requirement management process. Let’s address both of these issues.
An operating model describes how a company will grow and prosper. The choice of an operating model is a critical corporate decision. The operating model enables rapid implementation of a range of strategic initiatives, but that same operating model will fail when initiatives are undertaken that are not based on the assumptions of the operating model. Selecting an operating model is a tough decision and is a commitment of doing business a certain way. The operating model decision should drive how an organization implements business processes and IT infrastructure.
Enterprise architectures that are developed without choosing an appropriate operating model will not work. An operating model has two dimensions: business process standardization and business process integration, which are represented as the x and y axis of a matrix. Process standardization delivers efficiency and predictability across the company. Integration links the efforts of organizational units through shared data. The table below illustrates the four types of operating models. After reviewing this matrix for only a few minutes, it is easy to see why organizations which embark on implementing an enterprise architecture without first defining and obtaining a clear understanding of their operating model often end up with worthless piles of paper.
There are many frameworks for defining Enterprise Architectures including:
- The Zachman Framework for Enterprise Architectures
- The Open Group Architecture Framework (TOGAF)
- Federal Enterprise Architecture (FEA)
- NIST Enterprise Architecture Model
- Gartner Group
The two most used are probably the Zachman Framework and TOGAF. The Zachman "Framework" is actually a taxonomy for organizing architectural artifacts (design documents, specifications, and models). It takes into account both who the artifact targets (for example, business owner and developer) and what particular issue is being addressed. John Zachman, the creator, retrospectively described his work:
“The [Enterprise Architecture] Framework as it applies to Enterprises is simply a logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of the Enterprise, as well as to the development of the Enterprise's systems.”
TOGAF describes itself as a "framework," but the most important part of TOGAF is the Architecture Development Method, better known as ADM. ADM is a methodology for creating an enterprise architecture. TOGAF complements the Zachman framework; Zachman tells you how to categorize your artifacts; TOGAF gives you a process for creating them. TOGAF addresses four levels of architecture:
- Business process architecture
- Data architecture
- Applications architecture
- Technology architecture (infrastructure services and the technology).
The diagram below shows a high level view of the TOGAF’s Architecture Development Method (ADM).
Note how Requirements Management is at the center of the process and indicates that the ADM is continuously driven by the requirements management process. Requirements Management is the glue that holds all of the other processes together. It is important to understand that the Requirements Management balloon does not represent a static set of requirements. Instead, it represents a dynamic process whereby requirements for enterprise architecture and subsequent requirement changes are identified, stored and used by all other ADM phases. The ability to deal with changes in requirements is crucial to ultimate success. Architecture is an activity that is driven by constant change as the business changes to address competitive challenges, economic swings, regulatory changes, and mergers and acquisitions.
TOGAF does not mandate or recommend any specific requirements management process or tool. It simply states what effective requirements management should be. The Enfocus Requirements Suite™ from Enfocus Solutions is one of the few requirements management tools on the market that responds to the TOGAF requirements management process. The Enfocus Requirement Suite™ allows requirements to be captured by business process and IT service components (application, data, and infrastructure), has powerful change management capabilities and keeps a history of all requirement changes made to the processes or IT service components. To find out how Enfocus Requirement Suite™ could help your organization, please download our fact sheet below.
