Cloud computing, SaaS and SOA - the universal service network
Something that's been sloshing gently around in my head for a little while came into focus the other day on reading a post by Brenda Michelson:
Unintentional Cloud Watching >> Cloud Computing for Enterprise Architects. Namely, that the link between cloud computing and SOA has multiple angles.
It's becoming clearer that, true to
Tim O'Reilly's initial Web 2.0 noodling, by providing open infrastructure services and APIs, the poster children of the Web 2.0 era - Amazon, Salesforce, Zoho, and so on - are now treading the path that companies like
StrikeIron started out on in 2002.
As a result, as other commentators have noted, it looks like the bulk of the service-oriented IT that many organisations will interact with will be "stuff from outside" (commercially provided services) rather than "stuff from inside" (internally developed services). And it's not just hosted SaaS providers who are playing here of course: there's the issue of newer versions of on-premise commercial packaged application software products and integrations between them - SOA is coming in by the back door there, too (see
SAP's ESOA,
Oracle's Fusion Architecture). In fact, perhaps unsurprisingly, there are strong parallels here with the component-based development (CBD) hype-wave of the 1990s - a lot of the initial hype was around tools and development for enterprise IT groups, but ultimately the vast bulk of development was actually carried out by commercial software vendors, for consumption by enterprise IT teams. What we're seeing here is a repeat of "
componentware" market development, with a 21st Century twist.
Regardless of where services come from (and indeed because they will come from multiple places, creating cross-enterprise service networks), it's increasingly the case that in order to deliver effective IT capabilities in the 21st Century, you need to understand SOA principles and build technology and management structures that really support the principles of service orientation. Much has been written about the "consumerisation of IT" and how new generations of people entering the workplace are asking difficult questions about why enterprise IT applications are so unintuitive to use. But what happens when business teams that are using SaaS-based offerings learn about the infrastructure side of the story - how easy they can be to customise, extend, and integrate with - and ask why internally-developed systems don't exhibit the same qualities? Another slab of SOA pressure, that's what.
Back in 2006 I was doing some research for an event that we were considering running on "IT Sourcing in the 21st Century". As part of trying to work out what might be in scope and what might be out of scope, I drew this picture:
As the picture attempts to show, from a technology architecture point of view, the software-as-a-service (SaaS) model relates to the prior Application Service Provider (ASP) model in much the same way as SOA relates to monolithic on-premise applications - to deliver value, both SaaS and SOA need to "crack the box open" and enable IT capabilities to be customised, composed and remixed while also being shareable/reusable. There's much I disagreed with about
Anne Thomas Manes' recent "SOA is dead" post (see
Schrodinger's SOA), but she nailed this parallel between SaaS and SOA pretty well I think.
With the increasing visibility of cloud-based infrastructure and application services in mind, anyone seriously pursuing SOA should be looking to the world of SaaS for insight, or at least inspiration. In the IT industry's rush to SOA, many of the nuances and implications of SOA have often been condensed into simplistic advice targeted at software developers (something that's been written about a great deal,
not least by us). One of the themes we've returned to again and again in our SOA advice is that the concept of a "service" isn't primarily about something you build - it's about something you experience. If you're going to deliver business value from your SOA efforts, you have to grasp the implications of this and make the necessary changes - not only in terms of tools and technologies, but also (crucially) in terms of your governance approach. One of the most popular posts from arch-architect Todd Biske, on
ITIL and SOA, digs nicely into how it's crucial to consider the full service lifecycle when you do SOA, and drive governance to ensure that you can deliver "real service" - not just code wrapped in XML-based interfaces.
The providers of cloud-based services should have this idea etched on their brains - and there are plenty of examples of this principle in action for any eager student of SOA. Witness the grumbles that echo
when Twitter barfs, for example, or see the
grumpy users trying to get to grips with Zoho's CRM API in the face of almost non-existent documentation. These are great examples of situations where the provider's idea of service doesn't match the consumer's expectation.
The rise of cloud computing and SaaS should entice us to revisit our development-centred assumptions about SOA and search for a "bigger picture" that focuses on consumer expectation and value first. The pressure to deliver business value from IT capabilities, and the increasingly diverse mix of IT capability sources, demands that we do so.
Labels: architecture, cloud computing, ITSM, SaaS, service, SOA
