So, when Chris Harding, Forum Director for The Open Group’s SOA working group, proposed an SOA reference architecture at the organizations Enterprise Architect Practitioners conference in San Diego this week, the room erupted in a surprisingly vigorous debate.
A reference architecture is essentially a blueprint of the pieces that comprise a technology or process.
This being The Open Group, it wasn’t surprising that the group’s own enterprise architecture framework provided the starting point for the SOA proposal. EA frameworks are supposed to embody the processes, standards, and behaviors that codify what IT does, the systems it developers and supports, and how those systems are delivered.
The framework, called TOGAF (which stands for The Open Group Architecture framework) originated in the mid 1990s as one of the answers to the venerable Zachman Framework, which was the granddaddy of EA frameworks.
Whereas Zachman dealt at high levels with data, function, networks, people, time, and organizational motivation, TOGAF slices the world differently: business, application, data, and technology. TOGAF is billed as a formal description of a system, or a detailed plan of the system at component level to guide its implementation.
At this point, The Open Group’s proposed SOA reference architecture remains highly conceptual. Harding pointed to OSIMM, the group’s proposed maturity model for SOA, as a starting point.
The rationale is that, with maturity models providing a way to benchmark your progress towards meeting your goals, the goals outlined in OSIMM might provide a good indicator of what are the component parts of an SOA.
And that’s where the debate began. Some in the audience confused the maturity model with a reference model.
Others questioned whether the world needed yet another reference model, saying that SOA should be just another view or slice of an enterprise architecture model. The rationale is that both EA and SOA both aim for a similar goal, of integrating and harmonizing processes and technology standards, and that developing a separate reference mode for SOA would degenerate to reinventing the wheel.
There was debate over whether agility belongs in an SOA reference architecture, or is simply the result when you follow the reference architecture and have the right internal climate. The question was whether a reference architecture should include business practices, or simply provide a recipe for the technical pieces that can enable you to achieve the desired business result.
Furthermore, with pieces such as standards in SOA still a work in progress, many in the audience questioned whether it made sense to define a reference architecture when nobody knows what the final pieces will be.
All this probably sounds highly theoretical to the practitioner who faces tight deadlines and barebones budgets. Yet the value of a reference model is that it can at least provide a recipe or design pattern that could enable a beleaguered tech lead to skip steps that could save valuable time and effort.
Nonetheless, the debate revealed that it’s probably a bit premature to set the SOA recipe in stone.
