Cloud Journey Part 4: The Gap Analysis – EMC CR9 and Cisco Domain 10

Aside some of the more impartial discussion with Gartner, we took a couple of free consultancy offerings from EMC and Cisco which were targeted at creating a baseline of where we were in terms of Cloud maturity from a technical, organisational and security perspective, to map our requirements and drive out our desired end state and then create a gap analysis between these two positions to determine which areas we need to develop and invest in.  Please note the examples below are not specific to the organisation I worked for, but taken from the ‘acme’ company example documents provided by the vendor as examples of what to expects.

EMC CR9

The EMC Cloud Readiness 9 measures against the following:

1. Cloud Organizational Transformation
2. Cloud Infrastructure (Compute, Network, Storage)
3. Data Protection in the Cloud
4. Multi-Site Cloud Technologies
5. Automation/Orchestration for Cloud environments
6. Trust/Compliance in the Cloud
7. Cloud Services/Chargeback
8. Cloud Ready Applications
9. End User Computing.

We measured once for baseline and again for aspirational against a maturity matrix like the one below which is focussed on Infrastructure specifically.

gap1

An example of a completed CRA9 results in a chart like the one below.

gap2

Ultimately this is then turned into a roadmap with five areas to focus on initially.

gap3

The report that is generated also covers more detail in terms of why the scores have been arrived at and more detail again in terms of next steps.

General feedback was that the format of the workshop wasn’t the best. We had a lot of people in the room representing different IT and business areas, however in hindsight it could have been a much smaller group. I think a lot of people felt like they needn’t have been there as only one person was really contributing at any point in time and it could have worked better as a series of interviews. This is probably a lesson learned on our side as I’m sure EMC would have facilitated either model.

The output was very good and one area where EMC are very good is the none technical things like organisational change (i.e. Transformation). The report reiterated that we need to move to a more standardised reference architecture to move our focus away from integration tasks to concentrate on exploiting the infrastructure capabilities. It also demonstrated that we needed a basic Service Catalogue of items that could be requested by end users and then the adoption of Automation and Orchestration to deliver those services dynamically. Not rocket science when deploying cloud services, but it was a useful exercise to start talking about this with a wider audience, put the work into context and highlight why we were tackling certain things first i.e. automation / orchestration.

Cisco Domain 10
Cisco domain 10 was the second workshop we undertook and again this was a group effort to measure a baseline and a target state. The 10 domains are:

gap4

Similar to the EMC model, however the feedback was that this model was easier to understand and that it demonstrated that a Cloud platform is built in layers. This session also seemed to help those struggling with the concept of Cloud as they seemed to have everything fall into place and it was pleasing to see some light bulb moments in the room.

This session was a also a little more collaborative than the EMC session as everyone was made to grade our current state and identify target. An example of the scoring scheme can be seen below:

gap5

The result was a grading and identifying initial areas to concentrate on.

gap6

Feedback on this session was almost uniformly positive and it further highlighted key areas to concentrate on.

What did we do with the information?
It is worth adding that each of the session started with a requirements gathering phase so at the end of the two engagements we had a list of requirements gathered from a wide variety of business stakeholders, a good baseline of where we were maturity wise and a good idea of where we collectively thought we need to be in order to address the requirements.

We were able to draft a strategy document, referred internally as a ‘statement of direction’ for Cloud adoption.

In brief it essentially covered the adoption of a Private Cloud platform delivering IaaS and targeted PaaS as a phased project, with the intention of scaling out to a Hybrid Cloud using whichever Cloud Management Platform we ended up adopting. This would support our Development and Operational areas by introducing much needed agility and standardisation into our processes. The long term ambition was to build out a comprehensive service catalogue of items and move to an IT as a Service or X as a Service model, with service cost understood and demonstrated to consumers of the service. The ability to support any potential move to a DevOps style culture was also highlighted as a stated ambition.

Once we had this strategy approved we logged a formal project to deliver a Cloud Delivery / Management platform and started talking to vendors.

Share this post:
Facebooktwitterredditpinterestlinkedin

Leave a Reply

Your email address will not be published.