Seven ways companies go wrong with SOA
Remember, SOA is a journey, not a quick overnight fix. It's a transformative process that your organization will follow for the long run.
A few years back, I put together a list of where companies appeared to be steering in the wrong direction in terms of SOA implementations. The list bears repeating, because the issues still keep getting in the way of SOA success. Many companies run the risk of jumping into the approach without looking at where they are leaping. Here are the most common pitfalls that could tie an SOA installation into knots.
1) Viewing SOA as a global, enterprise-scale project involving the entire enterprise: An SOA need not be a galactic initiative that sucks up resources all across the enterprise. In fact, one of the beauties of SOA that it can start small and simple, deployed across a single business process. Definitions of SOA vary, but SOA can start with something as simple as some Web services that accomplish an end-to-end process, such as fulfilling a purchase order.
2) Looking to a single vendor to offer very complete SOA solutions: There’s no such thing as buying an SOA solution; there’s no such thing as SOA in a box, no matter what a vendor may tell you. SOA is not a product that a vendor can ship to you for installation over the weekend. Rather, SOA is a philosophy around developing your infrastructure using those vendor tools. If you have a J2EE or .NET Framework, you have a framework. An SOA is what you eventually do with those frameworks.
3) Assuming that SOA will automatically grow out of a primordial soup of Web services: Many companies think they have SOA when they actually have a JBOWS (Just a Bunch of Web Services) architecture. Somehow, there’s an assumption out there that a spaghetti architecture of Web services will somehow evolve into something resembling a full-functioning SOA. Actually, it’s possible (but not advisable) to build an SOA-enabled infrastructure with no Web services at all. An organization could have 1,000 Web services, but unless these services work in concert to address specific end-to-end business processes, that does not an SOA make. One additional point about JBOWS, however -- there's nothing wrong with being in the JBOWS stage of evolution, because that's what it is, a stage of the evolution. But don't expect the full-fledged agility of SOA at this stage -- that's where the disappointment has crept in.
4) Build it, and they will come: SOA is not an illuminated ballpark in the middle of a cornfield that can be seen from miles around. No one will take advantage of an SOA-enabled infrastructure if they don’t know where to find it, or even if it exists. There’s a rule that if developers have to spend more than 10 minutes to find what they are looking for (and don’t find it), they will create it themselves. An SOA will never be of value if it’s confined to one silo of the organization, and its components are not made available and shared across business unit. An SOA service built, managed, and used by one business unit will cost just as much as any other legacy application.
5) Assuming that businesspeople don’t, or won’t, understand SOA: Actually, most people on the business side can intuitively grasp the potential savings and opportunities an SOA can bring. And Enterprise 2.0 and the cloud dynamic really drives the points about service orientation home on the business side. The potential of reusing services across various business units, versus paying developers to rebuild a new service in each instance, is Management and Finance 101. The difficult part is building and managing such an infrastructure, applying IT governance, monitoring, and management to ensure that services are kept up and running, are scalable, and perform well.
6) Assuming that IT people don’t, or won’t understand the business: It’s time to put this misconception, which has been weaving its way through conferences, articles, and analyst reports for years, to rest. Indeed, SOA needs to be a multi-disciplinary, cooperative effort between IT and other departments. However, IT is part of the business, and IT professionals’ paychecks are signed by the business. Most IT departments understand that they play a vital role in moving the business forward. However, inevitably, specs and priorities will change during the life of a project, and that’s why projects fail. It’s incumbent on both IT and business users to keep each other informed; both have a financial stake in the business’s success.
7) Treating SOA as something far superior to a mere mortal “project:” SOA success is delivered one project at a time. If you have been to any number of SOA conferences, or tuned into the multitude of SOA Webcasts, you probably have heard the message over and over again that “SOA is more than just another project.” Yes, true. SOA does represent a new way of thinking, and will transform your IT, and ultimately, your business processes. However, SOA still needs to be treated as a project, with the same deliberate planning of timelines, establishment of baselines, and measurement of key performance indicators as other large IT projects. SOA requires executive buy-in, it requires resources, and it requires proof that it is paying off.