Seven elements of Cloud value: public vs private

In last week's post on the seven elements of Cloud computing's value, I said that the simple model I put forward looked like being a nice way to compare different Cloud approaches and offerings and see what's really being offered. There's a lot of people jumping on this particular bandwagon, and a lot of the time it's not easy to see what's really going on.

In this blog entry I want to use that model I introduced last week to try and clearly demonstrate the difference between "public" cloud offerings (third party owned and managed, remote installations that you rent capacity from) and "private" cloud offerings (infrastructure that you install and own, but that implements many of the technology platform features found in large "scale-out" server farms run by public cloud providers). I'm not diving into the technology detail here, but rather showing how the value you get from each type of offering is different.



In the diagram I've drawn lines around each of the "cloud value element". Thicker lines mean that more emphasis is placed on that value element; where the value element appears fainter, the value element is de-emphasised or missing.

So, in a nutshell: public cloud offerings typically major on the strategic and economic value elements, and quite often - although the architectural value elements can be there - they're not talked about quite so much. Private cloud offerings, on the other hand, are *all* about the architectural value elements - virtualised resources, management automation, and (in some cases) self-service capacity provisioning.

Another slightly simplistic way to think about private cloud offerings is that they're basically like 21st Century mainframe computers. Built using commodity hardware, yes - but layered with virtualisation, sophisticated SLA-driven management, capacity management, billing/chargeback... this looks awfully like a mainframe (again, from a value perspective, not from a deep technology perspective).

So: public and private cloud offerings: "like chalk and cheese" (as we say here in the UK). That's not to say that one is better than the other: just that they're different, and it pays to understand the kind of value you'll receive from each.

Just like I said in my last post: I don't pretend to have all the answers here, and I'd love to hear your thoughts on this. Please let me know what you think!

Labels: business value, cloud computing, SaaS

posted by Neil Ward-Dutton @ 12:20 PM 0 comments permalink

The seven elements of Cloud computing's value

Last week I was invited to speak as part of the London leg of TIBCO's NOW roadshow, which focused primarily on Cloud computing and TIBCO's new Silver offering (you can see what we think about that specifically in this report).

My job was to talk about "articulating the value of Cloud computing". This was a fun challenge: so much of the talk about Cloud today starts by arm-waving at the 30,000ft level - and then zooms right down to the level of "virtualised compute resources" and "dynamic scalability". What I hadn't seen so much of was an attempt to map out more of a big picture of the value that Cloud computing can potentially deliver in the context of other approaches to consuming IT infrastructure resources.

So after reading countless blogs, conference proceedings, customer stories and news articles, I sat and stared at a blank piece of paper for a while, thinking about how I could pull all the different perspectives together to show one picture that captures all the different ways in which Cloud computing can potentially deliver value. This is what I ended up drawing and presenting in my talk:



You can see that there are seven elements of value I've highlighted, and they fall into three "value types": economic, architectural and strategic.

• The economic value of Cloud is largely about being able to align the timing and size of the investments you make with the value you receive - variously referred to as "pay as you go", "pay as you grow". You don't pay $millions for infrastructure that only delivers value months or years later; you pay for what you actually need, when (or soon after) you use it. And you don't purchase an asset that then depreciates (like crazy).
• The architectural value of Cloud is about having an simple, consistent abstract environment presented to developers and operations folks that hides a lot of complexity, making it much quicker and easier to develop and deploy applications.
• The strategic value of Cloud might be easily conflated with the economic value, but I think it's different. It's this: Cloud platforms help you focus on what makes your organisation more effective and different, and leave all the other stuff to a third party that is dedicated to doing a great job for a competitive price. This is about focus and it's also about avoiding having to train people to do things that fundamentally don't add value to your organisation (think "Lean IT" if you like.)

Have I captured all the potential elements of Cloud computing value? I'm 90% sure I have - but if I've missed something please let me know! Either way, the discussions I've had around this picture so far make me think that it's a useful model for exploring different Cloud propositions as stated today and comparing them. What do you think?

Next up: I'll post another version of this picture that contrasts the value of "private" and "public" Cloud propositions. Both types of propositions have value - but it's important to be clear about what that value actually looks like in each case.

Labels: business value, cloud computing, SaaS, TIBCO

posted by Neil Ward-Dutton @ 10:00 AM 0 comments permalink

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

posted by Neil Ward-Dutton @ 9:53 AM 0 comments permalink

Software Delivery InFocus podcast - Developing in the cloud

This is the third in our Software Delivery InFocus series of podcast episodes, starring Bola Rotibi - the Principal Analyst of MWD's Software Delivery competency area. In this episode, she discusses the opportunities and challenges associated with using cloud-based software development services. Bola's guest is Debbie Ashton, Product Director for CODA - a provider of both on-premise and SaaS-hosted financial management applications.

Although there is a lot of hype surrounding the concept of "cloud computing", there also appears to be real value to be gained in some usage scenarios. The obvious financial benefit of renting software service (being able to remove up-front capital expenditure and instead account for software as an operating expense) is coupled with the scalability that's possible (you can pay as you go, and pay as you grow) and together it looks like cloud-based offerings will be especially attractive in the tougher economic climate that nearly all of us look likely to be experiencing for quite a while. Many organisations today are tempted to think only of the quick advantages of Cloud – partly as a result of the hype coming from the vendor community. However, whilst the potential and advantages are well documented and clear for people to see, the disadvantages or the challenges of use are not. In this podcast we look specifically at the challenges of developing applications for delivery from cloud-based software platforms. What practices if any should organisations take on board in developing applications and solutions using cloud-based development services? What processes and methods should organisations be putting into practice to get the most out of cloud development services?

CODA developed its SaaS-based offering, CODA2go, on Salesforce.com's Force.com platform - and in this podcast episode we hear what Debbie and her team learned about developing in the cloud along the way. Thanks to Debbie for some great insights. You can download the audio here or alternatively you can subscribe to the podcast feed to make sure you catch this and all future podcasts!

As with all the episodes in this podcast series, we've also published a companion report which summarises the discussion and "key takeaways". You can find it here, and it's free to download for all MWD's Guest Pass research subscribers (joining is free).

Labels: coda, development, podcast, SaaS, Salesforce

posted by Neil Ward-Dutton @ 5:08 PM 0 comments permalink

SaaS takes centre stage at Lotusphere

One year on from the launch of IBM Lotus's first home-grown effort in the world of software-as-a-service, codenamed project "Bluehouse", SaaS is again top of the news agenda at Lotusphere 2009, and shows up as an underlying theme across the event's big stories.

The main headline was the launch of LotusLive, a new brand for the company's cloud-based services, which will incorporate Bluehouse, Sametime Unyte Meetings, Sametime Unyte Events and Lotus Notes Hosted Messaging, as well as a all future offerings in this space, one of which I'll come to in a moment. In line with the new branding, each of the above products will be renamed, with the aforementioned products becoming "LotusLive Engage", "LotusLive Meetings", "LotusLive Events" and "LotusLive Notes" respectively.

Alongside this was more detail about last week's announcement of IBM's intent to acquire the assets of Outblaze, a Hong Kong-based provider of white-label, SaaS-based webmail services. Upon completion, IBM plans to offer the Outblaze technology as part of LotusLive, under the name LotusLive iNotes. In addition to adding breadth to the LotusLive portfolio which it is selling direct, IBM sees the Outblaze acquisition as providing a new business model, helping the company to develop the SaaS reseller channel through value-added services.

Other major news from Lotusphere centred on partnering activities at IBM, and again SaaS played a central role - Salesforce.com integration with LotusLive Engage and Lotus Notes, integration between the LinkedIn business social network and contacts within LotusLive Engage, and between LotusLive Engage and Skype for VoIP calls.

IBM is clearly determined to show it has a credible story in SaaS, and is working hard to deliver a portfolio which mirrors its breadth in the on-premise software space. The biggest opportunity for IBM in SaaS - particularly with the Engage offering - is clearly the SMB market, and it will be interesting to see whether it is successful here, or whether LotusLive simply becomes an extension of its established enterprise portfolio. In any case, these announcements demonstrate that it is prepared to square up to Microsoft in the battle for supremacy in the cloud.

Keep your eyes open for a new report on Collaboration-as-a-Service which we'll be publishing within the MWD Collaboration advisory service over the next couple of weeks.

Labels: collaboration, ibm, SaaS

posted by Angela Ashenden @ 2:14 PM 1 comments permalink

More acquisition activity in the identity space

Labels: google, identity, Ping, SaaS, Salesforce, Sxip

posted by Neil Macehiter @ 6:16 AM 0 comments permalink

Time to be honest about SaaS

I thought that those of you who aren't recipients of our monthly newsletter might be interested in this commentary (penned by the other Neil) dissecting some of the problems with the definition (or lack thereof) of software-as-a-service.

Over the past few days we’ve been having an interesting debate here at MWD, in conjunction with the analysts at our close partner Freeform Dynamics. The question came from Dale Vile at Freeform: what's a good definition of software-as-a-service (SaaS)? The reason for asking the question was that SaaS is a hot topic, and it's something that's considered as a major growth opportunity for a lot of technology suppliers; but although there are a fair few forecasts of growth in demand, it's difficult to get a clear idea of what's actually included in these forecasts. Of course, if there isn't a consistent view of what does and doesn't actually constitute SaaS then that's not really helping anyone. The approach we took to try and provide that consistent view was to look at a long list of things (ranging from Google Search, Google Maps and hosted wikis to Skype's VOIP and messaging services, hosted voice PBXs, online travel agency services and remote backup services), and say whether we thought they "counted" as SaaS offerings.

What came to the fore very quickly was that there was no crisp set of attributes that we could agree characterised SaaS offerings. SaaS isn't defined (as some would tell you) by a particular type of distribution or access technology, a particular technology architecture, or a particular approach to charging for usage.

Yes, SaaS offerings do commonly exhibit particular choices in these areas (use of the web for distribution and access; a "multi-tenant" architecture to efficiently separate the data and customisations of each customer from those of others; and some kind of subscription license). But crucially, these choices aren't unique to what most people would call SaaS offerings. Google's services, and countless millions of other online dynamic websites, have made those same technology choices for distribution and access – and they're commonly lumped into that whole other can of slippery worms, "Web 2.0". Countless online portals (some hosted within organisations, others available to the public) allow users to personalise their experiences and use a multi-tenant architecture to store personalisation data efficiently and effectively. Lastly, all sorts of information- or IT-based capabilities are delivered on a subscription basis (not least, mainframe capacity, and analyst research ;-).

So what is it that marks something out as SaaS (or not)? The only answer that seems to tick all the boxes is that SaaS offerings are those which deliver online, hosted alternatives to things that we have historically experienced through the in-house purchase (or development) and deployment of software systems.

Let's take Customer Relationship Management (CRM) as an example. Historically, CRM capabilities were provided by software that was installed on premise, was managed on premise, supported one organisation, and was paid for through a perpetual license. When Salesforce.com delivers those CRM capabilities from a remote installation, manages them on behalf of multiple organisations, and is paid to do so on the basis of a monthly subscription, it needs a different name: that's "Software-as-a-Service". Following that example, remote backup/restore services, online word processing applications like Google Docs, the Zoho suite and (now Adobe's) Buzzword, and SAP's BusinessByDesign (formerly A1S) all count as SaaS offerings. Google Search and Facebook don't, because they're not delivering capabilities that you would ever have associated with on-premise, perpetually licensed software.

This helps us clarify SaaS' place in the IT industry, but we think it's a problematic conclusion, for three reasons. Firstly, most people use the label without really understanding how context-dependent it is (what you think of as SaaS is primarily defined by your own experience); secondly, if we continue down this road, there can never really be a consistent definition of SaaS that will work for everyone; and thirdly, this is a very IT industry- and supplier-centric way of looking at the world that is only likely to alienate or confuse a very important community – "users" (the people who pay all our salaries).

Perhaps we need to call time on SaaS, and think of some clearer terms and definitions that can really help IT organisations and IT buyers work out how everything fits together. At the very least, as an industry we need to be honest about SaaS – and explain that it’s an industry-driven marketing and positioning term that's primarily about separating "funky new stuff" from "boring old stuff".

Labels: Adobe, Facebook, google, SaaS, Salesforce, SAP, Skype, Web 2.0, Zoho

posted by Neil Macehiter @ 3:08 PM 2 comments permalink

Real-world Enterprise Architecture part II: conversation, federation, road trips and tools

In my previous post I explained how in order to get real value out of Enterprise Architecture (EA) work, it's critical to focus not only on the outputs of EA work, but also on the process/practice of EA - and moreover that the process/practice has to focus on *conversations*.

What does this mean for tools, technologies and methodologies which purport to aid architecture work of different flavours? To get to the bottom of this, it's important to add another thought into the mix, which concerns the nature of IT work in large organisations.

What we found in our research for our book is that in large organisations (which are of course the organisations most likely to be pursuing EA activities) IT work is only very rarely truly centralised. Even where there is "officially" one central IT department, the reality is most often that there are other pockets of IT activity that happen elsewhere - perhaps in subsidiaries, remote offices, or within particular business departments. What we also found is that it's pointless trying to centralise IT work and force all IT activity to happen in one place. A top-down, centrally enforced IT mode of production might work for a short while, but soon enough entropy will work its slippery spell and projects will start springing up elsewhere (this is just one reason why the book is called the Technology Garden).

In reality, then, there's little point in planning and executing high-level architecture work in a highly centralised fashion, when IT work is actually federated. At least part of successful and value-adding architecture practice is going to be conducted on corporate road trips, not in bunkers or ivory towers.

So I'm starting to realise that a lot of architecture theory and method is not always very helpful.

At best the focus of the theory and method work can only be one part of a much wider picture, and it needs to be hidden from that main piece of the action - the business-IT conversations. We need new techniques, technologies and new skills to drive the conversations. We need tools and approaches that promote lightweight, collaborative and iterative work - tools and approaches which we can use to share ideas and edge towards agreements as we make those road trips.

There are lots of tools and approaches on the market that help people "do things right" in bunkers or ivory towers. But let's not forget that there's something that's at least as important as "doing things right", and that's "doing the right thing". Figuring out *that* part of the equation is where road trips come in. Where are the tools?

I really hesitate to use the terms "Web 2.0" or "Enterprise 2.0", but what's needed is an approach which builds off the kinds of capabilities you'll be familiar with if you're a student of those two-dot-oh-isms. Hosted platforms with universal remote access; and collaborative editing and sharing of information.

Embarcadero is planning on supporting this kind of scenario in future releases of its EA/Studio modelling tools, and Lombardi is already testing the market, from a process architecture perspective, with Blueprint.

Labels: collaboration, discovery, EA, SaaS, sustainability

posted by Neil Ward-Dutton @ 5:48 PM permalink

Has Microsoft got BPM? Part II

Back at the beginning of March I asked "has Microsoft got BPM?". At that time I hadn't had the opportunity to get a briefing from Microsoft on its recent BPM moves, but now I have.

So - has Microsoft got BPM? Yes and no.

Microsoft is not about to become a fully-fledged BPM solution provider. Rather, Microsoft is attempting to do to BPM what it attempts to do in all the areas of enterprise software it's played in (think DBMSs, development tools, middleware, portals, etc etc) - commoditise the core technology and make it part of an integrated software platform that's digestible by mainstream medium-to-large enterprises. Sun wasn't the first company to realise that "volume drives value" - it's taken a leaf out of Microsoft's book.

So a big part of the focus is on providing the technology foundation for BPM. Here Microsoft has a couple of formidable weapons:

1. Office. Office is the defacto productivity suite in enterprises - and with Office 2007, is becoming the front end infrastructure for BPM scenarios in Microsoft's world, as well as a suite of apps. It's an environment very familiar to business people, so if those people are looking to get a BPM initiative started, Microsoft's proposition could look pretty attractive. [If you don't believe us about Office, see this research from our partner Freeform Dynamics.]


2. Workflow Foundation. This is a core component of .NET 3.0 (the native programming model for Longhorn Server and Vista). It provides embeddable workflow execution services for both highly structured business process automation scenarios and less structured, collaborative scenarios. It's becoming the foundation of both BizTalk Server 2006 (which will drive structured process automation scenarios) and Sharepoint 2007 (which is more suited to unstructured, collaboration-focused processess). Workflow Foundation really is neat.

The big caveat, of course, is that all these weapons only really come into play if and when organisations buy into the current tranche of product releases - Office 2007, BizTalk 2006, Visual Studio "Orcas" and the Visual Studio Tools for Office (VSTO), and .NET 3.0.

Although all these pieces are either released or coming very soon, where customers have a significant investment in Microsoft in these kinds of areas, it's far from certain that they will upgrade or migrate quickly. Microsoft's success in engineering an integrated platform of software infrastructure is also a weakness, in other words - people who buy into it tend to have a lot of capabilities riding on it. That drives caution and risk aversion.

Microsoft's BPM foundation is mainly focused on the development and deployment of processes, and although BizTalk 2006 has some BAM capabilities (through integration with SQLServer OLAP and BI functionality) Microsoft isn't focusing primarily on providing tools for modelling and simulating, analysing or optimising processes. It's developed a coterie of "Business Process Alliance" partners to fill in the gaps, and also to help it accelerate demand for the new versions of its key BPM foundation components. When it comes to Workflow Foundation in particular, the huge Microsoft-focused packaged application vendor (ISV) community which so effectively drove adoption of SQLServer will also be a key element of Microsoft's strategy.

So on paper Microsoft has a good BPM story - if you're prepared to put a lot of skin in Microsoft's game and if you're prepared to upgrade to the latest Microsoft infrastructure. The company isn't yet pushing the base technologies aggressively and directly to customers, but it is priming its partners and channels and these will drive uptake.

Another interesting angle to the technology piece of this story is the recently announced BizTalk Services offering - a set of integration capabilities "in the cloud" which offer a hosted complement to on-premise BizTalk integration implementations. These services are designed to, in theory (it's early days), make the creation of highly federated, distributed service and process networks much more simple to develop and operate. It's a fascinating development that has some parallels with what Salesforce has been doing with the Salesforce Platform Edition, and (a little less so) with what BT is attempting to do with BT Integrate.

One last small thing though. If it's serious about BPM, at some point Microsoft's going to have to sort out the difference between this BPM and this BPM...

Labels: BPM, BT, Microsoft, SaaS, Salesforce, Workflow Foundation

posted by Neil Ward-Dutton @ 9:01 PM 0 comments permalink