One of the fun parts of being a software architect is trying to figure out how to build whatever it is that you are supposed to build. It's even more fun when you look at the architecture for an entire enterprise, and have to make choices that integrate every complexity and account for every nuance of the portfolio, even if only long enough to get something in place before ripping something else out.

The advantage of buying a COTS product from a software vendor is that you get expertise at programming, and in a particular line of business, without having to hire, retain, and pay a staff of programmers. This ability to buy functionality was a major innovation in the entire software development process, and a boon to departments that no longer had to wait out a long, waterfall-based life cycle before they got applications to assist them in doing their jobs more effectively.

The downside, as the IT department found to its horror, was that the ISVs weren't interested in building to every platform under the sun. Instead, they'd choose a system or a platform, like the mainframe, AS/400, VAX, or even client/server and create software. While the software was good at the business task (or at least good enough) that the business users were happy, it was a nightmare for IT. Now they had one of everything to support, and instead of knowledgeable programming staff who knew the platform as well as the application, they had to quickly train whoever was handy. It's not a wonder that IT satisfaction plummeted over the years. Very rarely did the true cost of packaged software, in terms of support, and impact to other parts of the business, ever get addressed.

Fortunately we have Web services now. Many of the problems caused by silos of applications can be mitigated by applying the technologies developed for Web services. Platform differences can be overcome. Communication mechanisms can be established. Locations of services can be determined.

And yet, it's still possible to make programmatic spaghetti with Web services and to design services that don't scale, aren't secure, and can't be managed. That's because Web services provides technology, but not architecture.

And that's why service-oriented architecture (SOA) is so important. An SOA helps overcome the challenges of application integration using Web services, as well as other concepts, constructs, and tools that aren't necessarily part of the core Web services stack.

SOA is not really a product, or a technology. Although you can buy an SOA in the same way you can buy a development methodology, in most cases you aren't buying code but rather thoughts. Like the instructions to a complex model airplane, SOA will guide the construction and ensure that there are no pieces left over at the end.

Applying SOA in an existing environment can be a challenge. Services are a different mindset than applications - in fact, applications are built on top of services that may be reused in an SOA. The concepts of user interface and integration are different, and with existing legacy software, it may take years of careful, planned refactoring before the software that was is the service that should be.

This month's focus is on SOA and the enterprise service bus (ESB). The ESB is a similar concept, but slightly simpler - it provides a messaging backbone for enterprise communication. And for many organizations, adopting an ESB before an SOA is a wise move - sort of a crawl before you walk approach. Regardless of whether you do one, the other or both, Web services technology still underlies the concepts. WSDL, XML, SOAP, and other message bindings are core to both concepts. And the concepts themselves are key to avoiding building yet another stovepipe.