Turning Failure Into Success
Over the last two-plus decades, most organizations have come to rely on information technology (IT) systems to run their business. Now, with a variety of mission-critical applications and tools in place, many organizations see the value in integrating these systems in order to operate more efficiently, provide better customer service, and develop new revenue-generating activities. According to Gartner, integration increases the value of application portfolios and positions IT to use their portfolios to deliver improved business value.
In the computer industry, integration is a general term for any software that serves to join together or mediate between two separate and usually already existing programs, applications, or systems. From a business perspective, integration is about creating automated business processes – known as workflows – to codify routines that were once performed manually.
A new integration standard has evolved in recent years known as service-oriented architecture (SOA). SOA enables different programs, applications, and tools to interact via self-contained services that do not depend on the context or state of the other service. Working within a distributed systems architecture, SOA has gained momentum because it creates reusable integrated business processes. While tracking mediocre results, and even failure2, in the implementation of service-oriented architectures, many common threads, or “worst practices,” can be found. The top-four worst practices for SOA integration include:
- Overemphasizing low-level code
- Centralizing design and development
- Ripping and replacing legacy software
- Buying software without support
These worst practices set companies on the inauspicious path of SOA failure. They have been repeated by some of the best run and smartest companies in the world. Typically, these worst practices are the result of wanting to ride the latest technology wave without balancing the hype with practical knowledge and experience. For an SOA integration initiative to be successful, organizations must think about the long-term health of their architecture, even while deploying short-term solutions.
Designed to help organizations learn from the mistakes of others, this paper provides insight into the top-four worst practices for SOA integration. It also provides guidance on how to avoid and/or overcome these worst practices in order to realize the true value of an open, reusable integration architecture. By reading this paper, you will have a solid understanding of how to avoid SOA integration failure and achieve success with your initiatives.
Worst Practice #1: Overemphasizing Low-Level Code
A doomed – yet typical – SOA integration scenario goes something like this: Company X purchases an integration tool. The company’s integration developers immediately begin automating business processes. The integration solution works for a short while, but soon business processes change and developers are forced to modify the code.
These business-process changes can result from enterprise-wide changes, such as merging with or acquiring another company, or something relatively minor, like contracting a new supply chain vendor. As the developers change the SOA integration solution’s underlying code, the system becomes clunky, slow, and less able to adapt to additional changes.
This approach, rooted in the way enterprise application integration (EAI) was historically performed, addresses only specific workflow integrations. It does not allow an organization to create an open, reusable architecture.
iWay’s Response: Focus on Business-Level Services
SOA implementations are not about connecting specific steps in a workflow to mirror existing business processes. Organizations that have built successful service-oriented architectures build services for specific projects and then incrementally develop new services that are consistent and work in a mutually supportive way. By breaking the entire system into logical building blocks – also known as services – a sustainable solution is created that can grow along with business needs. These services, which are nothing more than reusable bits of functionality, can be divided into three levels: fine-grain services, coarse-grain services, and global services.
When organizations overemphasize low-level services, the net result is too many services that don’t aggregate up into business-level services. Coding this way creates slow and complex process flows that are not easy to maintain or reuse.
Take for example the workflow required to process a purchase order. Typically a credit check is performed and then inventory levels are determined. Are there other business scenarios in which a customer’s credit history must be verified? Probably. The same is also true for inventory levels.
