Put SOA to the test

Proponents of service-oriented architecture often talk about the technology in revolutionary terms, emphasizing SOA’s ability to cross information barriers and turn the world of software development upside down.The promise of SOA is a plug-and-play software environment of loosely coupled information technology services, or tasks. It replaces tightly integrated software applications that handle specific tasks. The SOA approach? Break up a software application into bite-size chunks with standard interfaces. Think of each chunk as a service that performs a basic task. Let other software developers use your service in their software applications. There’s no need to recode for every task. With a loose coupling of services, you can create a new software application.SOA’s value is the freedom to adapt software quickly to changing business needs, integrate new functions and spend scarce resources on new capabilities rather than on duplicating existing ones.But after the application development excitement fades, people have to think about managing the SOA application. “There’s an emerging understanding that the key to SOA capabilities and the SOA design pattern is a well-defined and enforceable governance capability, and a necessary component of SOA governance is the service-level agreement,” said Bernal Allen, who was chief of the Defense Information Systems Agency’s Enterprise Application Division. He is now a senior account executive at Raytheon Information Solutions. An SLA is a covenant between a service provider and service consumers. It’s a means of managing and enforcing expectations about performance under real-world conditions. SLAs are nothing new. They are one of the primary tools of software governance. And despite all the hubris about SOA being a new software paradigm, SLAs don’t change in a SOA environment. From a business perspective, the environment is the same, said Buddy Ritchie, Raytheon program manager of the National Oceanic and Atmospheric Administration’s Advanced Weather Interactive Processing System (AWIPS). In 2005, Raytheon won a $300 million contract to manage AWIPS and modify its software to run in a SOA environment.“SLAs are the customer telling us what they consider to be important,” Ritchie said. “Whether we are in the current software architecture or we are in the new architecture, that dialogue has to continue.”However, after people understand the purpose of an SLA, they still can appreciate that preparing and executing an SLA in a SOA environment presents special challenges. Agency officials should follow four basic steps when they craft an SLA in that environment.  On the surface, this requirement would seem to be no different from that of more traditional programming models in which somebody compiles a long list of user requirements and the information technology department writes code to match.  However, in a SOA environment, people should consider alternatives to business as usual, said Sam Ceccola, a vice president of technology transformation at Capgemini, a consulting company. “What are we doing to change business as usual?” should be  asked at the beginning of any SOA project, Ceccola said.People can use SOA to perform the same business tasks that previous software performed, but that misses the point of SOA’s flexibility and adaptability to changing business needs, Ceccola said.  When developing a SOA application, business or program leaders should define the outcomes they want, experts advise. Embed  those desired outcomes in an SLA between the business and technology sides of your organization. Chief information officers often complain that their business colleagues are indifferent about designing new IT environments, but they should make the effort.Bob Gourley, a former chief technology officer of the Defense Intelligence Agency, offers this advice to CIOs who encounter resistance. “The only thing I’ve seen that works is if you have smart IT folks with business experience who make assumptions about the business model, press ahead as if those assumptions are correct and then stand by to take grief if those assumptions are not correct.” Gourley is now CTO at Crucial Point, a technology research and advisory company.At some point, software designers must select performance indicators for technical services, including service availability, bandwidth and response times. Larry Fulton, a senior analyst at Forrester Research, uses the analogy of a consumer using an automated teller machine to explain how technical SLAs should be crafted. “It’s not enough that you put your card and PIN [in the machine] and request to withdraw cash,” Fulton said. “There’s an expectation of how fast that will happen, the level of reliability and the level of security.”Varied business needs require different technical thresholds. A military targeting application requires the highest levels of availability, whereas a civilian data analysis tool can probably operate at degraded performance levels outside of normal working hours. “Only negotiate the SLA that’s important to you,” said Mark Zalubas, CTO at Merlin International, an IT company. “It’s not one size fits all.”Because SOA applications have many loosely coupled services, SLAs can get complicated. For example, software designers need performance guarantees if they’re going to reuse a service. In that case, you’ll need a technical SLA between the service provider and the service consumer.That gets tricky, Zalubas said. Each individual service might be in compliance with its technical SLA and yet the overall application could still fail to meet its performance benchmarks. SLAs cannot be an afterthought, he said. They should become part of the system engineering process that occurs when SOA application developers are selecting services to incorporate or reuse. However, from a user standpoint, a SOA application should have one SLA — including a phone number — even if many sub-SLAs support it, Gourley said. “You have to be able to pin the rose on somebody.” A technical SLA lets you know what performance to expect from a SOA application, but how do you know if the application meets that benchmark? DISA’s Net-Centric Enterprise Services program created a SOA framework, a structured method for monitoring all service information going back and forth. “The common framework captures…service information,” regardless of the program or organizational entity, said Victor Harrison, a senior subject-matter expert at Computer Sciences Corp. CSC is supporting DISA’s SOA Foundation project. The agency declined to comment.You can adopt a less structured monitoring approach with a solution that vendors call enterprise service management. John Emerson, a vice president at AmberPoint, said ESM is performed by a series of monitoring stations dispersed throughout a SOA environment. “They collect data and, in most cases, they’re making a quick copy of the [service] message,” Emerson said. “They gather up the metrics that they’ve gathered, and they send them off to the server of the ESM system.” Regardless of how it is done, performance monitoring is an essential step in avoiding pass-the-buck arguments about who is responsible for performance failures.  Consider a scenario in which a service provider agrees to accept 10,000 consumer data queries in an hour. The consumer’s service information shows that the queries are not exceeding that level, but the application isn’t responding. Logs show that the consumer sent batches of 10,000 requests in 10 seconds in hourly pulses, and batch processing wasn’t part of the original SLA.An agreement to provide service without a mechanism to penalize noncompliance is no agreement at all. But that can sometimes occur with SOA SLAs.A user agency could say it has an SLA that guarantees performance levels, but a provider agency could argue that Congress doesn’t intend for the money it appropriates to the provider agency to be used to fix another agency’s IT problems. Although under various laws, notably the Economy Act of 1933, agencies can contract for services from another agency, the law when applied to SOA “gets into some sticky areas that are way out of the purview of IT people,” said Randy Hite, director of IT architecture and systems issues at the Government Accountability Office. “It starts getting lawyers involved.”Partly because of those legal and funding issues, SOA studies show that only 5 percent of reusable services actually are reused, Harrison said. It’s easy to find examples of organizations failing to fulfill their SLA agreements. “Every time that happens, there’s some crusty old program manager that says, ‘You see, I told you so. We should have done it ourselves,’ ” Gourley said.  For that reason, SLAs in the federal government are most effective within a single organization whose various parts are supported by the same source of funding. Not going outside the organization for reusable services is perceived as prudent, Gourley said. That constraint doesn’t necessarily apply to contracting with vendors for SOA services. Government agencies can try to financially penalize a vendor for reusable services that fall short of agency expectations. However, vendors are not eager to assume extra responsibility without getting paid. “Unless somebody brings money, technical cost and schedule, it stays with what my customer wants,” Raytheon’s Ritchie said. Even in the confines of a single organization, it takes leadership to get program managers to trust SLAs. “The first response is always, ‘I’ll do it all myself,’ ” Gourley said. SOA experts say chances are good that SOA will eventually attain its promise of flexibility, but they say it could fail. To date, most organizations aren’t getting “true mission value out of SOA,” Ceccola said. “They’re getting IT value.”  Technology has been down a similar road before. It was called object-oriented programming, the SOA of its day. Fifteen years ago, organizational and cultural hurdles similar to ones SOA now faces squashed object-oriented programming proponents in their attempts to revolutionize the IT environment, Ceccola said. However, Ceccola said he thinks SOA can succeed where object-oriented programming didn’t if organizations can make SLAs work. “It’s up to the service-level agreements, both at the technical level and the business level, to come together if we’re going to really see SOA live and become pervasive.” Perera () is a freelance writer.