Come on vendors, get it together: Office 365, Google, Dropbox, etc

For many of our customers, large and small, their first foray into the beautiful world of cloud computing is driven by a less beautiful compelling event related to one of the following:

  • On-premise email servers (typically Microsoft Exchange) require an upgrade of either software, hardware or both
  • Licensing and upgrades of the Microsoft Office suite, typically as part of some enterprise-wide licensing agreement (or maybe an audit!)

So, if you are approaching a refresh, what should you do?  There’s a myriad of comparisons out there on the web comparing the features and costs of Microsoft Office 365 against Google Apps so I won’t add to that. To cut to the chase, feature-wise they are approaching parity but of course it depends on the specific requirements of your organisation. What I wanted to cover was the usual corporate dilemma, and why Microsoft is currently (and probably for a long time) the right answer.

The logic goes like this.  I really quite like the idea of using Google Apps, it’s a bit easier to administer (in my view – but partially as it’s less rich and maybe doesn’t expose all the cruft of Exchange in the config pages), it’s just feels a bit more hip and happening. Although to be fair, Microsoft have managed to shed their corporate image and loosen up a bit, as demonstrated by this identification challenge that tickled me when you are registering for Office 365…

But, I really only want to have one vendor and configuration to manage – surely I can get everything I need from one vendor in 2016?  It really depends what line of business you are in, but certainly for us as a professional services-based business some customers will expect materials to be sent to them in Microsoft Office formats (Word, Excel, PowerPoint).  Whilst other vendors can work in this format or I could use LibreOffice, I know that the interoperability just isn’t quite good enough. And my finance team are going to rebel if I don’t give them Excel, so… I really need to buy Microsoft Office – and this is when the costing dimension comes in. Pricing starts at £7.80/month/user for up to 300 users for Office 365 with the ability to download all the Office client applications (jumping to a pre-discount £14.70 for the Enterprise E3) – and that immediately makes a Google Apps-based solution unattractive as you basically have to pay for many of the services twice, e.g. email services, Skype or Hangouts etc from both Microsoft and Google.  A masterstroke of lock-in from Microsoft.

OK, so I accept this as a fact of life, and resign myself to going “all in” with Office 365.  Not so fast.  Like many organisations today, I might have a BYOD or CYOD policy and I know that my users have both PCs and Macs. That sounds fine – Office 365 supports Macs.  Yes, the Mac implementations of Word, Excel etc are a bit different (mainly as a result of the weird double menu bar thing – why have one “Insert” menu when you can have two?) but the apps are pretty good these days.

But the issue comes with file sharing and synchronisation on the Mac. Whilst there is a Mac client for syncing your OneDrive so you can work offline etc, it does not sync shared files – and so the only way you can access them is via the web interface – not something that you are going to enjoy on the train on the way home.  This fact is a little buried here – there’s more evidence of Microsoft’s sense of humour with this statement…

So that leaves us with an issue as to how to support collaborative file sharing across our organisation.  This is what Dropbox (in my experience) does best – it just works across clients.  So you end up having to have at least one other vendor product to plug this functionality gap, which is frustrating.  I was talking to a start up the other day – they are not big but they’ve active subscriptions for all three – i.e. Google Apps (as the email search is the best), Office 365 (as they need the client apps) and DropBox (for the file sharing).  I bet this is much more common than it should be.

But, it’s on Microsoft’s Office 365 roadmap so maybe I’ll be able to have just one subscription in 2017.

If you want to read more on comparisons of Google Apps and Office 365 etc – this is a great resource.


Beamap is the cloud consultancy subsidiary of Sopra Steria

Cloud adoption consideration #5: Drive adoption

This is the fifth and final post of a series of blog posts discussing the five main considerations critical to successful cloud adoption by enterprises.  If you missed them, the previous posts are here.

Today’s topic is about how to make sure that all your hard work is appreciated.

Let’s imagine that we’ve got a clear strategy, put the technology fundamentals in place and we’ve refined our operating model to ensure we can scale and industrialise our cloud-service consumption.  We can’t fail, right?  Well – even with all these necessary conditions in place, our experience shows that the consumers of cloud-services in your organisation may still not consume.  There can be many reasons for this – gaps in cloud awareness, bias, internal politics etc.  The solutions lie in good old change management techniques such as communications at multiple levels, education and briefing sessions, stakeholder management and capture and publication of good metrics to show what is really going on.

The key point is that you cannot assume that you can “build it and they will come” – adoption is not a given and the barriers to adoption of cloud services can be subtle and often invisible, so a metrics capture regime and publication is required to surface them.

Recommendation

Our recommendation is to consider these mechanisms to drive adoption as part of the initial cloud programme structure and scope, but also “bake in” as an inherent part of the operating model revisions that we’ve discussed previously.

One technique to drive early adoption is to find and nurture evangelists with candidate “early adopter” projects and this is an approach we see very often.  The trick is making the leap from this initial activity to broader mass adoption in your enterprise that is self-sustaining – i.e., doesn’t need outside influence from the cloud programme to keep the flywheel going.

Wrapping up

In this series of blog posts we’ve outlined five of the top factors that we feel are critical to successfully realising the oft-quoted promises of cloud computing for large enterprises.  There are technology challenges for sure, not least of which is a whole bunch of new skills required in a discipline that is rapidly changing all the time, but fundamentally this is an exercise in change management and we believe in these fundamental building blocks as the basis for a comprehensive strategy.

Of course, there are more than five things to get right – and infinite ways to fail – but that’s what makes it interesting!  Thankfully, our experience is that we are past the phase of disputing the benefits of cloud computing – now the opportunities are clear and it’s all about good execution.  We’d love to help you with your journey!


If you want to read more about this and the other four considerations for successful enterprise cloud adoption, have a look at our white paper.

What are your thoughts about successful cloud adoption by large enterprises? Leave a reply below, or contact me by email.


Beamap is the cloud consultancy subsidiary of Sopra Steria

Cloud adoption consideration #4: Leverage the benefits in your application teams

This is the fourth of a series of blog posts discussing the five main considerations critical to successful cloud adoption by enterprises.  If you missed them, the previous posts are here.

Today’s topic is about moving past the initial technology implementation phase to really realise the maximum enterprise benefit from cloud adoption.

At Beamap[1] we live and breathe cloud computing all day every day, but it’s important to not lose sight of the fact that really it is not an end in itself, it is just an enabler.  It’s all about the applications.  An issue that we see in enterprises is that they have access to more agile cloud services, but the workloads that they run on them are still architected and developed in much the same way.  So cloud has been “adopted”, but the biggest benefits come from fully leveraging the hard-fought benefits throughout the application lifecycle.

Vendor application issues

This is one of the real blockers on accessing the full benefits.  The harsh reality is that most commercial applications out there are still not really architected to fully exploit cloud services.  Application vendors have all the same problems that enterprises do in tracking the cloud market, and so support for features such as auto-scaling is often lacking (even worse, the vendor is likely to have “cloud-washed” their app in a marketing sense, so it’s hard to tell where the shortcomings are).  Hence there is a long long tail of application rework required by vendors and in the meantime cloud is used simply as a hosting platform for these applications, which makes the business case against traditional hosting models much harder to make.

Internally developed application issues

For internally developed applications, the same issues are playing out, but require changes to the architecture, development and operations processes – and this takes time.  Organisations need different skills and tools to implement and really get the benefits from continuous integration, continuous delivery and blue-green deployment practices, containerisation, serverless computing etc.  And then there are the real game changing higher-level PaaS services to be exploited, or the use of commodity IaaS services to deliver a scale of operation at a cost point that was unimaginable just a few years ago – for machine learning, big data processing, artificial intelligence and IoT.  In addition, like everything else in the world of cloud computing, this is not a static challenge, so in your applications teams there’s an ongoing need for training around opportunities, best practices and standards development related to the ever-improving cloud services.

…and what to do about it

There is a phasing and investment profile issue here that needs to be considered in the cloud business case work – whilst the target is to have a set of beautiful cloud-native applications, the creation (or conversion) of these applications takes longer than it does to stand up private cloud services, and certainly way longer than it does to access public cloud services.  The size of internal cloud platforms and the operating model to support all cloud services only need to scale a touch faster than the application demand that is able to consume these services.  When the application development capabilities don’t keep up with the cloud services that they can consume, that’s when you have a problem and are missing a trick.


If you want to read more about this and the other four considerations for successful enterprise cloud adoption, have a look at our white paper.

What are your thoughts about successful cloud adoption by large enterprises? Leave a reply below, or contact me by email.


[1] – Beamap is the cloud consultancy subsidiary of Sopra Steria

Cloud adoption consideration #3: Avoid overly technology-led approaches

This is the third of a series of blog posts discussing the five main considerations critical to successful cloud adoption by enterprises.  If you missed them, the previous posts are here.

Today’s topic is about a common anti-pattern that we see – when organisations see cloud adoption as primarily a technology problem to solve.

Working on cloud has become great CV fodder in the last few years, and so everyone wants to work on the new cloud implementation project and get exposure to the new technology.  Obviously enterprises want to harness this energy, but there is a trap, and it comes back to the need for a cloud adoption strategy and an underpinning business case – i.e. why are you doing it.  Is it to become the world’s leading authority on cloud computing?  Should your organisation be focusing its energies on its core business operations, markets and customers, or pushing the envelope with ground-breaking cloud implementations?

Technologists (and I’m counting myself as one here) love this stuff – introducing complexity, sometimes at the cost of the original business goals.  So consider the following questions…

How many cloud providers do you really need?

A common emerging enterprise adoption pattern is to manage multiple cloud providers via a brokerage solution that gives a single point of control across them.  It’s a valid strategy, but do you really need this?  Is it to reduce the risk of lock-in?  For vendor negotiation leverage?  The risk here is that a great deal of complexity (a barrier to the very agility you are trying to achieve) is introduced, leading to a “lowest common denominator” set of cloud services and a maintenance nightmare as you engage in a never-ending and never-winning chase of the cloud vendors’ latest feature releases.

Do you really need internal/private and public cloud offerings?

In the enterprise market, we could perhaps characterise the last few years as being very focused on private cloud, as the traditional hardware and software vendors desperately tried to defend market share from the public cloud usurpers.  Now the tide is turning more in favour of the public cloud providers, but there is a massive inertia in large enterprises towards on-premise initiatives hence, for example, Microsoft’s focus on positioning for hybrid cloud with Azure Pack and Azure Stack.  This is understandable – there’s typically a huge data centre investment, and an operating model that has been painfully refined over the years to feed and water that investment.

So ask yourself these questions:

  • Are you reinventing something that already exists from the public providers?
  • Are you pursuing an evolutionary step that you can avoid?

Are you really that unusual?

A common statement we hear is “ah, but we are unique/different” – but we would argue that this is rarely the case.  It can certainly be true in the SaaS adoption case, but is much less likely to be the case for IaaS services.  If this argument is used to justify custom development for cloud services, be suspicious.  It’s unlikely that AWS and their kind have not solved all these challenges already, and if they haven’t, ask yourself why they haven’t…it’s likely because it’s not a genuine need.


If you want to read more about this and the other four considerations for successful enterprise cloud adoption, have a look at our white paper.

What are your thoughts about successful cloud adoption by large enterprises? Leave a reply below, or contact me by email.


Beamap is the cloud consultancy subsidiary of Sopra Steria

Cloud adoption consideration #2: Define and implement the revised operating model

This is the second of a series of blog posts discussing the five main considerations critical to successful cloud adoption by enterprises (if you missed it, the first post is here).  Today’s topic is the impact of cloud adoption on your operating model.

A common customer scenario goes like this.  We want to get the benefits of cloud computing.  But our organisation is so…slow…to…change and we have so much legacy to deal with.  So let’s set up a skunkworks team for application X that is coming up on the development roadmap, so that we can develop a small initial capability to design, deploy and operate a cloud-based solution.  So far, so sensible.

But then the advantages that this initial team had start to become disadvantages. They can’t scale. They don’t really have the organisational sponsorship as they’ve deliberately operated in a silo so they could move quickly, avoiding all those pesky organisational constraints. This is the old bimodal IT dilemma which has had far too many column inches written about it already (here is a good place to start on this topic), so I won’t add to them here.

Bite the bullet

At some point, the enterprise has to bite the bullet, define and then implement a revised operating model for the design, deployment, operating and retirement of cloud services at scale.  It needs to become the default model for the scenarios defined in the strategy that we did such a great job of earlier, not the exception.  Regardless of the technology selection, the operating model within the IT function needs to change, and in some respects this needs to be defined before the implementation phase.  This is a non-trivial undertaking and requires serious management commitment.

Most non-cloud-native, large enterprises have not got to this stage yet, regardless of what case studies are available in the trade press…digital flagship projects get all the coverage but the reality is that the vast majority of enterprise workloads are still in the data centre as we are just a few years into a very long journey, and so the evolution of operational models is tracking this trend.

So what does a cloud-ready operating model look like?

Well, it considers cloud adoption in multiple dimensions:

  • design, build and run…
  • …using the full range of cloud services – SaaS through to IaaS…
  • …considering the people, process and technology implications

Some of the aspects of the operating model can be radically new for an organisation, e.g. DevOps processes, multi-skilled teams.  And some can be refinements to existing processes to better support an environment that has greater and greater dependence over time on cloud-based services.  For example, vendor management needs to change to cope with the differing innovation pace, commercial models, legal implications and billing models of cloud providers.

The risk here is that your technologists do a fantastic job providing your staff with access to the underlying internal or external cloud services, but a pre-cloud-era operating model destroys the benefits by constraining the achieved agility and innovation.  In addition, the new operating model needs to be much more responsive to change itself, so there is a “one-off” redesign required here, but also an ongoing process of adaptation to respond to the still rapidly changing cloud landscape.  It’s still relatively early days…


If you want to read more about this and the other four considerations for successful enterprise cloud adoption, have a look at our white paper.

What are your thoughts about successful cloud adoption by large enterprises? Leave a reply below, or contact me by email.


Beamap is the cloud consultancy subsidiary of Sopra Steria

Cloud adoption consideration #1: Have a strategy

This is the first of a series of blog posts discussing the five main considerations critical to successful cloud adoption by enterprises.

Before diving into the first, let’s define the scope of what I’m talking about here, as it affects the points that need to be made.

  • We are talking about cloud adoption by large enterprises – typically global organisations who have the advantage of scale and for whom private cloud implementations are within their reach, but who also have the disadvantages of scale – the challenge of organising a large number of people to deliver complex capabilities. The critical considerations are different for start-ups where public cloud is typically the only realistic option.
  • At this scale, customer strategies tend to encompass private and public cloud components, and sometimes multiple providers for each – so our scope here includes SaaS, IaaS, the fuzzy bit in the middle that we’ll call PaaS, plus on- and off-premise implementations.
  • We are interested in the long game – of course you need quick wins to earn credibility and get the flywheel effect going, but the big gains are to be realised over several years (at least).

Firstly, technology is not one of the five critical considerations

This might seem counter-intuitive, but let me explain. Our clients have the scale to get the technology right. Typically, they have talented staff and/or strong delivery partnership organisations in place, and they are big enough to attract a lot of love from the big cloud vendors. Also, these types of organisations have already implemented and operated multiple data centres over the years, so they know how to deliver big technology change programmes.  So whilst getting the technology aspects right is absolutely fundamental, it’s not where we see customers having trouble. In fact, it’s a risk, as customers can focus too much on where they are comfortable. Five years ago, perhaps, this was the hard part, but whilst it’s still far from trivial, it’s not where organisations flounder. We do see customers with cloud initiatives that fail for technology reasons (e.g. sub-standard security patterns and governance) but typically, the root cause of these failures is not technical ignorance and can be traced back to one of our five main discussion points.

The key point is – and it’s taken me a while to figure this out myself – that successful exploitation of cloud is not just a technology challenge, but predominantly a change management challenge. So this takes us to the first consideration critical to successful cloud adoption by enterprises…

#1 – Know why you are doing it

This sounds obvious – but it’s amazing how many organisations do not have a clear set of business drivers that can be traced through to the cloud part of their strategy. (Just to clarify – we tend to talk about cloud strategy as a shorthand, but really we mean “business strategy in a cloud world” – i.e. those components of the business and IT strategy that can leverage the developments in cloud computing from the last 5-10 years)

Actually the problem is more subtle than this – often what we find with a new client is that there is a cloud strategy defined in some form, but it might have one or both of the following flaws:

It is non-specific, and therefore tries to be all things to all stakeholders

We want to be more agile? Tick.  And reduce costs? Tick.  And more secure? Tick.  And rein in and provide a credible alternative for shadow IT? Tick.

The cloud vendors (and I have contributed to this) are guilty of feeding the “cloud good, non-cloud bad” mentality, but of course it’s more complex than this. Some of these objectives compete with each other – sure the overall effect on the organisation of cloud exploitation can to achieve them all, but any strategy that can really be executed needs to be less generic than this. For example – are you chasing infrastructure cost savings, or application development savings, or operations staff savings? Is it an IT benefit you seek, or a benefit that will be visible to internal business customers? The answers will probably be different for different parts of your application estate also.

One cause of a vague or non-existent strategy is a “follow the leader” behaviour from senior management – i.e., my peers/competitors are adopting and my shareholders/investors read the same press I do, so I have to do it also. Five years ago I spent what felt like too much energy evangelising cloud adoption in a large enterprise (with limited effect!), and now it’s taken as a given that it’s part of the CIO’s mission. That’s progress. Just be sure why you are doing it and be brave enough to say no if…

It is not underpinned by a business case

Assuming the previous flaw has been addressed (it’s a pre-requisite really that the strategy is specific enough), then do a good old-fashioned cost-benefit analysis on what you are proposing to execute. I am not arguing that cloud adoption in a large enterprise does not lead a visionary leader to show the way by articulating a compelling vision – it absolutely does. But do your homework. Our motto in Beamap[1] is “If the business case for an application migration to cloud does not stack up, do not do it”.  We’ve no bias towards migrating everything regardless of benefits case – we’re not selling hardware or software or cloud services.

Of course, there are many sound strategic rationales for proceeding without a positive “hard numbers” business case, such as risk mitigation, future agility, data centre space constraints or contract terminations, etc, – and putting a financial value on these softer benefits is difficult.  But at least make it a conscious and evaluated decision – otherwise how are you going to go back later and measure the benefits realisation and adjust your approach from what this teaches you?

If you want to read more about this and the further four considerations for successful enterprise cloud adoption, have a look at our white paper.

What are your thoughts about successful cloud adoption by large enterprises? Leave a reply below, or contact me by email.

———————————

[1] – Beamap is the cloud consultancy subsidiary of Sopra Steria

What do recent AWS announcements tell us about the cloud market?

As always, Amazon Web Services (AWS) made a bunch of announcements at their recent Chicago Summit.  The new features have been reported to death elsewhere so I won’t repeat that, but there were a few observations that struck me about them…

Firstly, the two new EBS storage volume types aimed at high throughout rather than IOPS – are 50% and 25% of the normal SSD EBS price, so are effectively a price cut for big data users.  As I’ve commented before, the age of big headline grabbing “across the board” cloud price reductions is largely over – and now the price reductions tend to come in the form of better price/performance characteristics.  In fact, this seems to be one of Google’s main competitive attacks on AWS.

Of course, I welcome the extra flexibility – it’s always comforting to have more tools in the toolbox.  And to be fair, there is a nice table in the AWS blog post that gives good guidance on when to use each option.  Other cloud vendors are introducing design complexity for well-meaning reasons also, e.g. see Google’s custom machine types.

What strikes me about this is that the job of architecting a public cloud solution is getting more and more complex and requires deeper knowledge and skills, i.e. the opposite of the promise of PaaS.  You need a deeper and deeper understanding of the IOPS and throughout needs of your workload, and its memory and CPU requirements.  In a magic PaaS world you’d just leave all this infrastructure design nonsense to the “platform” to make an optimised decision on.  Maybe a logical extension of AWS’s direction of travel here is to potentially offer an auto-tiered EBS storage model, where the throughput and IOPS characteristics of the EBS volume type is dynamically modified based upon workload behaviour patterns (similar to something that on-premise storage systems have been doing for a long time).  And auto-tiered CPU/memory allocation would also be possible (with the right governance).  This would take away some more of theundifferentiated heavy lifting that AWS try and avoid for their customers.

So…related to that point about PaaS – another recent announcement was that Elastic Beanstalk now supports automatic weekly updates for minor patches/updates to the stack that it auto-deploys for you, e.g. for patches on the web server etc.  It then runs confidence tests that you define before swapping over traffic from the old to the new deployment.  This is probably good enough for most new apps, and moves the patching burden to AWS, away from the operations team.  This is potentially very significant I think –  and it’s in that fuzzy area where IaaS stops and PaaS starts.  I must confess to having not used Elastic Beanstalk much in the past, sticking to the mantra that I “need more control” etc and so going straight to CloudFormation.  I see customers doing the same thing.  As more and more apps are designed with cloud deployment in mind and use cloud-friendly software stacks, I can’t see any good reason why this dull but important patching work cannot be delegated to the cloud service provider, and for a significant operations cost saving.  Going forward, where SaaS is not an appropriate option, this should be a key design and procurement criteria in enterprise software deployments.

Finally, the last announcement that caught my eye was the AWS Application Discovery service – another small tack in the coffin of SI business models based on making some of their money from large scale application estate assessments.  It’s not live yet and I’m not clear on the pricing (maybe only available via AWS and their partners), and probably it’ll not be mature enough to use when it is first released.  It will also have some barriers to use, not least that it requires an on-premise install and so will need to be approved by a customer’s operations and security teams – but it’s a sign of the times and the way it’s going.  Obviously AWS want customers to go “all in” and migrate everything including the kitchen sink and then shut down the data centre, but the reality from our work with large global enterprise customers is that the business case for application migrations rarely stacks up unless there is some other compelling event (e.g. such as a data centre contract expiring).  However, along with the database migration service etc, they are steadily removing the hurdles to migrations, making those business cases that are marginal just that little bit more appealing…

What are your thoughts? Leave a reply below, or contact me by email.