Todd Biske: Outside the Box

Chuck Allen, in this blog entry posted after he read my book, felt that the book was missing a discussion on the role of iteration and test-driven development in building a canonical model. He felt that my description of the role of a canonical model felt like a waterfall methodology. I had posted a comment on his blog, but it hasn’t shown up there, so I’d thought I’d post a response here.

There’s two things that came to my mind as a result of Chuck’s post. First, Chuck’s viewpoint is consistent with a lot of people’s thinking around governance as some big, heavyweight process that has more in common with BUD (big up-front design) practices. When applied to agile methodologies and iterative development, they feel it won’t work. This is not my view on it, however. My view is that governance is a requirement, regardless of your methodology. If your project teams feel it’s getting in the way, it’s not that you need to get rid of governance, it’s that you need to change your approach. Where teams get frustrated is where they’re forced to go before some review board or reviewer who starts asking them, “Did you do this? Did you do that?” and the answer is always, “No, I didn’t know I needed to do that.” Therein lies the rub. The team didn’t know about the policies that existed. If the policies aren’t documented, how can we expect projects to be compliant? If the policies are documented, then there should be no reason why a technical lead or project architect can’t bring them up as appropriate within an iterative approach, or bring them up as part of some up-front design, if that’s your preferred approach.

The second thing that came to mind is more about developing those policies and that reference material. If we’re adopting SOA at an enterprise level, then there will need to be policies that define what that “enterprise” success is. My book calls out what those reference materials are, because those are what’s important to good governance. The book did not, however, go into depth on how some of those artifacts would get created. It doesn’t describe how to develop a canonical model or a business capability map, rather, it describes how those artifacts should be used to achieve SOA success. That is the governance question. Developing a business capability map is a business analysis and architecture question. Developing a canonical model is an information architecture question. There are books out there that can teach you how to do that. To Chuck’s point, however, when these artifacts are intended to define something at an “enterprise” level, there is significant risk that they never get created because we go into analysis paralysis. I did call this out in my book, as Chuck pointed out, but I think he offers some good advice that it may make sense to not only apply iterative approaches to your software development effort, but also to your efforts to produce policies and reference material. That’s embodied in my four processes of governance, where the last process is one of continuous improvement. Establish some policies, communicate and educate, enforce them, measure the impact, and then adjust as needed.

One Response to “Governance and Iterative Development”