Todd Biske: Outside the Box

Pete Lacey had a very interesting post entitled, “What is SOA?” I encourage you to go to his blog and read the whole thing, but I wanted to call out a couple of nuggets here for some comments. First:

“But wait,” I hear my SOA-loving readers say. “SOA is not about exposing business logic on the network. That’s just a technology thing. SOA is about the business! CxOs and business units don’t care about technology, they will only pay for business solutions.” Which always makes me scratch my head. What exactly does IT ever do that’s not about the business? Do they not work for the same company as the other BUs?

This is very reminiscent of the recent discussion on the business case for SOA, which I argued should be a business case for services, not SOA. Pete hits the nail on the head with his comment, “What exactly does IT ever do that’s not about the business?” Of course, it’s probably better stated, “Shouldn’t everything IT does be about the business?” After all, there’s probably some things going on most large IT shops whose business value is debatable. Anyway, what’s really interesting about this is how many activities within IT don’t go far enough to be about the business. IT is just as guilty of putting up walls as the business partners are. Recently, I had a discussion regarding instrumentation of services and collection of usage metrics. I argued that anyone who is acting in the capacity of a service manager should be looking at those metrics on a regular basis. Think about this. How frequently do you run into someone within IT who has recently put a solution into production who is actively monitoring the usage of it to determine if it is a business success? More often than not, I see project teams that quickly dissolve, allocated off to other projects, and no one paying attention to run-time usage unless some red light goes off because something’s broken. This type of monitoring should not strictly be the domain of “the business”. As IT, you are PART of the business, and you should be proactive in your monitoring and understanding of how your solutions are supporting the business. If you throw it over the wall into production, then the business-IT relationship is going to look very similar.

Pete also states:

“Well, it’s not just about business alignment,” another group of SOA advocates claim. “It’s really about governance.” Again, I’m scratching my head here. Everything is about governance! Software development (network-oriented or not) is about governance: ‘You must use a version control system; you must write unit tests.’ Moving systems into production is about governance. Updating a routing table is about governance. Hiring a new employee is about governance. Buying a plane ticket is about governance.

“No, no.” They go on. “With SOA there’s new things to govern.” That’s true, there are. But really, is it that much different than any other governance process? Not really.

I certainly agree that the need for governance is not just limited to SOA. What I’ve found in my work is that long term SOA success requires a fundamental change in the way IT operates. It’s not limited to SOA, however. SOA is merely the trigger that is bringing attention to the flaws in the system. As IT grows, there will be a need for governance, period, whether it’s for SOA or not. This doesn’t mean that SOA isn’t important, but it also means that there’s a risk that SOA becomes the banner under which all things wrong with IT are destined to be cured, and that’s a dangerous path. I’ve done work where the “SOA deliverables” contained a whole bunch of stuff that arguably were not specific to SOA at all. At the same time, if that’s what it takes to bring some attention to some things that need to be fixed, I’m not going to argue. Just be cautious in how much falls under that banner, because you can inadvertently jeopardize your SOA efforts on things that have nothing to do with it.

One Response to “Pete Lacey and SOA/NOC”