Enterprise SOA: End Of The Line?
There’s been plenty of discussion across the blogosphere, analystphere, conferencesphere, and mediasphere about how SOA has not been quite making it because it hasn’t been surfacing on the enterprise level. Instead, SOA has been mainly seen in departmental or single business unit settings.Zapthink has long argued for more targeted approaches to SOA, or Pragmatic SOA as they called it. As we reported in an earlier article:
... success with SOA rarely necessitates comprehensive change; instead, architects who choose their SOA battles carefully can deliver on SOA's promises to the business via projects of limited scope. Architects who miss this point often set the bar for SOA success too high ...The same argument holds true for most new technologies: with very few exceptions, for many reasons an evolutionary approach to use has a higher chance for success than a revolutionary approach. The larger the organization and the larger the scale of potential deployment opportunities, the smaller the chance that you can get everyone to agree to the necessary changes in the necessary time-frame. Joe goes on to discuss how he hears echoes of "Geurilla SOA" in what Zapthink say:
... well-targeted, lightweight engagements to address specific business problems, versus the Big SOA approach promoted by many vendorsHowever, Jeff Schneider disagrees with Joe in general:
... [Joe] implies that 'enterprise SOA is failing' which couldn't be farther from the truth. I believe that his bad information comes from people who don't know SOA, don't do SOA and in some cases, caused the mess that SOA cleans up.And he also disagrees with Joe and others concerning "Geurilla SOA":
... the idiots that are running around yelling "guerrilla SOA" have to be put in their place. Many of these individuals are the ones responsible for silo-oriented thinking in the first place. They proposed small (agile) projects where we captured just enough requirements to begin coding and releasing. Guess what? This style of development doesn't jive with the concept of shared services. It is the cause of the problem, not the solution.Furthermore, as Miko points out, enterprise SOA is hard (as is enterprise Java, enterprise CORBA, enterprise XYZ), so it should be no wonder that the number of successful examples are limited at this point: but give it time:
So while it may be helpful for us to look at the eventuality of Enterprise (intergalactic) SOA, it’s enough at the moment to establish “Interplanetary” SOA. Lets get the Development Martians talking to the IT Operations Venusians about Service Lifecycle Governance.Although Joe agrees that both have valid points, he stands by his view that things are not all well in the State of SOA:
The bottom line is that organizations that really need SOA the most to reform and reshape their processes are the ones least likely to adopt SOA. For most of these organizations, service-orientation will be spotty, uneven, without purpose, and often without the full support of the enterprise — or perhaps no support at all. There will be plenty of SOA proponents forced to go it alone, building success one process at a time. Guerrilla tactics may be the only way forward here.But there does seem to be some agreement. Whether or it's "Geurilla SOA", or Pragmatic SOA, Joe mentions that successful enterprise SOA deployments he's been involved with have involved some partitioning of the deployment space, but with the whole picture still kept in mind:
They don’t do it for the entire enterprise all at once - that isn’t what ‘enterprise SOA’ means. Instead, they partition their enterprise into a set of communities and attack them, often in parallel.To which Joe responds:
Perhaps we tend to think too small when it comes to SOA. Maybe we need to start ‘thinking big.’ As with anything in life, constrained, limited thinking leads to mediocrity. Dreaming big opens up the universe to new possibilities, new ideas, and new innovation. In the long run, SOA is far more than standardized interfaces or streamlined processes ... SOA has the potential to reorder organizations into confederations of entrepreneurs and brokered services that will open up new opportunities for everyone in the economy.
The people who he calls idiots are merely saying: it's easier to get forgiveness than it is to get permission.
It's also easier to get forgiveness before you call people idiots than after.
think globally act locally
Joost de Vries
These issues aren't so much design issues but organisation-change issues. That takes a wholly different tool set.
Agile is the cause of the problem?
The vast majority of the enterprise mess is from legacy systems created pre-Agile.
These are the critically deformed progeny of projects with a lack of collaboration, lack of domain-driven design, lack of "think big, act small" (or globally/locally" as Joost points out), all-you-can-eat requirements, and framed with cost-blowouts and anti inter-departmental sharing budgets in mind.
That's what I'm thunkin anyways, aherk.
Re: Agile is the cause of the problem?
You are correct; the vast majority of the mess was pre-agile mostly becuase the vast majority of the systems that exist were created pre-agile. As a proponent of spiral development in 1993, I got a kick out of people getting excited about iterative & agile ten years later. Not all 'pre-agile' systems were waterfall.
Most people will agree that a continuum exists between agility/rapid results and long term planning. E-SOA is fundamentally closer to the planning side than the agility side. It's wonderful fun to claim that you can have your cake and eat it too. However, reality is that E-SOA requires more planning than knocking out an agile application. It's extremely dangerous to tell people it isn't.
There are lessons to be learned from waterfall, spiral, iterative and agile that should be applied towards SOA.
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014
Andrew Stellman Mar 06, 2014