Todd Biske: Outside the Box

Recently, there’s been a few posts that have discussed the role of the individual in an SOA effort. David Margulius of InfoWorld posted an article about a doctor that took it into his own hands to create an electronic records system for outpatient services. Joe McKendrick of ZDNet and eBizQ followed on with some commentary. Prior to this, there was an article by a developer that was particularly critical of Enterprise Architecture.

Both of these articles raise some interesting points, and for the discussion, we need to go back to the city planning analogy that I recently discussed. If we were to equate these two technology related activities back to the city planning analogy, what would we have? In the case of the doctor that built his own electronic outpatient records system, let’s look at a recycling program. It’s entirely possibly that a homeowner’s organization could use some of the dues collected and implement a recycling program for an individual subdivision. It’s even possible for an individual homeowner to take their recycling to some provider elsewhere. Does it work? Absolutely. Is it cost-effective at the city level? Well, maybe not. Every individual getting in their car and driving to the nearest recycling center will be more expensive than a few trucks coming from the center for curbside pickup. The homeowners organization may be slightly more cost effective, but if each subdivision picks their own provider, you could have problems with far more recycling trucks on the street than are really necessary. The real concern, however, comes back to the problems in the first place. Why didn’t the city council put a recycling program in place? The fact that the city failed to act on this in a timely manner for its citizens is what causes a homeowner or homeowner’s organization to take matters into their own hands.

Likewise, let’s take the case of the frustrated developer. Here, the author called out:

Projects are driven by business deadlines, and not by the time it will take to get things right. So the foundation starts out weak…

This sounds like a case of being doomed from the start. In the city planning analogy, there are many scenarios, ranging from fixing a pothole in a street, to building highway interchanges. How many stories have been there about some worker that follows the letter to the T? They’re told to fix a pothole, so they fix that pothole, and only that pothole, regardless of whether or not the street looks like the surface of a golf ball. Some major development project is put under way, and winds up having huge cost overruns because an over-aggressive schedule.

While some may think that the core of the problem is too much governance, it’s not. The problem is ineffective governance. There needs to be an understanding from top to bottom of the roles and responsibilities associated with decision making and all need to be held accountable. A developer that isn’t following the guidelines isn’t a good thing, nor is an architect that establishes the wrong guidelines. An enterprise architect that obsesses about particular lines of code in a project is focused on the wrong thing. The city council shouldn’t be mandating what color a homeowner paints their bathroom. At the same time, there will always be gaps, and there will always be people with time on their hands to address them, like the doctor in the InfoWorld article. A key to being successful is the creation of the appropriate framework so those people can fill those gaps, but in a way that leads not only to short term success, but long term success, as well. I’m just as guilty as anyone else of jury-rigging a solution for a problem that I had, and then telling a few people about it, who in turn told their friends about it, etc. and the time I spent on it starting going up and up. The problem was a lack of understanding of either the need or the value that would achieved from the solution.

SOA is just another example of this. I recently had a discussion with Phil Windley about an upcoming article. In our discussion, one of the things I mentioned was that I felt that the technology governance (i.e. EA) needs to get in sync with the traditional IT governance (i.e., project scoping and funding). Project establish boundaries, and if those boundaries make it difficult to build services that have broader benefit, the odds are already stacked against you. We need to find a way to have those services be built the right way, and that may be more about changing the way that IT operates than it is about using a particular technology.

In short, the groups that comprise IT Governance in my opinion, EA and Management, need to establish the right guidelines and the right funding models for SOA, and really IT as a whole, to be successful. For some larger efforts, it will involve significant planning and effort from those areas. The smaller efforts will still occur, however, and they can’t be ignored either. An environment that encourages the individual to contribute to the overall success, and helps them to contribute in a constructive, rather than destructive way, will be the most successful. Sometimes it is necessary to deny a building permit for the greater good. The best situations, however, are where it can be turned into a win-win situation for both.