<<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," Manes
said. "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:
http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1319609,00.html?track=NL-110&ad=649093&asrc=EM_NLN_3958312&uid=5532089
Gervas
