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. By creating these processes as reusable services instead of hard coding the order-processing workflow, checking customer credit or inventory levels only needs to be coded once and reused by any other existing or future business routine that requires that information.
Once an organization gets the architecture design right, everything else naturally follows. For an SOA initiative to be successful, organizations must move away from the EAI paradigm. When businesses processes become too complex, the amount of code developers are required to write increases exponentially. iWay Software encourages organizations to identify recognizable integration patterns. Every repeatable integration pattern should be developed as a reusable service.
Worst Practices in SOA Implementation