{"id":13773,"date":"2018-11-15T13:13:17","date_gmt":"2018-11-15T13:13:17","guid":{"rendered":"https:\/\/www.microsoft.com\/en-gb\/industry\/blog\/?p=13773"},"modified":"2022-08-24T12:46:08","modified_gmt":"2022-08-24T11:46:08","slug":"developing-a-cloud-capability-model","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-gb\/industry\/blog\/technetuk\/2018\/11\/15\/developing-a-cloud-capability-model\/","title":{"rendered":"Developing a Cloud Capability Model"},"content":{"rendered":"

\"The<\/p>\n

By Stephen Armory, Cloud Solution Architect at Microsoft<\/p>\n

Executive Overview<\/h2>\n

\"A<\/p>\n

The process of Cloud Adoption can be a daunting one, requiring both high-level strategic thinking and detailed, execution level understanding. Over the last few years there has been an explosion of offerings in the cloud arena, everything from Cognitive Services providing AI and Computer Vision through to the lowly Web Application Firewall. This leads us to the problem of how to develop a cloud strategy that is both meaningful to non-technical stake holders, but also useful to those tasked with its implementation.<\/p>\n

We often see that big ideas can easily become detached from reality while an overly delivery focused agenda can be myopic in its scope. We can spend our time producing beautiful slide decks, detailed project plans and delightfully complex business process diagrams, but the problem with these approaches is that you still end up with a high risk of \u201cFailure to Implement\u201d. Their weakness, when used to drive a Cloud Transformation, is that they are typically very poor at delivering the following key requirements:<\/p>\n

1: Easy to understand.
\n2: Able to encompass a strategic vision.
\n3: Technically meaningful.
\n4: Able to explain the implementation process.
\n5: Drive consistency of approach where appropriate.
\n6: Describe the skills required to develop and manage the platform.
\n7: Able to remain relevant and up to date.<\/p>\n

Once technical and business requirements have been considered and worked through, how do we then communicate this within the organisation in a meaningful way? Several clients we have worked with have benefited from the following approach to \u201cCloud Capability Modelling\u201d, in one instance still benefiting from and enhancing the original vision 4 years into their Cloud Transformation programme.<\/p>\n

Introduction<\/h2>\n

The purpose of this document is to introduce an approach that I have been using with clients over the last four years to help address the issues above. The approach is intended to work alongside a \u201cCloud First\u201d strategy, so you may recognise parts that have been \u201cborrowed\u201d from traditional approaches, and some may be new to you. The goal of this document is to help you build a vendor agnostic capability model.<\/p>\n

As with all sensible methodologies, you have the freedom to pick and choose the parts that you think are useful. There is only one golden rule \u201cIf you can\u2019t draw it, you can\u2019t build it.\u201d<\/p>\n

Step 1: Gathering the required capabilities<\/h2>\n

From a cloud perspective there are several key capabilities that are considered as standard, which include things like Authentication, Operations Management, Secure Communications etc. It is recommended that you arrange a small number of meetings with stakeholders and IT staff to ensure that the list of requirements is complete and aligns with the business strategy going forward. Getting people to write the capabilities that they need on Post-It notes and put them on a wall is my preferred approach.<\/p>\n

Next, work through the Post-It notes to remove duplicates or fine distinctions, and try to merge items that don\u2019t materially impact the strategy or are technically identical. We\u2019re trying to add simplicity at this stage. If your organisation has a universally known tool that isn\u2019t going to be replaced any time soon, put it in, as it will help people understand what\u2019s being designed.<\/p>\n

Don\u2019t worry if you\u2019ve missed some as this is intended as a living document. Finally, under no circumstances use this as an opportunity to select products or services. The credibility of the Cloud Capability Model rests on its objectivity, and you don\u2019t know what the best tools are at this stage.<\/p>\n

Step 2: Draw Out \u201cCloud Capability Model” Version 1<\/h2>\n

Use of a design or presentation tool is required here. Follow your own approach – what you are aiming for is something visually appealing. Typically I would use Visio, though PowerPoint or Adobe In-Design could be used. See Appendix A<\/a> for an example.<\/p>\n

We can now use colours to separate out the location of services. Also, where a capability is present now, colour it in grey to denote its existence. Don\u2019t be afraid to work in A3 or A2 sizes. Once drafted, we would look to gain agreement that this is what was discussed and then seek executive approval of the \u201cCloud Capability Model\u201d. Explain that this is not going to be used to start a grand cloud roll-out process, merely a considered vision of the future. After all, if you don\u2019t know where you are going, how can you get there?<\/p>\n

Loop around this step until all parties agree, or at least until you have sign off. At this stage, I would recommend printing of a large\/full-size copy to mount in a prominent location.<\/p>\n

Step 3: Shortlist of Projects and Technologies<\/h2>\n

The next task is to go through your upcoming project list and identify, for example, your top 3 projects that will use the new architecture. These first 3 will be used to draw out the stages you will go through as part of your Cloud Transformation.<\/p>\n

Each project will have dependencies on certain technologies:<\/p>\n