Putting the Serve in Server-March 2009
Anyone who’s used Amazon.com to purchase a book or CD has experienced service-oriented architecture (SOA). Users log onto the Web site, review offerings, and place selections in a shopping cart before checking out. In the process, an order is specified through one service, which interacts with an inventory service to see if items are in stock, which links to an order and shipping service that communicates with yet another service that enables users to track their order status. The entire soup-to-nuts transaction is managed through communications via Web services—supported by a service-oriented architecture—that appears seamless to customers.
“Each part of Amazon you interact with is an independent piece of the business process, but you’d never know it,” says Manish Sharma, a managing consultant with Ciber, a systems integration firm with an office in St. Louis Park. “[The system] is so interwoven that it becomes a seamless experience for the end-user.”
The architecture of an information technology (IT) system is the way its components are connected, organized, and controlled. While you may meet with many descriptions of SOA, it’s essentially an architectural style that enables companies to make information technology (IT) operations more agile, open, and efficient by facilitating interaction between disparate parts. In short, SOA turns the heterogeneity of IT systems and services into a business asset rather than a drag on productivity or efficiency.
SOA in Action
Although the SOA concept has been around for years and manifest in technologies such as electronic data interchange, the growth of Web services platforms and universal coding languages such as XML sparked the imagination of software vendors and helped bring SOA to a more sophisticated, strategic level—and into mainstream use within organizations.
While it’s common to hear “Web services” used synonymously with “SOA,” the two are distinct animals. “I think of service-oriented architecture as a set of principles or a style, and Web services as one implementation of that style,” says Aleh Matus, owner of Modelus, LLC, an IT consulting company in Plymouth.
Web services are application components (think of Salesforce.com or Basecamp.com), and SOA is the way they are connected. Sharma compares the effect that the proliferation of Web services has had on SOA to the impact Microsoft Access software had on the database market 10 years ago. MS Access was not a comprehensive database management or warehousing system, but it did allow users to quickly develop databases to “get from A to Z quickly,” he says. Web services had a comparable effect on SOA “by allowing people to implement a federated view of their IT enterprise very quickly,” Sharma says.
Because Web services are built with standardized languages and connected via the Internet, we take it for granted that, for instance, we’ll be able to integrate a Twitter feed and a separate blogging platform into our Web site. That interoperability allows the “federalized” view. In the same way, SOA can integrate Web services and company IT services to facilitate business processes across the enterprise.
But though it may seem like a shortcut to SOA, Sharma warns against the rampant adoption of Web services. “When I go into companies and hear they have 100 or more Web services up and running, I cringe a bit,” he says. “It tells me that symptomatically the organization has likely done an Access-like implementation of what should instead be a more comprehensive, coordinated online transaction processing system.”
Mark Richards, a director and senior solutions architect for Collaborative Consulting, LLC, in Boston who presented on SOA issues at a recent Minneapolis conference, says Web services “are just one of many possible implementations of SOA, and don’t represent a coordinated, comprehensive architecture or paradigm.”
Making the Business Case
Richards says SOA doesn’t make sense for all organizations, but it does have particular benefit in two situations: when economies of scale can be realized from SOA’s use or in environments that experience frequent change, which places a premium on the reusable elements of SOA.
Companies that have multiple product lines with commonalities in processing requirements for back-end systems can benefit from service-oriented architecture, Richards says. For example, an insurance company might have quoting systems for auto, home, life, boat, and other lines of insurance, with each of those systems having some overlap. Making a process or policy change in 10 separate systems would take considerable time; with SOA, a change can be made in one place that affects or updates all 10 systems simultaneously. In addition, IT will have saved money by integrating application servers, directory systems, portals, and mainframe applications as well as reusing software across business functions.
Sharma believes SOA’s biggest business benefit comes in “time to market” for new business services or applications by increasing interoperability between disparate systems. “It improves how quickly an organization can bring a new business capability into the enterprise,” he says.
Say a company wanted to add the ability for salespeople to place orders on a mobile device. If the system employed SOA, it would support a range of devices, in the same way you can place an order with Amazon.com via your computer or your Blackberry. SOA’s success also can be measured by how many point-to-point systems and data islands—data that is locked in departments due to incompatible systems—it reduces, as well as by how much of the domain knowledge within business units it turns into automated work flows.
Matt Leising, a solutions architect with Solution Design Group, an IT consulting and software application development firm in Minnetonka, believes that IT maintenance efficiencies alone make SOA a good investment. Leising says use of SOA helped one of his health care clients save considerable time and potential labor costs. Each time a new government or industry regulation was mandated, the company had to implement new business rules in each of multiple IT systems that were used to access key data. “That meant consulting with three different teams and implementing rules in three different areas, requiring a lot of coordination, developer time, and more,” Leising says. Now, with an SOA pattern, the medical firm only has to modify one set of business rules to satisfy new guidelines, a change that will affect all systems and decrease overall maintenance costs.
Richards also says SOA can be invaluable in situations where technology platforms frequently change or where there is a lot of disruptive merger and acquisition activity. “Changes in these situations can’t take years anymore, they need to take months or weeks,” Richards says. “That level of agility requires . . . SOA.”
Barriers to SOA
Many of the biggest challenges to implementing SOA revolve around “soft” issues such as cross-departmental cooperation, system governance, and maintenance. “SOA is inherently a shared asset that cuts across business lines, raising questions like who really owns it, who can change it, when can they change it, and the like,” Sharma says. “Getting people from different units to agree on one way of doing things is never easy.”
Experts say companies often are too quick to jump into SOA without thinking through all-important governance, maintenance, and security issues. Is there a shared services team, and who will be on it? Who will be responsible for maintenance and service level agreements for the various Web services?
“Too often the thinking is, ‘we need Web services or SOA now, so let’s just build it,’ without considering how it will affect the whole enterprise, and how the system will be governed after it’s up and running,” Leising says.
Most parts of an organization are touched by SOA, so all parties need to understand how they’ll be affected by any change in those linked business applications, Leising says. Without that, employees can arrive to work one day and find a change has been made that impairs the functions of a critical Web service, which can greatly impact things like customer service or productivity goals.
Richards also says that if SOA efforts don’t properly engage managers in the planning stages, and consult only IT on how the system should work, the architecture will likely underperform. “A lack of input from business unit managers and having only IT system architects defining key business services are warning signs of a dangerous and expensive road ahead,” Richards says. “There is plenty of attractiveness to SOA from an IT standpoint, but the business links and benefits must be strongly established.”
Organizations that struggle with implementing SOA and Web services also tend to make another miscalculation, says Chris Spurgat, president of Object Partners, an IT consulting company in Minneapolis. They pour all of their energy into building services that can be reused across the organization, instead of first focusing on ensuring they’re usable in one part of the business. Making reusability the chief goal often results in shortchanging the organization’s current needs.
“First, figure out how the service can be used today by existing applications, something which is already defined. Build the service that way and then let it grow and evolve as you find new uses for it,” Spurgat says. “If it becomes reusable across other applications or units, that’s gravy.”
Richards believes SOA’s most overlooked problem is how the data underlying linked applications is affected by the architecture. “The merging of services in SOA is fairly easy, but the consolidation of data involved is not nearly as straightforward,” he says. For example, an organization might have five different ways of keeping customer records in five silos or units of the organization; some records might be kept by full customer name, others by abbreviations, yet others identified by demographic information. So when an employee does a “customer lookup,” from which of those five systems is that information pulled, and what are the implications of that request?
“People in business units are keen on the idea of Web services, but my experience is you don’t dare touch their data,” Richards says. That concern has fueled the use of tools such data buses, a subsystem that transfers data between central processors and all internal devices. Unlike point to point connections, buses can connect several peripherals over the same set of wires. These buses can consolidate and abstract data for particular user purposes or “views.”
Getting companies with multiple business units to agree on requirements for Web services and their underlying data can be a major challenge, Spurgat says. Questions such as who owns the data and how it might consolidated should be dealt with up front in any SOA effort “because it can literally make or break that effort,” he says.