InfoQ

News

Partitioned-Iterative more appropriate for EA than Zachman, TOGAF?

Posted by Johan Strandler on Jul 26, 2007

Community
Architecture
Topics
Enterprise Architecture
Tags
TOGAF ,
Zachman Framework

System complexity is the key reason for the many failures of IT organizations to deliver what they are supposed to do, said Roger Sessions, ObjectWatch CTO.  In May, Sessions published an indepth comparison of the top four current Enterprise Architecture frameworks Zachman, TOGAF, FEA, and Gartner's methodology, and in a separate article this July he stated that the methods have not evolved to meet the compexity of today's system development & business needs. Instead Sessions says that "the key is thinking small, partitioning the organization into narrowly defined areas of business need, instead of attempting to define the architecture for the entire company"; then, build out these features in an iterative fashion, showing early value and success in the EA project. Sessions last year proposed this new methodology, calling it the Partitioned-Iterative Approach to Enterprise Architecture, a process drawn from the lessons of probability theory and war strategy.

In Sessions' comparison he makes the following characterizations:

  • The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy for for organizing architectural artifacts.
  • The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process for creating an architecture.
  • 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

Going into more depth on the complexity management problems with these approaches, Session points at their OODA background:

"The standard existing enterprise architecture frameworks (including TOGAF, Zachman, and FEAF) share a similar history. They were all heavily influenced by the world of object-oriented design and analysis (OODA).

The fact that these frameworks are in the OODA generation is significant, because it dates them pre-SOA (service-oriented architectures). Today, most large systems are based on the notion of interoperability of autonomous applications through Web service standards (such as SOAP, WS-Security, and the like). This notion is very much tied to the service-oriented world that did not exist back when the earlier architectural frameworks were created.

Object technologies are intended for application implementation, not for architecting enterprises. Their biggest drawback is their inability to manage complexity."

Sessions also says that one key to successful enterprise architecture is that the technology and business groups must be partners. "You have to build up a culture of cooperation, complete some successful projects quickly, with low risk, and high perceived business value. Sessions points out that the existing approaches take too long to show value, similar to Agile criticicms of waterfall.

Instead Sessions proposes a Partitioned Iterative Approach as a solution to address the complexity problem. The approach suggests finishing a single business partition in one iteration, rather than recursively do a top-down design where each iteration basically makes one more level of details in the whole EA.

An example of this approach is given in his last year article by a system similar to a failed $170 million project at McDonald's, which needed the following functionality: Global HR, Payroll, General Ledger, Accounts Payable, Accounts Receivable, Billing, Assets, Accounting, Treasury and an Employee Portal. Session says that "all enterprise methodologies agree that the following phases must occur: Business architecture design, Technical architecture design, Implementation, Testing, Deployment. However the traditional methodologies would take these phases one at the time, fully completing one before the next is started." The partitioned iterative approach instead suggests using the same process, but iterating on one business partition at the time, producing a fully functional system for each iteration such as the Global HR function. Not until this partition is up and running, the next partition is addressed.

The advantages of Partitioned Iterative Approach, according to Sessions are:

  • Faster Time To Value (TTV). Sessions means that this is a more important success factor in the business world than measuring Return On Investment (ROI). A vertical slice can be delivering perceived value long before completion of the rest of the project, even before it has a positive ROI. "If you can show, for example, that within the first month, the library has already decreased the length of customer calls to the help desk by 20%, you are showing value, even though you may be years from showing a positive ROI for the overall project.
  • Increases the overall chances of a successful project, due to the possibility to apply the lessons learned in earlier iteration.

Sessions concluded his partitioned approach proposal by giving three rules for success for an enterprise architecture, summarized here:

  1. Start with low-hanging fruit. The important thing in developing an enterprise architecture is to demonstrate success. This will help build momentum for the larger goal.
  2. Leverage economy of small scale. Use a relative small group attacking a well-defined partition of the enterprise.
  3. Centralize interoperability, decentralize implementations. A centralized enterprise architectural organization is necessary. But the central organization needs to focus on the right issues, and not get bogged down on issues that are irrelevant. The general rule of thumb is that decision that impact interoperability should be centralized. Decisions that impact implementations should be decentralized.

Roger Sessions intends to publish a book later this year "Simple Architectures for Complex Enterprises" that discusses this methodology in greater detail.

Interesting by Stuart Charlton Posted Jul 26, 2007 8:17 PM
  1. Back to top

    Interesting

    Jul 26, 2007 8:17 PM by Stuart Charlton

    Seems to be typical Sessions - kernels of truth twisted into his own unique worldview, mixed in with just enough good writing to make people pay attention.

    He is right that all of the various EA "schools" out there have different assumptions & focuses. But I think his view of the heritage is wrong. For example, the Zachman model predates OODA by quite a bit - mostly I see data-guys behind it.

    Anyway, the one thing that's lacking is a popular approach to actually using a map like Zachman -- though books have started to emerge, such as from David Hay or Clive Finkelstein. I Mr. Sessoins wants a piece of this pie. On a glance, what he's saying seems to make sense, though isn't this just 15-year-old "incremental and iterative" methodology applied to architecture?

    BTW, I'm working on this area with in BEA lately. More fruits to come this Fall....

    Cheers
    Stu

Educational Content

Rails in the Large: How Agility Allows Us to Build One Of the World's Biggest Rails Apps

Neal Ford shows what ThoughtWorks learned from scaling Rails development: infrastructure, testing, messaging, optimization, performance.

Stuart Halloway on Clojure and Functional Programming

Stuart Halloway discusses Clojure and functional programing on the JVM in depth, and touches on the uses of a number of other modern JVM languages including JRuby, Groovy, Scala and Haskell.

Orion Henry and Blake Mizerany on Heroku

Orion Henry and Blake Mizerany talk about the technology behind Heroku and the benefits of the new add-on system.

Security for the Services World

Chris Riley presents security issues threatening service based systems, examining security threats, presenting measures to reduce the risks, and mentioning available security frameworks.

Navigating The Rapids:Real-World Lessons in Adopting Agile

This talk investigates technical issues encountered when moving to an Agile process.

Codename "M": Language, Data, and Modeling, Oh My!

Don Box and Amanda Laucher present “M”, a declarative language for building data models, domain models or external DSLs. Don Box's demos show some of M’s features and latest changes of the language.

SOA Manifesto - 4 Months After

It is four months since the SOA manifesto was announced; InfoQ interviewed the original author’s to get insight into the motivations and the process behind the initiative.

Memory Barriers and JVM Concurrency

This article explains the impact memory barriers, or fences, have on the determinism of multi-threaded programs.