<<Burton Group analysts spent the first few months of the year looking into SOA implementations and what they found was a landscape devastated by petty territorialism, lack of governance and the failure to involve the business.
According to Burton Group vice president and research director Anne Thomas Manes, some users had executed nearly perfectly in terms of doing SOA on the IT side, but the initiative had yielded no increased
agility, quicker time to market or project savings because the business remained completely oblivious to the initiative. Yet the study also found that users who do break down artificial corporate barriers, install proper governance and involve the business have runaway success stories to tell.
"The successes we found are just incredibly inspiring," Manes told attendees at last week's Burton Group Catalyst Conference.
She listed key attributes common to SOA success stories:
* Business and IT reorganization, usually with a new CIO coming on board
* Sponsorship at the C-level or by the Board of Directors
* Agile/iterative development methodologies put into place
* Projects tied to and measured by business goals, not IT drivers
* Well-defined funding and maintenance models that balance the needs of service providers and consumers
* A simplified architecture, making it easier to access and manage quality data
* A culture of trust between business and IT
Manes repeatedly returned to the issues of trust and culture. She placed the burden for creating that trust on the shoulders of the IT department.
"You're going to have to create some kind of culture shift," she said. "And you know what? You've been breaking their hearts for so many years, it's up to you to take the first step."
Cigna fails, then succeeds with SOA Chad Roberts, architecture director at Cigna Group Insurance, presented his company's experience with SOA. It started in 2004 with a technical focus mostly based on integration and rolled out its first successful project in 2005. Yet in 2006 a key project got cancelled
and the initiative ground to a halt.
"The perception of SOA being an IT thing was loud and clear," he said. Then a new CIO got hired in 2007 and made culture change a priority.
"We had to realize that we have to think about the business first and technology second," Roberts said. "Whether we like it or not, we are order takers to the business. … If I'm a claims guy, the last thing I
want to do is talk to an IT guy about SOA and how that's going to help me in the future when I've got systems that are failing today."
Manes found repeatedly in her research that the "if you build it, they will come" approach to SOA wound up a failure and Roberts confirmed that, saying, "We stopped trying to build business cases for SOA, it
wasn't working. Instead use SOA to strengthen the existing business case."
What Cigna did was "nail the basics," making sure the acute pain points of the business were being addressed and that projects delivered as promised. Architects also visited the various business units to gain intimate knowledge of how the business actually works.
"We had to be able to act and communicate like a business person," Roberts said.
The IT department was reorganized by function across business domains and it identified which domains were service providers and which ones were service consumers. The result has been a full slate of SOA
projects rolling into production with real business gains attached to them.
Common factors in SOA failure Burton Group found a 50% complete failure rate in the 20 companies
that took part in the study. Another 30% were considered neither successful nor wholly failed.
"Many of them had deployed multiple successful projects, but most of those projects were focused on just one integration problem," Manessaid. "It was just a bunch of Web services. … The service is only
built for one application and it's never going to be used again."
She noted that such projects amount only to a less efficient method of doing EAI. Instead she recommended users focus projects around quality data, systems modernization or business process automation.
Kinam Peter Kim, vice president of IT strategy and architecture, echoed Manes' disillusionment with integration-centric SOA, noting that his company did an inventory of its IT vendor products and
stopped counting when it reached 7,000.
"We decided to weed out and stop doing so many integration projects," he said. "What we needed was a simplified architecture."
Steven Warner, technical director at Northrop Grumman, emphasized that SOA, ideally, enables the technical implementation of a well-planned business process.
"BPM and SOA are like the peanut butter and the chocolate in the commercial the way they go together," he said.
Manes listed numerous other failure factors during her presentation, including:
* Lack of defined service models
* Infrastructure focus
* Governance only of SOAP-based systems, if that
* Failure of developers to leverage the runtime governance in place
* Initiatives led by and solely involving the app dev group
* Roadmaps lacking specificity
* Inability to measure ROI
* Project-centric culture
* An "I'm special" attitude
Manes mentioned that last point a few times during her presentation, noting that such a mindset can be "really devastating" to an SOA implementation.>>
You can read this at:
If the road to SOA adoption was measured like a 26-mile marathon, many corporations would still be in the first two miles—with a long way to go....
Posted by: one way link building | 14 July 2008 at 08:46