Patterns of SOA success

Acknowledging that there is now "more hype than actual work" in the field of SOA, David Linthicum, a prolific author and host of SOA Expert Podcast, offers several patterns of success to think about as one puts their SOA plans to work.  "These patterns are not always obvious, so perhaps this is a good time to learn through the successes of others and do our own homework before we spend millions on moving to an SOA," he says.

While he notes that "some of this is trial and error," he nevertheless insists that certain patterns are emerging. Among these successful patterns and practices:

Focus holistically, act locally. SOAs are all-encompassing architectures, not mere projects, and those who consider them "projects" are doomed to failure. You're in for a pound when implementing an SOA due to the fact that, the more penetration the architecture gets, the more value it has within the enterprise.

Define the value. [W]e have a tendency to leverage the most popular technology without regard for how its use will affect the bottom line - not a good practice if you want IT to have a strategic position within an organization. We [need to] build SOAs because they provide an infrastructure for agility, or the ability to change processes in support of a changing business, or both. They also allow for reuse [and] services should be designed for reuse.

Don't neglect service design. At the end of the day, services are small, specific applications and need just as much attention paid to design. If SOA supports composite applications and composite processes made up of services, then the overall design of services will determine the overall success of things made out of those services.

Remember the semantics. If you don't understand application semantics, or, simply put, the meaning of data, then you have no hope of creating a proper SOA. You must understand the data to define the proper integration flows and transformation scenarios, and provide service-oriented frameworks to your data integration domain, which means levels of abstraction, as well as how data is bound to services.

The proper place for orchestration. For our purposes we can define orchestration as a standards-based mechanism that defines how Web services work together, including business logic, sequencing, exception handling, and process decomposition, including service and process reuse. While all SOAs don't need orchestration, most do, and you must find the right fit and application.

Classify the patterns of use. As we build an SOA, we need to determine how the SOA will be leveraged within the enterprise - not only now, but in the future. Thus we need to determine patterns of use for several reasons, including:

• Understanding the value of the SOA
• Understanding how we will test the SOA
• Understanding how we can improve the SOA

Persistence is important. You need to think about persistence for a few reasons, including federation of services around the SOA. When building an SOA you may end up with composites or processes created out of services that may exist over a dozen or more different systems, and as such, persistence becomes more complex if done at the points. So, in these types of situations (which are becoming more common), it makes good sense to centralize the persistence for the composites and processes, as well as some supporting services to a central data tier or central data service. This data tier exposes a custom schema view or views to the composites, and may also abstract some data at the points as well.

"New patterns continue to emerge, and each SOA is unique and deserves careful consideration," concludes Linthicum. "However, these patterns should provide a good base on which to plan your next SOA."