Archive for the ‘ITSM’ Category

From system integrator to service integrator

Tuesday, February 23rd, 2010

One of the themes we delve into in our free online framing a Cloud Computing strategy event is the emerging role of the Service Integrator. This is something I’ve been talking about for a while in discussions with clients but I thought I’d share it a bit more widely…

So what is a Service Integrator? Simply put, a Service Integrator relates to the SaaS/Cloud Computing world in the same way that a Systems Integrator relates to the on-premise computing world.

Right now we’re at a stage in Cloud computing development which is dominated by “early adopters”. Typically such companies are willing to go an extra mile to get the benefits of a new technology and technology model – things that many other companies would consider too complicated, risky or expensive.

Activities which fit into this category include integrating data and functionality (both between Cloud-based platforms and applications, and between Cloud-based and on-premise systems); encrypting sensitive data and securing communications; backing up and restoring data; replicating and managing resources to maximise reliability and availability; and so on and so on.

While today’s adopters of Cloud Computing may be quite happy to shoulder the technical burden of making remote resources “fit for purpose” within their enterprise, we should assume that most won’t. Particularly when you consider that a big part of the promise of Cloud Computing is that with this model, you’re delegating responsibility for managing technology. Why, if you’re so interested in a model of computing which is fundamentally tied to outsourcing – and particularly if you’re interested about using this model not just for one application but for a wide variety of purposes – would you choose to take responsibility for integration yourself?

If use of Cloud Computing is to move beyond tactical use in the early adopter community, there’s going to be a big opportunity out there for providers who can wrap multiple Cloud-based services and platforms up and deliver them as bundles of managed services.

So… duh… isn’t this the same thing as systems integration then? Well, maybe a little – but not completely. There are three distinct levels that a Service Integrator can work and add value at, which further blur the boundaries between “traditional” systems integration work and outsourcing/managed services provision work:

  • Technical integration. This is primarily “traditional” systems integration project work – delivering code to create and stitch custom and off-the-shelf application services together.
  • Management integration. This is managed services work that is focused on delivering seamless experiences to service consumers, to agreed levels of quality. Reliability, security, availability, break/fix, helpdesk services and disaster recovery all play here.
  • Contract integration. This level of integration work is about providing “one throat to choke”. The Service Integrator takes responsibility for all back-end contracts with resource and application service providers, and becomes the single integrated billing and payment point for the end customer, also creating a single point of liability for quality of service delivered.

Now of course many established Systems Integrators already combine work of different kinds (for example development/integration and application management) to create overall offerings for clients – but here, we see increased industrialisation of some the services provided (particularly as infrastructure providers like Informatica, Pervasive, and Cast Iron get in on the SaaS act at the technical integration layer), and also more focus on the economic benefits of the Cloud Computing model (rather than on “all-in” pricing for multi-year contracts). We’re already seeing a number of service providers stepping into this space, as well as new players springing up. Examples include (though there are many more):

Capgemini – which has created a specialised Cloud Computing centre of excellence and is providing advisory and integration services for its clients.

Accenture – which has created a set of services to help clients examine potential around Cloud Computing and SaaS.

CSC – which has launched two specific new offerings: Cloud Orchestration (principally operating in our technical integration layer) and Trusted Cloud (operating in our management integration layer).

Saaspoint – a specialist Cloud Computing/SaaS consultancy centred on delivering services based around Salesforce.com application service implementation, citing over 700 clients.

Bluewolf – which focuses on integrate a variety of services (often centred around Salesforce.com’s applications) for customers interested in driving change in marketing, sales and services processes.

For me, one of the most interesting things here will be to what degree the flexible pricing and billing models that have become expected in the Cloud Computing space are offered on to customers when these intermediaries become better established in this market. Will service integrators find ways to make margin out of Cloud Computing providers’ pricing and billing arrangements (for example by pooling a set of back-end application service licenses across multiple clients, and “soaking up” some of the variable demand for capacity that way) but not passing these efficiencies onto clients, instead preferring to drive clients towards fixed-price multi-year contracts? Or will they start to adopt more granular pricing and billing practices? Indeed, will this become an area of differentiation between the established SIs and the upstarts?

I’d love to hear what you think… this is a topic we’ll be digging into more over the course of this year.

If you’d like to check out our Cloud Computing event, it’s available free and on-demand… just go here. You’ll need a free Guest Pass ID to access the content, but signing up only takes a few seconds and you also get access to an extensive library of written research.

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.

Turning IT inside out and the trouble with ITSM and BSM

Monday, June 4th, 2007

The other day Martin Atherton over at our partner Freeform Dynamics got me thinking again about the IT service management (ITSM) / application management / business service management (BSM) hoopla we’ve long been saddled with in the IT industry.

I can absolutely see why vendors would want to try and avoid being seen as “just” providers of ITSM tools and make themselves look more “businessy”. It’s another example of the stack race phenomenon you see in so many areas – development tools, middleware, etc – and the simple idea is that if you can make your offering look and sound as if it can help customers talk more effectively to businesspeople, it’s better than an offering that is a bit oily under the fingernails.

And I absolutely believe there’s a place for tools that can help customers explain the value of IT investments in a way that makes sense to the people who pay the bills.

The problem is that the vast majority of the technology and practice out there does nothing of the sort – at least not without the expenditure of a lot of blood, sweat and tears. To characterise the ITSM/app management/BSM “stack” probably crassly unfairly, all that happens as you move higher up the stack is that events and alerts are correlated at ever more abstract levels. Events from routers, servers and switches are aggregated to give higher-level views of health and performance of infrastructure; infrastructure events are correlated with stats from DBMS instances, application servers, web servers and more to give higher-level views of health and performance of “applications”; and information at the application level can sometimes be aggregated further.

But fundamentally all we’re doing is reporting on more chunky technology outcomes. The outcomes we’re reporting on are still technology outcomes. The insight is about performance, uptime, security, and so on. There is no business context.

I could argue that we do have technology that can help provide business context to ITSM, app management and BSM – business activity monitoring (BAM). But to focus first on technology is missing the point.

The real underlying point is that do really manage services that make sense in a business context, the whole mindset of the IT organisation has to be turned inside out. IT organisations have to stop focusing so much on internal perspectives of process improvement and efficiency (are we doing things right?), and start focusing a bit more on a more external perspective (are we doing the right things?)

To pursue this idea of “inside out IT” into the software development realm, let’s not forget – as I said to an audience of CIOs last night: you can be at CMMi level x and still not guarantee that the things you do will drive business value; instead you *can* turn out irrelevant systems, but in a very predictable way.

Microsoft server and tools is now part of the business division

Friday, May 18th, 2007
The ever-vigilant Redmond watcher Mary Jo Foley over at ZDNet reports that Microsoft’s Server and Tools unit (but not the P&L – Microsoft will still report server and tools financials), which is responsible for Microsoft Windows Server, SQL Server, Visual Studio, System Center management products and Forefront security products, is now part of the Business Division, the home of Office and Dynamics.

Mary Jo finds this move ‘curious’ but I can see the logic. It’s hinted at (if you get past the marketing speak) in the company’s official statement that it made the move to:

sharpen leadership focus on the company’s top priorities and align its organization for innovation, ultimately enabling it to deliver even more value to its customers.

I think this is all about making it easier for Microsoft to articulate propositions which resonate with the key concerns of senior business and IT people. The reality is that key strategic business and IT initiatives – SOA, BPM, compliance … – increasingly depend on multiple technologies and associated competencies, which cross traditional stovepipes. Big SOA, for example, is about managing IT work across the entire service lifecycle and so touches project and portfolio management, software development and integration, IT service management. BPM, as the other Neil pointed out, is about Office as much as it is BizTalk and Workflow Foundation.

In the past, the way that Microsoft has been organised has worked against the articulation of such joined-up propositions (that’s in part why it took the company so long to talk about SOA). Customers would get different answers to the same cross-cutting requirement depending on which Microsoft stovepipe they were talking to: you need BizTalk and SQL Server; you need OBA and SharePoint. [As an aside, I said much of this in an interview with Microsoft PR earlier in the week].

Obviously, shifting branches of the org chart is comparatively easy (even it is very big). The hard part is going to be changing behaviour, joining up the marketing etc. The creation of the Connected Systems Division back in 2005 shows that the company can pull this sort of thing off (albeit on a smaller scale in the Server and Tools Business as was) and Jeff Raikes, who now owns the combined entity, has the influence and power to drive things through at this larger scale.

I am off to a Server and Tools Business analyst event in just over a week so I will hopefully learn more then.

MMS 2007: Microsoft begins to deliver on DSI; provides some IT-business alignment pointers

Monday, April 2nd, 2007

I spent the beginning of last week in San Diego at the Microsoft Management Summit (MMS), the company’s annual conference focused on all things systems management. With time to kill on the 15-hour return journey, I began to draft my thoughts only for this post from Coté over at RedMonk to pop into my feed reader. As well as providing excellent summaries of IT management, Microsoft’s Dynamic Systems Initiative (DSI) and the company’s System Center product family, Coté provides his impressions of MMS and Microsoft’s approach to systems management. Since my impressions were much the same:

  • Significant focus on delivery with System Center Operations Manager, Configuration Manager and Essentials, Virtual Machine Manager and Service Manager (although the latter is still a year away)
  • Emphasis on modeling – Service Modeling Language, Common Modeling Language (adding the management semantics to SML), CMDB, Management Packs
  • Raising the ITIL flag – Microsoft Operations Framework (which Microsoft has until recently failed to exploit despite a long-standing ITIL foundation); System Center Service Manager and CMDB
  • Plugging some notable gaps – OEM relationship with EMC for network-aware management but support for a heterogeneous environment requires more work.

I won’t repeat them in detail here.

Instead, I thought I would call out something which I felt was largely absent from the two days of briefings and meetings with the Windows Enterprise Management Division team: how they help organisations align what they do from a systems management perspective with business objectives and priorities. Ultimately, as Microsoft claims, that’s what DSI is really all about:

A dynamic system is Microsoft’s vision for what an agile business looks like—where IT works closely with business in order to meet the demands of a rapidly changing and adaptable environment. The Dynamic Systems Initiative (DSI) is Microsoft’s technology strategy for products and solutions that help businesses enhance the dynamic capability of its people, process, and IT infrastructure using technology

Microsoft has done a pretty good job with its Infrastructure Optimization (IO) Model of outlining a roadmap to dynamic systems nirvana, as well as assessment tools to help organisations understand where they are on that path. The company has also gathered a significant amount of data from its customers which should help IT organisations to justify IO investment to the business.

However, the company hasn’t really explained how it can help them to maintain the dialogue with the business once the investment has been secured – understanding and capturing business expectations; providing business-meaningful monitoring and metrics; correlating IT security management (as an aside, Microsoft needs to tighten the linkage between its System Center and security – Forefront, Identity Lifecyle Manager – offerings) with business risk management etc. Microsoft needs to address this, not least because all of its enterprise systems management competitors are claiming such capabilities, be it Business Service Management from BMC, Business Service Optimization from CA, Business Technology Optimization from HP, Service Management from IBM.

There were signs, admittedly subtle ones that were obscured by the focus on new System Center products, in Bob Muglia’s Tuesday morning keynote that Microsoft recognises this need:

  • Plans to extend Design For Operations to a ‘business analyst’ audience
  • The use of SML (presumably in BizTalk) for business process and key performance indicator modeling
  • 2007 Office System (Project Server for portfolio management?) as a component of Microsoft’s management offerings
  • DSI is “ERP for IT”

Fortunately the timings of my meetings meant that I had a chance to quiz Kirill Tatarinov, Corporate Vice President, Windows Enterprise Management Division, about these small but important aspects of the keynote. He confirmed my interpretations of Muglia’s comments in light of aligning IT operations with the business. He wasn’t able to go into too much detail but I fully expect to see Microsoft begin to talk about these aspects of its management strategy in the not too distant future.

With Microsoft now four years into its ten-year management initiative it’s good to see it delivering the first generation of DSI-era management tools. It’s equally encouraging to see that the company recognises that it’s not just an IT proposition. The company certainly has many of the assets required to help IT engage with a business audience but Microsoft is already coming from behind when it comes to IT management. There may be another six years of DSI but that’s a LONG time in the IT industry, so it has to act quickly if its not to be forever trying to catch up with its competitors.