A service-oriented architecture isn’t a technology; it’s a way of doing business. It can even be a way of transforming your business. A service-oriented architecture can be a powerful tool for changing your business—or a good way to boil the ocean. The keys to a successful SOA project are setting limits, mitigating risks, and giving the business what it wants and needs.Text
That point was driven home time and again this year by SOA-using CIO 100 honorees (and there were lots of them). Reworking your IT framework as an SOA takes time, money, nerve and a strong business driver. Done correctly and for the right reasons, an SOA can save money on development costs (eventually) and increase your agility.
But getting to an SOA requires bold thinking and even bolder action. To do it right, everyone in your enterprise, both on the IT and business sides, must change how they look at the business. It can force business-side people to put off short-term opportunity in favor of long-term goals. It can make IT developers think in terms of service levels and reusability while simultaneously forcing them to relinquish complete control over processes such as quality assurance. It’s about change management, technology management, risk management and simply dealing with management.
If all that sounds scary, it is. But step into the deep, dark SOA woods and you’ll find some trails are already being blazed. And our bold honorees have even left a few breadcrumbs for you to follow.
SOA Defined
At its simplest, an SOA turns application functionality into the software equivalent of Lego bricks. Take a piece of software (say, a customer-number verification tool), strap a well-defined interface onto it, and let other applications use the new “service” as needed. Create a library of such mix-and-match parts, and you can build composite applications to meet almost any business need, the same way Legos can morph from castle to crocodile to catapult when the same components are rearranged.
But unlike object-oriented programming, in which chunks of reusable code are compiled to create new applications, services can live on widely distributed servers, ready to be tapped only when needed. How services are built, on which operating systems they run or within which applications they reside aren’t important as long as they support standard connection interfaces.
If that sounds like pie in the sky for the IT crowd, you’re right to be skeptical. SOA isn’t a cure-all. Nor will it (or should it) replace every tightly integrated instance in your company. But employed properly, SOA can grease rusty IT joints and make the whole organization more flexible—a bold goal that made SOA a worthwhile risk for several of our honorees.
How SOA Can Change the Business
ProCard had a tough decision to make. The credit card services provider’s suite of products touted features that its biggest competitors (such as Visa) didn’t have, including the capability to update card holders’ personal information (such as increasing their credit limit or changing their mailing address) in real-time instead of with the standard overnight batch process—a boon for customer service and a sales edge in the extremely competitive credit card market.
But ProCard knew that the competition had to be thinking about developing similar solutions. So ProCard had a choice: Continue to use its real-time advantage as a lever to pry open new business, or boldly morph the feature into a product and turn its competitors into customers. ProCard risked the latter route, and it used an SOA to get there.
ProCard could have pulled the real-time code out of its application and rewritten it as a standalone product specifically for Visa (likely the fastest and easiest option), but the company had a vision of turning the feature into something widely available to numerous potential partners. And it could imagine other pieces of its application being spun off as separate products as well. An SOA approach let ProCard create a service-based product that customers could quickly integrate into their own operations, and it provided a foundation that will support other service products in the future, should ProCard decide to go that route.
But bold ideas often meet resistance, and this was no exception. The biggest hurdle to making the shift was convincing the business side that the goal—that is, modifying ProCard’s business model—was not only realistic but necessary.
“Technically, our folks got it very quickly,” says ProCard COO (formerly CIO) Ian Hill. “On the business side of the house, it took a little bit longer for folks to grasp the concept that we were going to enable a competitor.” One of the keys, Hill says, was to make sure he focused not on the technical advantages of an SOA but on the potential business benefits of moving from monolithic application vendor to service provider. “I believed that if we had the opportunity to offer our functionality in pieces via services,” Hill says, “there would be a significant piece of business out there for us that wouldn’t be there [otherwise].”
He notes that a number of banks wouldn’t consider buying ProCard’s suite of credit card processing tools (sometimes because they already had purchased products from other credit card associations). But those same institutions might be very interested in individual components—including the real-time updating feature—thus opening new markets for ProCard. “We don’t need to be the total solution for the institution,” Hill says.
“This is the dream [of SOA] come true at some level,” adds Hill. “It’s bigger than just technology. It fundamentally changed the way that we do business.”
The Technology Is Hard; Staffing Is Harder
SOA practitioners also make it clear that companies should not bite off a choke-inducing hunk when moving to an SOA. One way to minimize the risk of throwing the enterprise into turmoil while reshaping it is to pick a small or lucrative piece of the business to recast under an SOA as a means of getting your feet wet.
Guido Sacchi, CIO and executive director of shared services at consumer credit service provider CompuCredit, says he decided last year to go with an SOA for his company for several reasons: first, to reduce the complexity of his overall IT infrastructure and second, because he felt he could get results—in this case, dramatically reduced costs and increased flexibility—quickly, even before the total architecture was in place.
To maximize his investment and reduce his risk, he chose two pieces of his call center operations—inbound customer service and outbound collections—as early test cases for SOA, primarily because they were both solid revenue generators as well as high-cost. They also had the added benefit of providing relatively easy-to-quantify metrics (such as reduced time per call) that could be presented as proof of the SOA’s success.
The systems involved were also highly complex, with numerous interfaces built on extremely inflexible applications and complex underlying code. “If you wanted to make a change to a piece of software that supported a certain business process,” Sacchi says, “I would have to rewrite the application.” For instance, he says, if he had wanted to build extract, transform and load (ETL) software in the past, he’d have had to
