Archive for the ‘service’ Category

Cloud computing, SaaS and SOA – the universal service network

Monday, February 23rd, 2009

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.

Posted in ITSM, SOA, SaaS, architecture, cloud computing, service | No Comments »

HP tightens up its SOA governance proposition

Tuesday, January 29th, 2008
HP yesterday announced long-awaited (at least as far as we are concerned) enhancements to its SOA software and services, which see the company beginning to realise the potential of its acquisition of Systinet (via Mercury) when it comes to SOA governance. Back in March, the other Neil highlighted that lifecycle management is one of the four key elements of an SOA functionality pyramid and is:
all about supporting development, integration and operations teams in linking their efforts to ensure that the consumer service experience is high-quality and consistent under potentially unpredictable circumstances. Typically the foundation of this capability is some kind of registry/repository, but ideally tools go further than this – firstly by helping to automate team workflows for implementing quality controls at design time; and secondly by helping to translate design intentions relating to operational SLAs into runtime policies which are tied into the infrastructure.

HP is attempting to go that bit further by more tightly integrating the registry/respository capabilities it acquired with Systinet to the policy-based management and monitoring capabilities of its SOA Manager product. Whilst HP also brings other valuable functionality to fill out the SOA pyramid, including business process monitoring (HP Process Insight), security and identity management (HP Select Access) and synthetic transaction monitoring and reporting (HP Business Availability Center) it does not – and nor would it claim to – have everything.

Enter the Governance Interoperability Framework (GIF) it inherited from Systinet. The GIF is designed to facilitate information exchange with the Systinet Registry and Repository allowing third parties to integrate relevant technologies, such as policy enforcement and service orchestration, with the SOA lifecycle management capabilities. As well as announcing 10 new GIF partners, HP is also publishing the GIF specifications.

Integration is not totally reliant on GIF though. Systinet’s registry is also embedded in the SOA infrastructure offerings from the likes of BEA, Oracle and TIBCO, which makes HP an obvious potential source of broader SOA lifecycle management functionality for their customers. The company is not such an obvious choice for customers of IBM and Software AG who are building out their own capabilities.

SOA platforms do not begin and end with BEA, IBM, Oracle, Software AG and TIBCO though. There are other choices: Microsoft, Progress, Red Hat and SAP etc. Not forgetting of course that organisations will be acquiring service oriented solutions as part of business applications. What’s the story there? There are two. The first is GIF. The second is the HP SOA Registry Foundation that also formed part of yesterday’s announcement and which the company describes as

a new software product expressly designed for independent software vendors. HP SOA Registry Foundation is a powerful, standards-based way to publish, categorize and discover SOA services and artifacts. This new product can be easily embedded with packaged applications and distributed solutions.

In other words, it’s an OEM-specific version of the registry designed to allow HP to replicate the BEA, Oracle and TIBCO agreements.

Coupled with the HP’s services capabilities, these announcements should mean that HP is able to exploit its systems management heritage and installed base to position itself as a credible SOA lifecycle management provider to organisations moving beyond project-level SOA initiatives – and to the software vendors that are helping them on that journey.

Posted in HP, SOA, UDDI, governance, service | No Comments »

Little SOA vs Big SOA

Thursday, April 26th, 2007

During our “off air” preamble with Miko Matsumura prior to recording our podcast earlier this week, he mentioned that he likes MWD’s focus on “Big SOA”.

I’d never thought of what we tell customers about SOA in this way before, but it’s true that we try and get people thinking about how SOA can help them transform their organisations in the long term by pushing the boundaries of SOA and not sticking with an overly-technical, bottom-up approach that sees SOA as “EAI with standards”. So Miko got me thinking about what, precisely, “Big SOA” might be and how it might be different from something that for the sake of argument we might call “little SOA”.

So I came up with a picture:

As the picture shows, I think the difference between “little” and “big” SOA comes down to how you look at the “S” and the “A” of SOA.

In “little SOA” (bottom left of the picture), organisations have a software development centric view of what a “service” is. A service is basically a standalone software component with some kind of remotely addressable invocation interface (let’s say a WS-* interface for now). In “little SOA” organisations have a similarly narrow view of what “architecture” is – architecture is basically software design with a corner office.

In “big SOA” (top right of the picture), organisations have a much broader view of what a “service” is. In this broader view a service isn’t something you build; it’s something that is experienced by a consumer. This view, therefore, is really about realising that delivering a service requires all sorts of IT competencies (design, development, integration, testing, deployment, admin, ops and change management) to be integrated together across the lifecycle of an investment that is packaged up as a service. That’s a very different perspective on “service” that is not coincidentally much closer to what a business exec would think of if you asked them what a “service” is. In big SOA organisations also have a broader view of what architecture is about. Architecture isn’t an inwardly-focused IT competence that seeks to make global optimisations to portfolios of software development projects. It’s an outwardly-focused business-IT communication competence that seeks to further understanding of IT within business, and of business within IT.

I don’t have hard quantitative data to back this up, but based on anecdotal evidence of customer conversations my feeling is that the majority of companies considering or starting out with SOA are doing “little SOA”.

What do you think?

Posted in SOA, architecture, service | 8 Comments »