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.
Feedback from the author
Chuck, thanks for your comments on the book. I'm glad you called out that it's written more in the style of a management guide than a technical reference, because that was done with intent. SOA Governance isn't a technology, it's about people, policies, and processes that guide the decisions we make, including technology usage.
Regarding your feedback on testing, measurement, and development processes, the goal of the book was not to offer suggestions on what SDLC to use (e.g. waterfall versus iterative, and for the record, I'd recommend an iterative approach), but rather on what policies and reference material are needed to guide the decisions made in the development process, regardless of the SDLC used by an organization. So, on the use of a canonical model, the real question is whether or not the organization is trying to achieve enterprise consistency across all services, or consistency within a smaller domain. If it's enterprise, then when the decisions are made for the use of those models on a project, the team needs to have the appropriate context and reference material to do that. If it doesn't exist, then the consistency is solely driven by the tribal knowledge of the people involved. As you call out, my recommendation is to focus on how the model will change over time and manage it, regardless of how it was initially created. Whether a big upfront modeling effort is required or not is going to be dependent on the scope of the SOA adoption effort, the time needed to achieve those goals, the amount of metadata currently stored and available, the level of communication that currently exists in the organization, and other factors.
Thanks for your feedback!