San Francisco – Analysts practically wear themselves out saying "service-oriented architecture is something you do, not something you buy," but during last week's Burton Group Catalyst Conference it became clear too many users are trying to take a shortcut to SOA by buying the latest got-to-have-it software package.
Burton analysts stressed that you don't need to chase after some enterprise service bus with every possible widget or try to support the latest chic Web services standards in order to achieve service orientation.
"SOA is an enterprise architecture style, not an application architecture style," said Anne Thomas Manes, Burton Group vice president and research director. She estimated it could take 20 years to realize all the benefits of service orientation, which she listed as:
- Increased flexibility and agility
- Improved application quality
- Reduced time to market
- Increased ease of doing business
- Improved consistency in systems
She suggested measuring business improvement to track SOA progress and urged users to model their business, not their technology, when setting out on the path to SOA.
"The technology really is irrelevant," she said. "The technology you use today is going to go away at some point. It's about how you use technology, not what technology you use."
Chris Haddad, vice president and service director at Burton Group, noted that many SOA installations are falling victims to anti-patterns, which are mostly worst practices inherited from client-server development. Haddad's list of anti-patterns:
- Isolation – includes point-to-point connections and standalone silos.
- Uniqueness – includes multiple end-user entry to access a capability and independent schema models for similar entities, transactions and processes.
- Duplication – includes multiple software applications delivering similar business functionality, continuous sign-on challenge prompts and redundant data entry.
"It's just too tempting for development teams, which is what I used to be, to go off and do their own thing," Haddad said. He added that when he goes out into the field, he rarely finds reference architecture models, implementations commonly don't conform to what was modeled and key IT performance indicators (like an inventory of integration connections) are not known.
Most of all, Haddad said elements such as collaboration, trust and confidence are lacking for many would-be SOA adopters. One technical tip he offered to creating an organization that can work together is to "build common data definitions and expand them across your development teams."
That's exactly what Sam Joseph, senior technologist at retail brokerage Raymond James & Associates Inc., did in helping to create a common lexicon for business and technical terminology across his company. He recommended getting someone with established skills in information modeling and classification theory to help do the work.
Having all terms well understood by all parties is critical to building out a proper architectural model, he noted.
Anil John, information technologist at Johns Hopkins University's Applied Physics Labs, said, "It took us about two years to build a community capable of collaboration."
He also echoed the analysts in saying there is a tendency in all phases of IT to focus on specific technology instead of what elements of the business to support, a habit IT shops need to break in his opinion.
"Prioritizing what services to build is more important than buying the machinery to build the services," he said.
Sri Muthu, vice president of Internet service development at Wells Fargo Inc., stressed the need for complete lifecycle support for schema and Web services artifacts.
"It's really easy to build a Web service," he said. "It's really easy to consume a Web service, but it's really hard to manage a Web service."
That difficulty extends into finding the people to understand the SOA paradigm. "Don't underestimate how long your designers and architects are going to take to learn services," Muthu said.
It all came back to Manes' assertion that "technology is irrelevant." She said that governance, quality and management are the keys to a successful SOA, not an integration bus.
"There is no easy way to do this," she said. "It takes organizational discipline."