Rogue services could be the killer app in SOA … but not in a good way. Rogue services are killers in the Soprano's sense of the term, not the cute ironic buzz word sense popularized by software industry marketing mavens.
Some companies think that all they have to do is build enough services and they'll grow themselves an architecture, which is the furthest thing from the truth.
Senior AnalystZapThink LLC.
When Dan Foody, CTO, Sonic Software Corp., calls rogue services a "silent killer," he means it to be as funny as a heart attack. In extreme cases, he says, the havoc wrought by rogue services might lead to people going to jail or a company going out of business."
As Foody defines them, rogue services are simply Web services that get lost in the IT system and then cause problems because IT managers don't know they are there and don't know who might be using them.
Then in the worst case scenarios, the rogue service turns out to be part of a financial application, but it doesn't comply with business policies and it hasn't been audited for Sarbanes-Oxley compliance. Next thing you know, company executives are on the witness stand explaining why an unknown Web service was capturing credit card data that was then accessed by a hacker. That's a worst case scenario, but it's what Foody means by silent killer.Jason Bloomberg, a senior analyst at ZapThink LLC., and another voice warning against rogue services, describes the worst case scenario this way: "Think of a laptop with personal customer information left in a taxi, only now it's left in a Web service accessible from the Internet. Just as serious."
Killers though they may become, rogue services do not generally start out life as malicious code from evil hackers, Foody said.
"Rogue services can appear in lots of different ways that are non-malicious," he explains. "You bring in a packaged application. It may have a whole bunch of services in it that you just don't happen to be using, but they're in production and someone might be able to use those. Have those services gone through the proper vetting, making sure that they are not saving credit card information, or that they are complying with Sarbanes-Oxley requirements for your organization?"
Besides packaged applications, both Foody and Bloomberg agree that applications built by outside consultants or even well-meaning programmers on the company payroll, can become rogue services.
As CTO of a software vendor, Foody is not the voice crying in the IT wilderness out of purely altruistic motives. The Actional 6.0 Web service management platform that Sonic now markets since the acquisition of Actional by parent company Progress Software Corp., includes a discovery tool for finding rogue services.
Foody, who was CTO of Actional prior to the acquisition, said he demonstrates the discovery tool at customer sites and finds IT managers are shocked at the number of rouge services hidden in their systems.
"What we've seen is that a lot of people really have no view of what they really have in production, in terms of services and their applications," he said. "They may think they have lists of things in production. What we've found is that most of the time those lists are actually inaccurate because they are managed and maintained by people and people end up being fallible."
Another governance advocate, Tom Erickson, president of Systinet, a division of Mercury Interactive Corp., agrees the problem of rogue services is real, but he does not find it as prevalent in this stage of SOA and Web services adoption.
"We haven't seen it much yet," he said, "but obviously that's a big concern downstream, especially with anyone focused on governance."
Systinet has automated discovery for rogue services on its roadmap, Erickson said, as the company anticipates the problem growing.
"It's not a problem in the implementations we're seeing today," he said. "We think it's still a little bit too early. But having said that, the whole thing about Web services is it's a groundswell. It's not something you're going to be able to heavily control. So there's going to be the combination of well-disciplined services and rogue services, no doubt about that."
Being in the SOA governance business, Erickson advocates following strong policies and procedures in Web services development as a way of minimizing the problem.
"Anybody who is following a good governance process, which we would obviously advocate, you're not going to have that many rogue services," he said.
This governance view is shared by ZapThink's Bloomberg, although he finds that not only are rogue services a "very real problem," but also a present danger.
"We're seeing them all over the place," he said, sharing the concerns of Foody. But reflecting Erickson's view, the analyst argues that it is first of all a management and governance issue.
"These services often don't have the appropriate management infrastructure in place to ensure their reliability and availability, impacting their loose coupling, and they are also ungoverned, which means they can potentially violate corporate policies of various sorts," Bloomberg said.
But a second part of the problem in the analyst's view is the proliferation of Web services by organizations that believe that they are doing SOA when they may only be creating IT chaos.
"Some companies think that all they have to do is build enough services and they'll grow themselves an architecture, which is the furthest thing from the truth," Bloomberg said. In his view this ungoverned production of Web services not only creates potential rogue services, but because they are unknowns, they often provide redundant capabilities that defeats the purpose of reuse in SOA.
"The key to solving the rogue services problem is to have architecture drive the creation and management of services," the analyst said. "Services built as part of an SOA initiative should be managed, secure and governed, which can lead to the reduction of redundancy as well as the other promised benefits of SOA."