A New Blueprint for I.T.

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.

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 build it for each application separately. With an SOA, Sacchi says, he wanted to create applications as flexible building blocks that would allow for easier process changes and reduced development time on future projects. So he could build his ETL once, for example, and expose it as a service to multiple applications.

It worked, Sacchi says, and provided a measurable reduction in call time. Instead of forcing call center staff to jump back and forth between applications, the SOA allowed his team to integrate features such as an automatic payment function into a single-user interface. And the IT department didn’t have to rebuild the feature in every application. But the results came with a learning curve, particularly in the area of staff training and skills.

“In hindsight, I should have concentrated on [staffing issues] a little bit more,” he concedes, noting that it was difficult to find IT people with SOA experience. And he advises other IT executives with SOA on their minds to pay attention to staffing as well. “Do you have the right skill sets, and can you train your people?” he asks. “It’s not easy to find people able to build these types of architectures. It created strains on recruiting,” he says. “Even the vendors don’t have that much talent in this space right now, and you really need to get top talent in-house.”

ProCard’s Hill had somewhat different issues with his staff. He says that while his development teams grasped the technology behind SOA quickly (they had already been working with .Net and Web services, around which ProCard built its SOA), making the move from application builder to service provider required a significant change of perspective. Moving to a services stance, for instance, forced ProCard to revamp how it handled development, testing and quality assurance. “In the past, we had complete control over QA cycles and when we were going to test things and where we were going to release code,” Hill says. “Now we have Visa, which has a front end using us as middleware to a back end.” That change meant ProCard no longer could develop or quality-test the end-to-end product in the same way it had in the past, when the company controlled everything from the back-end database to the interface the customer used to access ProCard’s tools.

The Bold Compromise on SOA

Experience teaches that a successful SOA requires evangelism but not zealotry. It’s critical to curb the urge to service-enable every project. “Some [SOA] purists think we can have common services across all seven [of our] brands,” says 1-800-Flowers.com CIO Enzo Micali. “Practically speaking, our intent is to have a set of business services per brand.”

Micali says that he has an architecture team and a pair of development teams (one for customer-facing application services and the other for core application services) whose job, at least in part, is to identify which projects are suitable for development within an SOA framework. “Between those folks and myself, we find commonalities in business requirements and expose things as needed,” he says. In the end, according to Micali, common sense must prevail to strike a balance between business users’ desire for immediate gratification and software developers’ drive to perfection.

He also notes that when time to deployment or overall application performance are the most critical factors, one-offs, rather than a service, are still the best way to go. And he’s not alone. Danny Peltz, executive vice president of Wells Fargo Wholesale Internet and Treasury Solutions, has watched his group’s infrastructure evolve into an SOA during the past five years (a period during which the company enticed more than 70 percent of its commercial banking customers to use Web-based, service-oriented tools instead of client-side software or live agents, resulting in faster speed to market with new products as well as lower costs). But, he says, many of his projects are still written for a single case rather than being opened up as a service. While he has found benefit (including reusability) in moving some core pieces of functionality (such as authorization tools) to the SOA, he warns that there are hidden costs to doing so. Simply building a component as a service isn’t the end of the process; the company must also bear the ongoing cost of managing that service’s use and reuse. In some cases, such as an authorization or security parameter or a search facility that can be reapplied to many applications, that overhead is justified. But there are times when taking advantage of an immediate opportunity or the need to have a tool specifically customized to one application negates the value of SOA. He notes that companies have a choice presented to them by their business units of “building once for all and building once for me,” adding that, “We lean more toward the ’building once for me.’”

Micali agrees, noting that some SOA purists will always say, If everybody could just wait until I’m done, we’d have this great service. But, he cautions, in the business world you don’t always have the luxury of time. Instead, he advises that even in cases where an effort is ripe for service orientation, it pays to “try to give the business what they need when they need it,” even if you know that you’ll want to generalize the application later.

Reaping SOA’s Rewards

Despite these caveats, there are plenty of benefits that SOA can provide beyond the flexibility for which it is so often praised. In cases where a common function would previously have been rebuilt for each new application, building it as a service can reduce development costs. “The marginal cost for putting on the next Web service is zero,” CompuCredit’s Sacchi says. For instance, he notes, connecting his service-enabled automatic payment feature to the interface utilized by collection-business employees was simple, even though the payment component exists in an entirely different application. By obviating the necessity for agents to switch between multiple customer service applications when dealing with a customer, it allows for faster service and reduced costs.

The SOA provided Sacchi with another benefit as well: governance. Moving to an SOA required the formation of an architecture team to determine the best path for the company as a whole. But what started as a tool for managing the move to SOA has become a central way of managing IT at CompuCredit.

“Now we do everything that way,” Sacchi says.

Given our honorees’ success, SOA is a concept every CIO should investigate. But if you do decide to go the SOA route, practitioners advice caution and commitment.

“Make sure you know what you are getting yourself into,” Sacchi warns. “It’s not just about the architecture: You need to dedicate the entire organization to services, to make a commitment to say, ’I’m running a service-oriented organization, hence I need an SOA.’”

Micali concurs, noting that the best route is the slow route. “Don’t try to boil the ocean,” he says. “Build it over time, and give the business [users] what they need.”

Technology Editor Christopher Lindquist can be reached at clindquist@cio.com.