Four main EA approaches will be briefly discussed here: The Zachman Framework, TOGAF, FEA, and Gartner EA Framework. The goal of the five FEA reference models is to give standard terms and definitions for the domains of enterprise architecture and, thereby, facilitate collaboration and sharing across the federal government.
The FEA Problem Statement
"Suppose the Internal Revenue Service (IRS) decides it needs a demographics system to track taxpayer data. They ask around to see if anybody has one they can modify for their purposes. Nobody does. Little do they know that, right next door, the Government Printing Office (GPO) has a perfectly good demographics system that is almost exactly what the IRS needs. They just happen to call it a customer-analytics system." The IRS builds its system from scratch, instead of just modifying the one already built by the GPO. And, in doing so, the IRS will waste considerably time and resources."
History of Software Development Complexity Leading to EA
Enterprise Architecture addresses two problems in the development of Software Systems; the complexity of the systems and the need to keep these systems in synch with the changing business needs. As the complexity of the PC development environment exploded with the introduction of the Windows PC operating system, development costs went up sharply in the 1990s. Also the number of people able to develop system decreased significantly. When the business owners needed changes or new systems for new business areas, the price tag was suddenly much higher. Hardware was cheaper but software services was more expensive.
It is the maintenance of custom software which becomes expensive, especially when users suddenly demand the latest technologies. As storage capacity and processing speed increased substantially, the automation of many manual processes became possible for the first time in the 1980's. This gave rise to many applications being written on mini-computers and main frames. Now called legacy systems, they are wrongly derided for a lack of complexity. Although the field of Computer Science was somewhat new then, most of these systems functioned very well, but usually only addressed the business needs of one or two departments at most. A lack of funding for proper system documentation and the turnover of personnel made maintenance difficult. When Pocks became common on desktops in the early to mid 1990s, acquisition costs of a computer went down sharply from the price of a minicomputer at $80,000 to the cost of a PC at $3000. Suddenly we could do more cheaper. Organizations set their sights on much more complex goals of integrating the process and data flows of not just several departments but the entire organization. Requirements gathering became much harder as few people or no one at all had the entire picture of what the new enterprise wide IT systems needed to do. Gaining consensus on functional processes became overly time consuming for the budgets allowed. By the time a thorough analysis was done, management was off reorganizing and reacting to new events, rendering the early requirements gathering phase to be out of date. Or even worse, IT people were not allowed to speak with the users who knew the requirements. Commercially, business that merged or acquired new companies faced severe integration and growth challenges.
Enter the Enterprise
As Mom and Pop shops declined and giant marts replaced them, inventory, ordering, warehousing, distributed systems, logistics, financial reporting all expanded beyond what was trackable manually. To handle the complexity, "Zachman proposed that there are six descriptive foci (data, function, network, people, time, and motivation) and six player [or stakeholder] perspectives (planner, owner, IT designer, builder, subcontractor, and enterprise.) These two dimensions can be arranged in a grid". His multiperspective approach to architecting systems is an enterprise-architecture framework.
Common EA Methodologies
The majority of IT architects in the field use one or a combination of these four EA methodologies:
Described as a framework or matrix into which we put a taxonomy of relationships. Each cell in this matrix owns unique artifacts. SOA artifacts live in row three, the designer's row.
Although called a framework, is actually more accurately defined as a process.
TOGAF divides an enterprise architecture into four categories, as follows:
- Business architecture - Describes the processes the business uses to meet its goals
- Application architecture— Describes how specific applications are designed and how they interact with each other
- Data architecture — Describes how the enterprise datastores are organized and accessed
- Technical architecture— Describes the hardware and software infrastructure that supports applications and their interactions"
Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture. It has both a framework and an architectural process. A segment is a major line-of-business functionality, such as human resources. There are two types of segments: core mission-area segments (e.g. healthcare) and business-services segments (financial). Segments and services here do not correspond to SOA services.
FEA consists of five reference models, one each for performance: business, service, components, technical, and data. It is true that FEA has these five references models, but there is much more to FEA than just the reference models. A full treatment of FEA needs to include all of the following:
- A perspective on how enterprise architectures should be viewed (the segment model)
- A set of reference models for describing different perspectives of the enterprise architecture (the five models)
- A process for creating an enterprise architecture
- A transitional process for migrating from a pre-EA to a post-EA paradigm
- A taxonomy for cataloging assets that fall within the purview of the enterprise architecture
- An approach to measuring the success of using the enterprise architecture to drive business value
Can be best described as an enterprise architectural practice". To them architecture is a verb, not a noun, and it is a more organic process of working collaboratively with people. Gartner believes that enterprise architecture is about bringing together three constituents: business owners, information specialists, and the technology implementers. If you can bring these three groups together and unify them behind a common vision that drives business value, you have succeeded; if not, you have failed. Success is measured in pragmatic terms, such as driving profitability, not by checking off items on a process matrix.
"Zachman tells you how to categorize your artifacts. TOGAF gives you a process for creating them."
Terms for EA
One whose responsibility is the design of an architecture and the creation of an architectural description.
A specific document, report, analysis, model, or other tangible that contributes to an architectural description.
A collection of products (artifacts) to document an architecture.
A skeletal structure that defines suggested architectural artifacts, describes how those artifacts are related to each other, and provides generic definitions for what those artifacts might look like.
A generic term that can describe any structured approach to solving some or all of the problems related to architecture.
A defined series of actions directed to the goal of producing either an architecture or an architectural description.
A methodology for organizing and categorizing architectural artifacts.
The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
An architecture in which the system in question is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise.
When people work together well without resentments, and they are empowered to make and enforce decisions, and when the stakeholders and users understand their job's purpose and place in the organization, EA will work if properly governed by IT and supported by management. Judging it too soon is the first mistake.
- Enterprise Architecture
- The FEA Problem Statement
- History of Software Development Complexity Leading to EA
- Enter the Enterprise
- Common EA Methodologies
- Terms and Definitions
Federal agencies are rated on their overall maturity levels in three main categories:
Maturity level of the architecture itself.
How effectively the agency uses its architecture to drive decision-making.
The benefits being realized by the use of the architecture