SOA Goverance and Canonical Model Development

My copy of Todd Biske's new book, SOA Governance, arrived today. It is mainly well done. Before you order you should know that this is much more in the genre of a management book than a technical reference. Much of the book uses a narrative about a SOA implementation at a fictional company, Advasco, as a device to explore SOA implementation and governance issues. The book isn't likely to solve all your SOA challenges, but it is useful and an easy read. Among the material that is particularly valuable are the role/position descriptions for a SOA team in chapter 8.

While I'm generally positive about the book, I do have a few issues it. As you might expect, there is a division in the book between "design-time" SOA governance and "run-time" governance. While Biske talks a bit about "design-time checkpoints," he only really talks about testing and measurement as a post-launch, run-time task. For example, Biske writes "the final process associated with SOA governance is that of measurement and improvement". I think something that is missing is a specific mention or any emphasis of the role of iteration and testing during design time. For example, if you read through the section on developing a "canonical model," it sounds more like a classic "waterfall" approach that is highly dependent on accomplishing the correct upfront research and the right agreement among stakeholders ("Consult all potential service consumers," etc.). My own advice would be for SOA implementers to expect model development (perhaps the most important "design time" activity) to be highly iterative and to be test-driven as much as possible.

To be fair, Biske does specifically advise against assuming that a model will be "defined once and never modified" and instead suggests that stakeholders should plan for change. However, he doesn't mention anything like test-driven development and iteration as key activities in model development.

More than just consulting with service stakeholders, your information architect needs to actively collect test cases, usually in the form of real-world data instances representing the particular entities being managed. If done right, this test-driven development will avoid the "analysis paralysis" that Biske cautions against while better guarantying that models meet the real-world requirements of stakeholders.