Todd Biske: Outside the Box

I just listened to Elizabeth Book’s podcast with Anne Thomas Manes of Burton Group and Joe McKendrick discussing Service Averse Architecture. They definitely echo statements that I and others have been making for some time. Particular quotes that I want to highlight:

The companies that are good with SOA are likely to be … companies that have forward-thinking management and are good at everything else, as well … The organizations that really could use SOA, that need that flexibility and agility, are the ones not likely to be adopting SOA.
– Joe McKendrick

Joe and I both had posts on this topic back in October of 2006 (see here and here). This is simply the nature of way things progress. You have a certain class of organization that are the leaders that have a high percentage of success at whatever they do. The problem, however, comes with the middle class. What we’d like to see is that middle class of organizations merely trailing the leaders, but still eventually achieving success. Instead, we’re at risk of seeing the “haves” and the “have nots.” Anne calls out that Service Averse Architecture is the status quo, and that’s a shame. As long as it continues to be the status quo, we’re not going to progress as an industry, and if anything, it fuels the fire of those that question the relevance of IT. After all, if businesses continue to thrive despite having continued dissatisfaction with IT support, then is IT really a differentiator worth investing in, or is it simply a necessary cost center where the focus should be on driving costs down to rock bottom levels? I believe IT can be a differentiator, but like Anne, I do believe it’s a very select few who are able to do so.

The same type of thinking does hold true in other business support areas. Is HR simply a necessary evil, or can it be a differentiator? Look at Southwest Airlines hiring practices and the experience they are able to give their customers and you can see the impact. Despite having no reserved seats, their customer satisfaction (and profitability) is far better than most airlines. Thankfully, a few shining stars can go a long way in keeping efforts alive to ensure that we don’t have the “technology haves” and the “technology have nots.” It’s why I am supportive of efforts like the SOA Consortium.

The big issue is that most organization have a culture and an incentive system that absolutely discourages the adoption of good SOA practices. That is, everything is project focuses and every project is completely focused on delivery of that project as quickly as possible at the least possible cost and there is no interest whatsoever in figuring out, “well, what is it that I’m building that should be implemented as a service that other people can use?”
– Anne Thomas Manes

I was happy to hear Anne call out the problems with the project-based culture prevalent in IT organizations that I also commented on in April of 2007. There are huge cultural changes that need to be made, but most organizations are not doing so. It’s an extremely difficult problem, because you need to figure out an incremental way of doing it. Anne goes on to comment:

So much of SOA is tied up in things like Master DM and ID M and a reasonable DA and BPI efforts and all the EA things people are doing. You have to take this cross-organizational perspective and plan what you’re going to do and not just say, “Oh, I’ve got a new project I’m going to let my developers figure out what services to build.” It’s challenging because you have to think globally but you do actually have to implement on a local level. But you just can’t depend on the local people to figure out what they’re supposed to be doing. They need guidance from above.
– Anne Thomas Manes

This articulates the challenge well. You can’t simply say tell the developers to build the right services, even if you’re allowing them to challenge the scope boundaries of the projects, without having appropriate guidance from above. I’ve see a number of efforts where developers are honestly trying to do the right thing, but they don’t know the right next steps to take. The project-based culture is so ingrained that even when they are able to identify appropriate services that have broader value, they don’t know what to do to ensure that those services actually see broad use. Too often, it’s simply a “let’s build it and hope they come” approach, where the only guaranteed consumer is that initial project that kicked it all off. In short, not much has changed.

I talk about this as a lifestyle. If you want to become healthy and fit you need to exercise and eat right. Well, if you want your systems to be agile and flexible, then you have to adopt SOA fitness activities. You have to recognize what’s good behavior, what’s bad behavior, and try not to do the bad things, try to do the good things.
– Anne Thomas Manes

If you’ve been lucky enough to have someone really think about what it means to adopt SOA, you’ll understand exactly what Anne is saying here. SOA winds up touching all aspects of IT. If your doctor tells you that you are at risk of a heart attack, simply eating less fatty foods is not enough. There is no magic pill or single activity that will make your SOA adoption efforts successful. It is a lifestyle, and you need to be committed to everything that it may entail, rather than only doing it where it is convenient. We have to recognize that to make things better for the business, things have to change. If we’re only implementing minor changes, we can only expect minor successes. If your IT department is already very successful, minor changes may be fine. If your IT department is on a path to a heart attack, major changes may be in order.

Update: As usual, the timing of Dilbert is perfect. The Dilbert for Monday, May 22nd really captures the status quo and how there is far too much competition rather cooperation that occurs within the enterprise.

5 Responses to “Service Averse Architecture”