A Comparison of the Top Four Enterprise-Architecture Methodologies

Twenty years ago, a new field was born that soon came to be known as enterprise architecture. The field initially began to address two problems:

  • System complexity—Organizations were spending more and more money building IT systems; and
  • Poor business alignment—Organizations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need.

The bottom line: more cost, less value. These problems, first recognized 20 years ago, have today reached a crisis point. The cost and complexity of IT systems have exponentially increased, while the chances of deriving real value from those systems have dramatically decreased.

Today’s bottom line: even more cost, even less value. Large organizations can no longer afford to ignore these problems. The field of enterprise architecture that 20 years ago seemed quaintly quixotic today seems powerfully prophetic.

Many enterprise-architectural methodologies have come and gone in the last 20 years. At this point, perhaps 90 percent of the field use one of these four methodologies:

  • The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy
  • The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process
  • The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture
  • The Gartner Methodology—Can be best described as an enterprise architectural practice

Why do we need model driven architecture (MDA)?

Many organizations have been developing IT software without modeling but there have been various problems in realizing the “requirements to implementation”.

Primary issue continues to be that of communication.

The two keys to solving this problem are

  1. Distinct viewpoints for each stakeholder.
  2. Automated information passing between them.

Business people need to communicate IT requirements in their own terms.

System designers and developers need technical specifications and unambiguous designs.