This week’s IBM Impact conference in Las Vegas is only the third incarnation of the service-oriented architecture-focused event. But even though the conference (and SOA itself) is in its infancy, a wide variety of mature customers have flocked to the show, offering up SOA best practices and experiences.
Here are five sure-fire ways to ensure you’re on the path to a smart SOA strategy.
1. The first rule about SOA: Don’t talk about SOA
According to Rao Tadepalli, CIO at Encino, Calif.-based insurance firm Republic Indemnity Co. of America, trying to get corporate buy-in for an SOA initiative is probably best done by not mentioning the term at all.
“You have to try not to intimidate them,” he said. “Don’t say SOA.”
Instead, IT leaders would be wise to use a term such as business service orientation, said Steve Pratt, CTO at Houston-based energy provider CenterPoint Energy Inc.
“Years ago, when my boss went to the CEO of the company and said, 'We’re going to have a CTO, he said, ‘Why do we need that person? We have enough technology already,” he said. “That brought the point home that you can’t go to the business and talk technical.
“They don’t care what’s under the hood,” Pratt added, stressing the need for technology stakeholders to focus on the benefits of the architecture, instead of how many services they’ve developed.
And while many IT managers might not have the time to pick up a night school course in Marketing 101, that could just be the best way to gain corporate sponsorship.
“The only time employees get an e-mail and hear from us is when something goes down,” Tadepalli said. “We need to do a better job in marketing the value we bring to the table.”
More IBM Impact coverage: Don't tell IBM that SOA is dead
2. Rome wasn’t built in a day
But being able to effectively market your SOA projects will only work if you actually have something valuable to say, Tadepalli said. And the only way to do that is to start small and get a service off the ground.
“Instead of the big bang approach, we did one process at a time,” he said. That meant identifying the business processes that brought the most value and working on that service first.
For Republic Indemnity, the easiest service to tackle was the insurance renewal process. Because the service was geared toward existing customers, it didn’t require the company to increase their advertising spend and the financial benefits could be explained to corporate stakeholders very clearly, Tadepalli added.
And for a company that might be expanding into a new province or state, having the processes in place to quickly provision existing services as you expand can also demonstrate quick cost savings, he said.
3. Develop a governance model
While demonstrating value to corporate stakeholders requires IT leaders to change the way they communicate with the C-suite, it also requires cultural changes in the IT organization itself.
The biggest technical challenge for an SOA initiative is not getting developers to embrace the concept, but rather getting them to truly understand it, Pratt said.
“It’s not, ‘I write my service and you write yours, but mine’s better because I wrote it,’” he said. That kind of thinking will sink a project quickly, Pratt said.
Ultimately, having a governance model for SOA will be as important as the roadmap itself and will help you avoid redundant services, he said. “You could have policies in place, but if you’re writing a lot of services, you’re going to need a repository in place for those services.”
According to Judith Hurwitz, president of Newton, Mass.-based Hurwitz & Associates and co-author of Service-Oriented Architecture for Dummies, establishing the rules that govern who has access to what code and the proper procedures to follow when modifying a service can cause headaches for many IT shops.
“If you roll out one order-to-cash piece of code that’s been around for 15 years into a business service, are your staff allowed to change it?” she asked. “And if they are, who signs off on that decision?”
And it’s not just about who can go in and change the code, Pratt said, but also about who’s consuming the service and the technologies in place to monitor the consumption of those services.
“If you don’t do this, you’re going to have a difficult time managing capacity and determining the value of a service,” he said.
4. Don’t treat SOA like normal IT
Running your SOA project as you would any other IT project will have you destined for failure, said Bob Bates, vice-president of technology solutions at Dallas-based IT services firm Affiliated Computer Services Inc.
“Yes, it’s six million lines of code, but at the end of the day, it's only five or six key processes,” he said. SOA allows IT organizations to digest this, he added, but only if multiple business units work together.
At ACS, Bates organizes a scrum meeting every week that brings together business analysts, testing teams, and other partners to examine how to streamline processes and eliminate redundant services.
In the IT shop itself, Tadepalli advises IT managers to look beyond picking developers with talent, and instead, target employees that are good learners. “If you get people who don’t have that mindset, you’ll be in trouble.”
Hurwitz added that evaluating existing developers is important and “even though they might be working in COBOL, if they really understand the business and are good at what they do, they should be included.”
IT leaders would also be wise to look for volunteers when initially rolling out a service-oriented approach, Pratt said.
“Don’t come out and say, ‘We’re all going to change to SOA,’” he said. “It works well to start with a small group of people who want to be onboard.”
As the project moves along, the rest of the IT organizations will see your successes and beg to join in.
5. Don’t be afraid to get help
For Tadepalli, calling on IBM insurance specialists and business partners to guide his company through the initial service processes was crucial. “One of the challenges is integration, because there are so many tools out there that need to be connected to one another,” he said. “Being in insurance, we are all about risk, that’s why we stick with one vendor that we know can communicate well.”
And while it’s important to have a SOA roadmap, you don’t need to go to one vendor and buy all of their SOA tools, Pratt said.
“Also, if a vendor says that they’re going to sell you SOA, take them off the list,” Pratt said. “You do SOA, you don’t get sold SOA.”