Most of you have no doubt felt the aftershocks of the Service-oriented architecture (SOA) Obituary (http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html) posted earlier this year by Anne Thomas Manes.  This post created a huge chain reaction in the blogosphere, with people on both sides of the fence chiming in.  This idea gained momentum as it circled the globe, but it also got people thinking about the true value proposition for SOA.

SOA had been largely touted by hardware and software vendors as a silver bullet with the promise of transforming your enterprise into a lean and mean machine.  Cost savings, agility, and quality would pour from the goblets of those who embraced it – right out of the box!  New business partners?  New business services?  New business model?  No problem!  SOA to the rescue!

This is reminiscent of a magic diet pill which promises to let the pounds melt away while you sleep.  Exercise?  No need!  Even enjoy same foods you currently eat!

What seems to have been conveniently overlooked in this positioning of SOA is that it is not something you can buy.  SOA is a set of architectural principles that address difficult, real-world problems.  People often talk about SOA implementations, SOA initiatives, or SOA projects.  What they should be talking about is “adopting SOA principles” instead.  SOA is not a solution, it is a set of principles.  In order to get to solution you need to implement these principles.  And, of course, to get to a solution, you need to solve your current problem.

And what better place to start than the existing application portfolio – a pain point for any large organization?  The main problem here is that you have to play the hand you are dealt.  If you start with a complex environment of legacy applications with an intricate web of dependencies and relationships and hope to fix it overnight you really are going to need a silver bullet.  SOA is not a magic diet pill. Critical to the success of an SOA implementation is a disruption to the status quo. Anne makes this point nicely in her blog:

“Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates. The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.”

SOA requires a disruption of the status quo.  How true.  It is precisely because organizations have woken up and realized that the status quo is actually not working that they need a change from it.

I have been giving a lot of thought lately to the challenges of creating shared services in an enterprise environment.  Shared services remove redundancy within the application portfolio, reduce development and maintenance costs, improve time-to-market for new applications, enable consistency of service delivery, and increase the overall quality of the applications using these services.   They form the foundation of a service-oriented architecture (SOA), and bring agility to the organization.

I want to pick on one specific obstacle to the creation of shared service: siloed project funding models.  There is an interesting parallel between siloed funding models and the classical Prisoner’s Dilemma problem: both result in a sub-optimal solution.  In the classical prisoner’s dilemma, two suspects are arrested and separated for interrogation.  Each is offered the same deal: testify against the other or remain silent.  If one prisoner testifies against the other and the other remains silent, the first one goes free and the other receives a 10-year sentence.  If both testify against the other, they each receive a five-year sentence, and if both remain silent, they each receive a six-month sentence.

No matter what decision the other prisoner makes, each prisoner is better off testifying against the other as they will receive a shorter prison sentence.  That is, if prisoner A remains silent, prisoner B will go free if he testifies against prisoner A, but will get six months if he remains silent.  If prisoner A testifies, prisoner B will get five years if he testifies, but will get 10 years if he remains silent.  The payoff for testifying is always greater than for remaining silent.  Or is it?

Using the above logic, both prisoners testify against each other and receive five-year sentences.  Somewhat paradoxically, if both prisoners remain silent, they will each only receive a six-month sentence.  But I just told you that each prisoner would be better off, regardless of what the other prisoner chooses, if they testify against the other prisoner.  Thus the dilemma.  The optimal solution can only be achieved if each prisoner trusts the other to remain silent, and remain silent themselves.

In a similar way, some organizations have funding models that give control over project selection and spending to each line of business, with no incentives to drive cooperation or horizontal initiatives.  This can present a significant challenge for the development of shared services. Shared services are more costly and take longer to build than proprietary services. More people have to be consulted.  More thought has to be put into the design to meet the requirements of all stakeholders, and more time has to be spent on security, reliability, scalability, SLAs, etc….  Over the long-run, these costs are recovered through software reuse, reduced maintenance costs, and increased quality.  Just as with the prisoner’s dilemma, the optimal solution can only be reached through trust and partnership.

I am excited that “service mash-ups” has been selected as the theme for this year’s GTEC conference.   In fact, there is a lot about mashups to be excited about.  They extend the capabilities of an organization and provide a platform for productivity which challenges traditional roles, responsibilities, and boundaries.   Mashups fill a need that is not met: if the current application portfolio did everything that was needed, we wouldn’t need mashups.  Mashups shake things up and fill this gap. And what’s not to like about a good shake-up?  Mashups symbolize a shift in the landscape for productivity within an organization.

Mashups have a lot more to do with enterprise architecture than might immediately meet the eye.  They are all about reusing existing IT assets, optimizing service capabilities of the organization, aligning IT with business, and delivering control of creating solutions directly into the hands of the users of these solutions.   In this way, mashups can play a key role in the enterprise architecture of an organization.

There are two striking ways in which mashups change the landscape for productivity: ease of assembly of software solutions, and change of responsibilities for software development.  Mashups provide an environment for rapidly building new solutions by leveraging existing data sources, processes, and user interface gadgets.  These assets can be quickly and easily orchestrated to form a new solution, often used in a context beyond their original intent.  This greatly extends the capabilities of the organization and provides a platform for a level of productivity previously unseen.  These solutions can be created by anyone – not just the IT department – and do not follow the same protracted lifecycle for the delivery of “official” applications.  This type of opportunistic programming is a new concept for most organizations.

Mashups also represent a change in the way IT is viewed within an organization.  Given this shift, it is important to recognize the role that traditional IT plays in enabling a mashup platform in the first place.  You can only mash what you have at your disposal.  Items to be mashed must first be defined and wrapped with a formal interface.  Someone, somewhere, will have to do this work.  For now, this work remains firmly within the IT department.  It is the job of architects and developers to build the underlying building blocks of the mashup platform.  These building blocks, or services, are then exposed in the “formal” environment for use in mashups.  If this sounds to you like a service-oriented architecture (SOA), you are bang on the money.  We can greatly improve our efforts in the mashup arena by taking clues from the world of SOA.  After all, if we are shaking things up, let’s do it right.