Lets get capable with AWS cloud capabilities.

Where are we again ?

Todays cloud platforms are all encompassing, there probably is not an area or field of technology that has not been touched by the services they offer. There are more and more services which have ever expanding horizons, and this is now posing a fundamental question on how we interact with these new capabilities. The question that we now have to face is a simple one and it is

Can we carry on with our first implementation and adoption strategies of cloud services and still be confident that we are realising the true benefits of the cloud ?

Is it enough to trust the marketing hype and dive straight into implementation with the belief that agile working practices will smooth out the bumps in the road ? or has the cloud become to big to quick ignore the need of some thinking at a higher level than just the technical why's and wherefore's.

Like all new technologies the cloud has enjoyed rapid uptake carried along on sometime spurious and sometimes over optimistic claims or reduced cost, risk or increased flexibility. These claims and the 'pay for only what you need' model encouraged a lets just get on and do it attitude which worked initially. If we liken the cloud to the discovery of America then initially it worked just getting out there and getting stuff done just get a pickaxe or a covered wagon and you may just strike it rich. The more this went on the more the smart money turned to providing the tools, providing the rail and communication networks and the infrastructure, looking beyond the immediate to a more joined up way of thinking. This is where we are now with the cloud.. the pioneers have gone out there learned the hard way and our now looking for a smarter way of getting ahead.

How do I know when I need to change course ?

Having worked at quite a few companies at the start of thier journey with AWS it is not uncommon to find that the 'getting stuck in and produce something' approach has been predominant. This engineer led approach can be seen as attractive and in some ways one that aligns closely to the spirit and general philosophy of the cloud. The neural connection we make between managed services and the decreasing need for design and planning is seductive. Why do I need to design and plan stuff that I just need to use ?

The weeks become months and eventually we have applications and artifacts that work with the services in pretty much a vanilla out of the box manner. We have a nice walm glow because we have delivered in an 'agile' manner, no pesky documentation, no unnecessary upfront design and all up and running quickly. So for the ease of understanding lets take the AWS Key Management service as our example. We know have keys being created by applications, services and individuals as and when required. Then our first bills start hitting the accounting department and some uncomfortable questions are being asked as to what are all these keys for ?, do we really need them in lower environments ?, how are they being managed ?, have we a policy or standard around administration and use ? and so on. KMS keys are not in their own right expensive but the cost can escalate in an uncontrolled environment.

We assure our finance department that this is all to be expected and we believe that the costs will level out. Then our security department start to ask questions about key material ?, centralised control of keys ?, seperation of concerns ?, can we trust AWS with key management ? are we rotating keys ?. Then other departments and teams start to create thier own accounts and following our lead start to interact with KMS on their own. Its all starting to feel like a runaway train and the destination is not looking that great. The fear I need to change course and that these questions are not going away starts to take hold.

Big rethink or a strategic repointing ?

So I am guessing you now thinking 'Oh great back to waterfall, rip everything up and wait six months before I can even create a key'. Lets step back and use an analogy to clarify. Lets imagine a country that has multiple distinct regions all self governing and to some degree working in isolation. At some point there is a need in these regions for a rail network to satisfy travelling to the far flung corners of their borders.

Time passes and the regions develop their own rail network catering for their own particular needs. The mountainous areas have a certain gauge of track and the flat arable regions have another and the coastal regions have thier own gauge of track also. Everything is great for a while until we want to transport wheat from the arable regions to the coastal port regions or gold from the mountains to the port via the farmlands in between because as soon as we hit the borders our train falls off the tracks due to a different gauge, and then we have border controls and paperwork ... you can see where we are going with this.

So lets rip it all up and start again but this time we will have a committee that will decide on a universal gauge for the whole country, also lets have a universal border and documentation standard that details everything and lets have a centralised enforcement control that has no interaction with the regions. Six months in we are still ripping up the tracks, nothing is moving and we are still arguing what gauge to use and we havent even started considering what border controls and check we need and so it goes on and we have come to the position of doing something to doing nothing. This is madness nobody would advocate this would they ? Well there are some convincing arguments such as we dont want more and more track being laid which means a bigger job ripping it up at a later date and continuing with the current border framework means we are just entrenching bad practice that needs to be remediated at a later date.

However there is a third way lets concentrate in solutions that change things just at the border and let the current situation carry on and integrate change slowly without ripping everything up. Lets have terminals at the border to unload cargo at the border before sending it back on its way and then slowly introduce switching mechanisms that allow a standardised train to run on different gauges. Lets have an overarching border framework that existing localised arrangements can still work under. With this approach stuff is still going on but we have a better picture of where we want to be and the small incremental steps to take to get there.... enter Capability and value stream mapping..

The Third Way ?

AWS introduced a capability based approach to cloud implementation which I think has a lot of merit. You can read more about this at https://docs.aws.amazon.com/whitepapers/latest/establishing-your-cloud-foundation-on-aws/capabilities.html .

The key takeaway here is that these are functional areas that we should have some interest in even if we rule them out as not being applicable. Also these dont belong to just one team or represent a direct mapping to a technology on the platform. Logging and Monitoring is quite likely to be of concern of Infrastructure, Development, Security and Compliance how its done and with what technology is not our concern at the moment.

Lets look at the diagram below as it relates to KMS and the Encryption and Key Management capability and see what we mean. So I am assuming KMS has already been integrated into the organisation and we have come to a point in our journey where the current model is not answering all our questions but on a day to day basis we are getting the job done.

So we can see that there are variouse rings that wrap around the KMS service, now as we are not it a waterfall scenario we know that some interaction and behaviours with KMS are already in use, now in the longer run these may be replaced, added to or left but we dont want to call a halt to these activities while we resolve some of the questions posed in the business model and capability layer. One thought to hold on to before we dive in is ideally we should look at the business model and capability layer as being technology agnostic.

Business Model (Why are we doing this ?)

The business model is where we really answer why we are doing this by targeting who are customers are and what the value proposition is that we are offering. It is more than likely that our customers are segmented and it may be that initially we will not have a capability that addresses all segments but identifying the segments will help drive out additions to the value proposition and feature sets in the next iteration.

So far example we may state that our customers in the first iteration of this capability are engineers and applications while recognising a future customer segment will be auditors and senior management. We want to offer the ability for applications to protect their data.

Our value proposition could be one of customer experience allowing our recognised customers to easily protect their data. The value proposition is the reason why customers turn to one company over another. It solves a customer problem or satisfies a customer need. Each value proposition consists of a selected bundle of products and or services that caters to the requirements of a specific customer segment. In this sense the value proposition is an aggregation, or bundle of benefits that a customer offers customers.

This may drive our customer relationship which is all about customer retention.

Capability (The What in this equation)

So we may come away from the business model design with answers that show we are not that interested taking this capability going forward and thats fine, but less say we know that we want to offer the capability by answering yes to the need for the capability question.

Also lets say we are only interested at this stage in supporting engineers and applications to have basic interactions with the capability. If this is the case then we can maybe rule out the need for a audit, enforcement and monitoring policy until we come to the next iteration of the business model that will support those customers who want these features. Please note this is subjective and will vary from customer to customer as will the questions that exist in each layer.

We now that to underpin the business model we will need a support model within the capability offering, will these simply be the existing support model of the organisation, something completely different or a hybrid of the two.

We also want to pin down who owns and manages the artefacts that our customers create is it us in a centralised, heavy policy driven methodology or are we going light touch and just offering a consultancy based approach.

What we are doing here is to take some of the answers from the business model and map them to some of the concerns in the capability layer. This is still technology agnostic because we havent looked at the service layer yet.

Service Layer (How does this work ?)

So now we can get down to brass tacks and map what we want to the features offered by a particular technology. It is completely fine to at the end of this process to come to the conclusion that KMS doesnt fit the bill for your organisation and another technology needs to be looked at.

So lets say we want a light touch management of keys as identified by our capability work. We can map this onto the multi account feature of KMS so theres a tick in the box.

We also want to support our customers by alerting them when something goes wrong, again we know we can integrate KMS with SNS and also extend our alerting applications which already use CloudTrail and CloudWatch another tick in the box.

We carry on until we have mapped everything from the business model down to the service feature and note any gaps.

And Finally !!

How are we going to deliver this ... well one way is to identify the capability owner stakeholder and at least one customer. In all likelihood with Key management and Encryption the owner will be the security function and a good candidate customer could be development.

Now because we havent ripped everything thats gone before up we will be able to have a knwoledgeable customer who can map what they do now and what they dont to what the capability needs to do and the we workshop the process out.

The deliverables can be as simple as a set of policies, standards and guidelines managed by the security function to infrastructure as code artefacts that implement the policy and control the interactions with the capability this is dependent on you organisation and what you want out from the process.

This has been a whirlwind tour to get you started its not definitive and please be comfortable that there may be some things that dont fit into the layers that I have described. You may think that some questions should be part of the business model layer rather than the capability layer and thats fine.

What I wanted to show was that it is perfectly possible to map the business needs, to a capability and ultimately the features offered by a service. I hope it helps !!