Over the last two-plus decades, most organizations have come to rely on 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. A new integration standard has evolved in recent years known as service-oriented architecture.

Working within a distributed systems architecture, SOA has gained momentum because it creates reusable integrated business processes.

Tracking mediocre results and even failures in the implementation of SOAs, reveals many common trends, or “worst practices.” The top four worst practices for SOA integration include:

  • Overemphasizing low-level code,
  • Centralizing design and development,
  • Ripping and replacing legacy software and
  • Buying software without support.

These worst practices set companies on the path of SOA failure. They have been repeated by some of the best-run, 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.

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.

Solution: 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 SOAs build services for specific projects and then incrementally develop new services that are consistent and work in a mutually supportive way. Breaking the entire system into logical building blocks - also known as services - creates a sustainable solution 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.

Consider, 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 business processes become too complex, the amount of code that developers are required to write increases exponentially.

Worst Practice #2: Centralizing Design and Development

Here’s another example of an SOA integration project headed for failure: after purchasing its SOA integration tools, Company X assigns a centralized team to design and develop the application. These developers, who are part of the corporate IT organization, are able to code the services that are part of their day-to-day activities because they know the applications involved very well. But problems soon emerge.

One challenge is that only a few people will know how the SOA application was built. As people leave, that knowledge does too. But this is not the biggest pitfall of centralizing the design and
development of SOA.

Centralized groups create service isolation, which undermines SOA integration initiatives. Big
problems arise when the centralized development team starts to code services for applications that they do not work with every day and therefore do not know thoroughly. For example, SAP may be used in Germany, but not in the U.S. where the corporate SOA integration team is located. Coding SAP services requires a familiarity with the application and how it works. By asking developers unfamiliar with SAP to code the requisite services, organizations run the risk of inefficiencies that do not conform to standards.

Solution: Decentralizing Service Creation

Services should be decentralized and locally maintained. Only in this model can they ascend to
higher-level services without forcing the coarse-grained and global service developers to try and
keep up with underlying information assets. Consider that each information asset is constantly changing as a result of new releases, upgrades, fixes and patches. A centralized design and development team cannot know about every change made to every system in the enterprise.

When the design and development teams are decentralized, local developers and administrators
can change the underlying services without affecting the entire system. By developing the service close to the information asset, the people who work with the application every day and know its ins, outs and quirks are responsible for making any necessary changes to the services.

SAP, for example, is a complex application, and developers need to know how to use the tool to
develop services. Local SAP developers are much better suited to creating the library of reusable
SAP services because they have the requisite expertise in the technology. These services are then put into a registry managed by a centralized developer. The centralized developer is able to create workflows without actually maintaining the services.

When services are created, implemented and managed by people who have the expertise in manipulating the specific databases or applications, the development of coarse-grained and global services is much faster and more efficient since developers don’t become engulfed in the intricacies of each application.

Worst Practice #3: Ripping and Replacing Legacy Software

When it comes to updating IT infrastructures, some organizations believe this is a good time to
replace legacy systems with new technologies. This approach stems from the notion that new
technology must be better. In terms of SOA integration, organizations view the data in their legacy systems, not the application, as the main information asset. According to this notion, as long as the data is ported to another environment, nothing is lost.

This strategy doesn’t address the magnitude of data in legacy systems - an estimated 70 percent of the world’s data - nor does it recognize the fact that the application itself is truly an asset. When put into action, a rip-and-replace approach pans out as follows: Company X has decided to move forward with an SOA initiative, but as long as they are upgrading their IT architecture, they also opt to update some of their legacy systems at the same time. The applications that they choose to upgrade include purchasing, manufacturing, finance and payroll.

While attempting to port the data into its new environment, unexpected problems arise, delaying the move toward a reusable architecture and, more significantly, negatively impacting the day-to-day business operations of their mission-critical applications.

Solution: Reuse Is the Muse

If a legacy application is working, don’t try to fix it. Upgrading technology for technology’s sake is never a sound business option.

Maintaining systems crucial to an organization’s business is essential because they house the data and business processes that differentiate a company from its competitors and represent years of valuable intellectual property. When less drastic alternatives exist ripping legacy systems out and replacing them with newer systems, makes little fiscal or strategic sense.

Worst Practice #4: Buying Software Without Support

Purchasing SOA software is only the first step. How the software is utilized to implement a reusable SOA 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 professional services or a consulting organization. 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 implementation 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 an SOA.

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 an SOA requires different tools or features.

Solution: 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.

A learning curve exists for every integration project which is why it is helpful for organizations to secure support from the very beginning of the project.

How an organization designs message transformation and splitting makes a difference. It is better to take the time to do this up front than to struggle with performance issues once the architecture is up and running. By proceeding with sufficient support, organizations can avoid developing overly complex systems and know which tools are the right tools for which jobs.

While some of what has been mentioned may seem like common sense, you can bet that someone in your organization will begin efforts that will put into effect at least one of these worst practices. The good news is that you are now well-armed to identify and combat at least four SOA worst practices.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access