Just about every publication, marketing brochure, and IT commercial currently on parade for your enjoyment contains some mention of service-oriented architecture. If products were still sold in boxes, instead of downloaded, you would see a bright sticker on the box saying "New and Improved: Now with SOA." Instead of Fuller brushes, today's sales wiz now pushes SOA - it's good for what ails you.

Now don't get me wrong - I'm more or less in favor of SOA, although I do believe there are times when it is inappropriate for use. But after all, this is a magazine devoted to SOA, so as its editor, you can bet I find those inappropriate times few and far between. SOA is a concept that works naturally in a partitioned application world - it allows the natural creation of interfaces and construction of software from basic services. A previous generation of coders might have recognized this as the same mantra used by proponents of component-based development, with increased interoperability being the added bonus of the current SOA strategy. And to an extent they'd be right - SOA is a modern software Lego set. Need security? Grab that piece there. Logging - this little piece over here. Have to connect billing to order management? Get that little connector thingamabob. All in all, it's a very neat, logical concept that resonates well with the logical mind of a programmer or architect.

However the joy of SOA tends to blind architects, programmers, and other techies to the cold, hard facts of SOA: once you get it set up, you still have to build the user interface.

I know, SOA is about computer-to-computer communication, right? At least that's what vendors and consultants would like you to believe. But that's a bunch of hogwash. In the end, SOA is about doing business better. If it doesn't help you do that, what possible justification do you have for changing to it? There is none. In fact, justification of the cost of change is often the first thing that kills a prospective SOA implementation. If it doesn't save money or make money, it's not going to happen in today's economy.

But let's get back to the front, or rather the front end, at least. Service-oriented architecture makes it easy to create composite services, or rather, business processes. Processes can be wired together from prebuilt services in a manner that is inconceivable when looked at from the perspective of 40 years of previous software development. And yet with Web services, some transaction management and a little business process management thrown in for good measure, it's very reasonable to rewire an entire process in a very short period of time.

And then it hits: because the reality is that while some business processes don't require the computer to interact with a human being (or reasonable facsimile), most of them (the business processes, not the human or reasonable facsimile) do. That's the wall, the spot where we run out of Lego.

I'll admit there are good tools out there for creating user interfaces in short periods of time. But I'll also challenge you to get past the HUMAN part of the equation - by this I mean getting users to agree on things like colors, field lengths, screen resolutions, order of presentation, etc., ad nauseam. You can't do it - the user interface always takes longer and costs more. As much as you might want to move quickly, user interface is the most contentious task in software design. You need consensus, and sponsorship and time.

And that's where the speed tends to fall off of SOA. It's great for creating the services, but it has yet to really develop fully towards quickly and easily deploying the processes so that people can use them. Guess we still need a few more pieces of Lego.