Partitioned-Iterative more appropriate for EA than Zachman, TOGAF?
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:
- 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.
- Leverage economy of small scale. Use a relative small group attacking a well-defined partition of the enterprise.
- 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.
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....
Anatole Tresch Mar 03, 2015