The Lessons Learned from "Forensic Architecture"

Blogger: Anne Thomas Manes

Duane Nickull posted an interesting treatise regarding the lessons he's learned from four SOA-related architectural efforts he's participated in during the past 9 years, including ebXML, W3C Web Service Architecture, UN/CEFACT eBusiness Architecture, and OASIS Reference Model for SOA. He refers to the experience as "forensic architecture", which he describes thus:

"Forensic Architecture! What is it? I use this term to refer to the process of describing the architecture of something after it has been built. It is a largely frustrating, cumbersome process yet I seem to have made a career out of it."

I'll point out that Roy Fielding's dissertation on REST is an example of "forensic architecture" based on this definition. Dr Fielding wrote the dissertation after the Web had been implemented, and REST describes the architecture of the Web. And it's an excellent and very successful architectural document. But I will also point out that Roy had the advantage of writing his dissertation by himself rather than as part of a committee. At the end of Duane's post he plugs his new book on Web 2.0 Patterns, which is yet another attempt at forensic architecture -- this time exploring the various patterns that exemplify Web 2.0.

I think Duane's treatise provides excellent insight into the challenges of working in a formal standardization committee with many representatives from many organizations with vested interests in developing standards that correlate with their existing products. It's extremely rare to find standardization efforts that develop greenfield architectures from scratch. In fact, I can't think of one formal standardization effort that developed a greenfield architecture. But that's the nature of standards bodies. They only get involved after an architecture or technology has demonstrated sufficient value to warrant standardization.

I,too, was involved in the ebXML and W3C Web Services Architecture (WSA) efforts.

Regarding ebXML, Duane neglects to mention that the folks organizing the ebXML effort had been involved in earlier eBusiness architecture efforts, such as UN/EDIFact, so they had some preconceived notions of eBusiness architcture, which provided the foundation for defining and creating the six ebXML architectural committees. But Duane is spot on when he says that these preconceived architectural assumptions were not documented before the effort began. And time-to-market superceded all other architectural requirements.

Regarding W3C WSA: I recall the heated discussion that consumed the first three months of the effort -- we tried to define SOA. Eventually we decided to punt. I have yet to see a one-line description of SOA that everyone can agree to. A number of folks that I respect greatly (including Duane) always point to the definition specified in the OASIS Reference Model for SOA, which says, "Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains." This definition has value because it calls out some important features of SOA:

• Services implement capabilities
• Services may be distributed
• Service interactions often cross ownership domains

Unforunately, this definition misses the fundamental feature of SOA, i.e., SOA design principles, such as separation of concern, loose coupling, and service orientation. I also come away from the OASIS definition thinking almost exclusively about business functionality, and it doesn't inspire me to think about applying SOA principles to infrastructure functionality or data.

Burton Group's one-line definition of SOA is:

"SOA is a set of design principles that makes systems more flexible, reusable, and interoperable."

But note that this definition doesn't call out the features expressed in the OASIS SOA RM definition. As I said, no one-line SOA definition suits everyone.

Some additional comments on Duane's perspective on a perfect architectural experience. He says:

The sequence of events in a perfect world usually involves the following steps:

1. A problem is identified.
2. The problem is documented.
3. A solution is proposed.
4. Specific requirements for the solution are documented.
5. An architecture is proposed to solve the problem.
6. An iterative process of mapping requirements to solutions takes place until all issues are resolved.
7. The final solution is built and solves the problem.

I assume that a bit of analysis occurs somewhere between steps 2 and 3, and I'd also expect quite a bit more iteration to occur in steps 3 thru 5, with quite a bit of protoyping and solution building going on during those iterations. I would also expect some gap analysis of current solutions to occur in steps 1-3 to explain why current solutions can't address the problem.