Worst Practice #4: Buying Software Without Support
Purchasing SOA software is only the first step. How the software is used to implement a reusable service-oriented architecture is what really matters. One surefire way to undermine an SOA initiative is to purchase software without support.
Use the following example to visualize this worst practice in action: Company X purchases software that promises to turn their SOA dreams into reality, but in keeping a close eye on their expenditures, they decide to forgo any support from the vendor’s professional services or consulting organiza- tion. The developers at Company X begin working on the SOA integration project, but soon run into trouble.
Two of the most egregious problems caused by not having the sufficient know-how to operate SOA software include building an overly complex system and not using the right tools for the job.
Overly complex systems are built when organizations do not fully recognize that an SOA imple- mentation is inherently different from EAI architectures. To be successful, developers must first learn to recognize what should be a service and how to aggregate them into higher levels. Yet, most organizations don’t have developers on staff with the design expertise to do this. Instead they code EAI workflows, which become overly cumbersome and complex as the system is modified and changed. Organizations then blame their failure on the software, instead of the fact that they didn’t know how to properly design, develop, and deploy a service-oriented architecture.
Without sufficient support, XML can also become an organization’s Achilles’ heel in terms of creating an overly complex system. Many vendors tout XML as the end-all and be-all for SOA. And, while XML is necessary it is not always as simple as it appears. In the e-business world, for example, messages converted into XML become huge. XML transformation engines were not designed to handle such large messages, which can become hundreds of megabytes. When messages are this large, the system slows down. Support services, however, can help organizations split and accumulate these messages into manageable sizes.
A second often-seen effect of not having sufficient support while developing an SOA strategy is organizations not using the right tool for the right job. Because integration projects involve connecting many different applications, data sources, and business processes, no single product or engine can be used to accomplish every task. Each function of a service-oriented architecture requires different tools or features.
iWay’s Response: Support Ensures Success
Having an overall SOA architect means that organizations establish set principles in regards to what their services look like. To be successful, organizations need people who can recognize integration and help create reusable services.