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.
Tracking change and innovation in the enterprise software development community
Posted by Johan Strandler on Jul 26, 2007
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:
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:
Sessions concluded his partitioned approach proposal by giving three rules for success for an enterprise architecture, summarized here:
Roger Sessions intends to publish a book later this year "Simple Architectures for Complex Enterprises" that discusses this methodology in greater detail.
Consolidation and Virtualization Are NOT Enough: The Case for Non-x86
Redbook: WebSphere Application Server V7.0: Planning, Concepts, and Design
Innovation in Your Data Centre
Comparing WebLogic, WebSphere, Oracle, and Open Source Application Servers
Intel® SOA Expressway Performance Comparison to IBM® DataPower XI50
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
Neal Ford shows what ThoughtWorks learned from scaling Rails development: infrastructure, testing, messaging, optimization, performance.
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 talk about the technology behind Heroku and the benefits of the new add-on system.
Chris Riley presents security issues threatening service based systems, examining security threats, presenting measures to reduce the risks, and mentioning available security frameworks.
This talk investigates technical issues encountered when moving to an Agile process.
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.
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.
This article explains the impact memory barriers, or fences, have on the determinism of multi-threaded programs.
1 comment
Watch Thread Reply