What to do when insanity reigns
Q&A: Miko Matsumura on the State of SOA
(Miko Matsumura, vice president and deputy CTO, SOA products at Software AG webMethods)
Khan: "If you had to take a pause and assess the state of the SOA today, what do you see?"
Matsumura: "People have gone through all of the Kubler-Ross stages now and have come to acceptance of SOA. SOA isn't utopian in the sense that Adoption is painful and difficult. We have been through a lot of cycles where people look for escapist alternatives. But when you get down to it, IT System and Organizational sprawl is a disease, and if you don't cure this disease, your IT systems will become ossified, atherosclerotic, and will slowly become the cement boots that will drown your business. People are understanding both that the cure is as painful as the disease, or perhaps even more painful"
Joe McKendrick wrote in August 2007:
How do we really know when SOA ‘fails’?
"Lack of a true SOA...."
"Lack of reuse or sharing by multiple business units...."
"More money spent than gained — over the long run...."
"More, not less, vendor lock-in...."
From a March 2007 podcast (transcript): BriefingsDirect SOA Insights Analysts Explore SOA's Role Through Failure, Governance, Policy and Politics
Udi Dahan's recent presentation: Avoid a Failed SOA - Ness Tziona Usergroup meeting #2 - (pdf)
David Linthicum wrote in November 2007: Are You in SOA Project Hell?
"...a few key issues..."
- "Not enough budget..."
- "Not enough influence..."
- "Wrong people..."
- "Bad schedule..."
- "No plan, approach, or method..."
More recently, David Linthicum wrote in September 2008: SOA Deployments: What Actually Works
- "People: From Leadership to Staff, the Right Aptitude and Commitment Is Critical..."
- "Processes: SOA Requires a Change in How You Develop, Manage, and Test Applications..."
- "Architecture: The Core of SOA Is Usually Given Short Shrift..."
- "Technology: Your Technology Should Follow the Requirements, Not Drive Them..."
Anne Thomas Manes recently wrote: SOA vs SOI
Service oriented architecture is hard work. It's disruptive. It's a political minefield. It involves going through the application portfolio and identifying redundant applications that can be decommissioned and replaced by a single service. But no one ever wants to open that can of worms. Many folks live by the adage, "If it ain't broke, don't fix it." There's way too much other stuff to do. But each additional application increases the annual maintenance and operations budget. And for many of those applications, the cost of maintaining the application exceeds the value it brings to the business.
Also worth reading: Burton On Real World SOA Experiences
And just for the record, in general, when I find myself sometimes disagreeing with something Anne has written, I carefully review my assumptions and usually find myself altering my conclusions.
Mike Kavis: Top 10 Reasons Why People are Making SOA Fail
"1. They fail to explain SOA's business value...."
"2. They underestimate the impact of organizational change...."
"3. They fail to secure strong executive sponsorship...."
"4. They attempt to do SOA "on the cheap"..."
"5. They lack the required skills to deliver SOA...."
"6. They have poor project management..."
"7. They think of SOA as a project instead of an architecture..."
"8. They underestimate the complexity of SOA...."
"9. They fail to implement and adhere to SOA governance..."
"10. They let the vendors drive the architecture...."
Two SOA Projects That Can Pay For Themselves in Six Months
Frank Kenney (Gartner Analyst): Ahh Shucks, SOA Is A Failure
The Laws of SOA
Nicolai Bonne's blog: Thoughts on SOA successes and failures
Eclipse kills open-source SOA projects (After the hype, the hurt)
