We all do it from time to time - forget something, get it out of sequence - and experience that annoying feeling that we've just done something incredibly stupid. I usually arrive at the dry cleaners to pick up my clothes, only to realize I'd left the next batch behind. Fortunately, it's not a long drive. But it's usually because I'm in a rush, trying to accomplish multiple things. If I slowed down just a second, I might accomplish more.

Service-oriented architecture faces similar challenges. In particular, the concept of architecture seems to be the one that gets left behind, or thrown out with the bathwater. Yet it's really the architecture part of SOA that enables it to provide the highest return on investment from an implementation.

I've gone on and on about architecture - what it is, why it's important, how to do it - in numerous issues of SOAWorld Magazine. Yet in many cases I still see organizations with the same old problem: "Ready, Fire, Aim!"

This is partially due to the challenges of providing an ROI on technology that is in many cases considered pure infrastructure. It's an old problem. Remember when you didn't have Internet access on the job, or it was a slow dial-up? Making the case that Internet access was important to the employee base was difficult - especially if you had to justify a move from limited dial-up to universal broadband. Sure, we all thought it was a good idea, but what was the monetary value to the organization? It was much easier to quantize the costs than to enumerate the benefits and place a value on them. And yet, eventually, the overwhelming majority of organizations have moved to broadband.

SOA is very similar. It's nearly impossible to quantify the business benefit of an SOA migration. The benefits are clear in an environment with multiple applications and strong integration needs, but at the same time, it's still a challenge to pin a number to them. Will an SOA increase productivity? Will it reduce maintenance costs? How much? How long will it take to reduce those costs? Yes, the questions sound like you're being pecked to death by the accounting duck, but they are also real issues. Bottom line in today's economy is that an SOA migration needs clear ROI justification.

Which is a challenge. Instead, organizations are using the grassroots approach to SOA. New projects have to include SOA. Old applications that are being renovated are encouraged to adopt SOA aspects. And slowly, through the process of accretion, an SOA arises from the muck.

The challenge is that by building SOA a system at a time, we're concentrating on the wrong end of the process and ignoring the role of architecture. We're building the same old silo - perhaps a little more open, but not a whole lot better than the system as it existed before the introduction of an SOA element.

This is why architecture is important. Without it, services arise at all levels of granularity. Processes have to be cobbled together haphazardly. Service rationalization and consolidation does not take place, so duplicate or nearly duplicate services exist long after they should have been rationalized to a single service. The retirement of redundant systems is delayed long after it could be accomplished.

Although it's rare to be able to fund a complete SOA overhaul, a best practice that should be followed is to set up an SOA Governance and Architecture group. The group doesn't need to boil the ocean in order to solve every problem, but as systems are reworked or introduced they can be the coordination point for rationalizing the enterprise to a set of identified services. They can also serve as the mediator in various negotiations around design and guide the IT organization as to how best to achieve an SOA given multiple options.

In the same way that I need someone to remind me to take my dry cleaning with me, we all need to have Architecture as part of SOA. Now where did I put that cleaning ticket?