Azure : IT Governance in the cloud

Introduction

During the weekend I saw the following tweet passing by …

Hosting company Verelox has had all their customers dedicated and virtual servers wiped. Their statement: pic.twitter.com/XvAQcofJKu

— Kevin Beaumont (@GossiTheDog) June 10, 2017

Apparently, a hosting company (allegedly) got all their data wiped by an ex-admin. Now I can imagine people thinking that this is something that is part of the territory when it boils down to cloud. So I wanted to write a blog post entailing what you do to set up a governance structure in Azure. Here I’m aware that the above tweet is more related to the security aspect of governance, it’s a part of it nevertheless.

 

Governance?!?

Let’s get started on our scope… IT Governance can cover a lot of ground. In essence, the goal is to assure that the investment in IT generates business value and the risks that are associated with IT projects are mitigated. Though I found that CIO.com has a nice definition on it ;

Simply put, it’s putting structure around how organizations align IT strategy with business strategy, ensuring that companies stay on track to achieve their strategies and goals, and implementing good ways to measure IT’s performance. It makes sure that all stakeholders’ interests are taken into account and that processes provide measurable results. An IT governance framework should answer some key questions, such as how the IT department is functioning overall, what key metrics management needs and what return IT is giving back to the business from the investment it’s making.

So let’s take a look at how we can put an enterprise-grade structure around the management of Azure!

 

TL;DR = Azure Enterprise Scaffold

For those who want to skip the post below… When talking about governance in Azure, the best place that summarizes it the following page in our documentation ; “The Azure Enterprise Scaffold“.

Lingo Explained : Lombardi Time

Personally, I am someone who is always on time. A disaster must have struck down upon us before I am late to anything. I would rather sit in my car for an hour as I am way too early for a meeting, than to be a minute late. This week I learned that there is a term that follows the same belief!

Vince Lombardi was the head coach of Greenbay Packers. He ran a disciplined regime and introduced something that later became known as “Lombardi Time” ;

Lombardi expected his players and coaches to be 15 minutes early to meetings and practices. Not on time — 15 minutes early. If they weren’t, he considered them “late.” Thus, it came to be called Lombardi time.

A fun fact ; The clock above the entrance of the Greenbay Packers their stadium runs 15 minutes early… 
So next time we have a meeting together, show up on Lombardi time. I’ll be there!

A roadmap to the cloud… Where should I focus on?

Cloud is here to stay!
A lot of questions about “THE Cloud” have risen the last years. In the beginning, the most responses included that it was a hype or that it was a rebranded solution from the past (“ASP“). Though at this point in time, it is safe to say that “Cloud Services” are here to stay and that there is no point back but to embrace them as an IT department. My personal sentiment is that the current market leaders “Amazon” & “Microsoft” will continue to grow and eventually dominate this market. As google has enough cashflow, I suspect that they will join in this battle. So the current conundrum is ; how to move your current landscape from an “on premise” way of working towards the cloud…?

Cloud Maturity Model
For organisations who are stuck with this question, I would like to point out to a fine document (“Cloud Maturity Model“) of the Open Data Center Alliance. It describes the different stages, even from different perspectives, that you will traverse in your journey.

Quote about the cloud maturity model ;

Progression through the various maturity levels is based on the evolution of a number of parallel capabilities, as described in the following figures.
The result is represented by an inferred resulting maturity, roughly mapped as follows:

• CMM 1. (Initial / Ad Hoc) The existing environment is analyzed and documented for initial cloud potential. Pockets of virtualized systems exist, for limited
  systems, without automation tooling, operated under the traditional IT and procurement processes. Most of the landscape still runs on physical
  infrastructure. The focus is on the private cloud, although the public cloud is used for niche applications.
• CMM 2. (Repeatable / Opportunistic) IT and procurement processes and controls are updated specifically to deal with cloud and who may order services and service
  elements and how. Private cloud is fully embraced with physical-to-virtual movement of apps and the emergence of cloud-aware apps.
• CMM 3. (Defined / Systematic) Tooling is introduced and updated to facilitate the ordering, control, and management of cloud services. Risk and governance controls
  are integrated into this control layer, ensuring adherence to corporate and country requirements. Complementary service management
  interfaces are operational. More sophisticated use of SaaS is evident, and private PaaS emerges.
• CMM 4. (Measured / Measurable) Online controls exist to manage federated system landscapes, distributed data and data movement, federated and distributed
  application transactions, and the cross-boundary transitions and interactions. Defined partners and integration exist, enabling dynamic
  movement of systems and data, with supporting tool layer integration (for example, service desk, alerting, commercial systems, governances).
  Cloud-aware apps are the norm and PaaS is pervasive. Hybrid apps develop across cloud delivery models.
• CMM 5. (Optimized) All service and application deployments are automated, with orchestration systems automatically locating data and applications in the
  appropriate cloud location and migrating them according to business requirements, transparently (for example, to take advantage of carbon
  targets, cost opportunities, quality, or functionality).

So far, so good… yeah? I know, this all still sounds a bit “fluffy“. The basics to remember is that there are various stages involved so you can keep track of where you are. Though for me there are three focus points that every organisation should embrace in order to be ready for the future with cloud services.

• IAAS has become commodity
• Federation is the new black
• Interoperability is mandatory

IAAS has become commodity
I do NOT believe in on-premise virtualisation farms anymore… for the majority of organisations. I must concur that there are use cases that would still require this, though for the majority of organization this is not the case. I can see you pondering “But we are special!”, and I must disappoint you, most organisations are not. Internal IT should focus on the things that deliver real value to an organisation. An Infrastructure-as-a-Service layer has become a basic commodity in the market and you should embrace it. The time you spend in maintaining the lowest layers is better invested in real business value. I, yet again, concur that this will imply a shift of skills needed…

“When the winds of change blow, some people build walls and others build windmills.” -Chinese Proverb

Federation is the new black
Let’s start with a quote from the maturity model ;

Federation refers to the ability of identity and access management software to be able to securely share user identities and
profiles. This ability allows users within a specific organization to utilize resources located in multiple clouds without having to generate
separate credentials in each cloud individually. IT is able to manage one set of identities, authorizations, and set of security review processes.
From the user perspective, this enables seamless integration with systems and applications.

For most organisations, start with setting up a federation service… Active Directory Federations Services, or a SAML provider, pick something that best fits your current technology stack. Though be aware that federation is a key, if not THE key, component of a succesful cloud roadmap!

Interoperability is mandatory
And, yet again, let’s start with a quote ;

There are two key concepts of interoperability: (1) The ability to connect two systems that are concurrently running in cloud
environments, and (2) the ability to easily port a system from one cloud to another. Both involve the use of standard mechanisms for service
orchestration and management, enabling elastic operation and flexibility for dynamic business models, while minimizing vendor lock-in.

Your high level architecture should consist of “islands”, which are linked together via APIs and/or abstraction layers and where authentication is done via federation mechanisms.

In addition, keep in mind that you will move systems around. So interoperability towards migrating systems is a key requirement and should always be a focal point in your decision-making. For instance; Think about exit scenarios with a specific cloud provider. How will you handle this?

Conclusion (TL;DR)

• Cloud is here to stay. In a few years, it will be the defacto standard.
• Infrastructure-as-a-Service has become commodity. In a few years, this segment will be dominated by Amazon, Microsoft & Google.
• Federation is the new black. If you haven’t set up a federation system… DO IT NOW!
• Interoperability is mandatory. Always keep in mind that systems should be portable islands which are built for data interaction.

Best practices regarding the creation of an “RFP” (aka “Request for Proposal”)

The Overall Process

• Study ; The first step… Consider what you want to achieve and what’s life currently like. This might seem as a no-brainer, though you might be surprised how few organisations actually do this.
• RFI ; So you have a great idea? Fantastic! Now compare this with what is currently seen as industry standards and what are common solutions positioned by vendors. My advice here is not to differ too much from the ongoing standards, unless this is really ground breaking or market differentiating for you. Though, in most cases, you are just looking to keep your business running. In the latter case, keep as close to the standard as possible.
• RFP/RFQ ; So we know what we want, and what is possible at this point in time by the market. Let’s select our vendors from who we wish a clear-cut proposal. We’ll go more in detail about this phase later on… So don’t worry. 🙂
• Project ; Once the selection is done and contract negotiations are (near) closed, the project can start. This usually starts with a due diligence by the vendor to check if the assumptions / constraints are still valid.
• Operations ; A lot of people think that operations stops during this project. The reality is far from it, and that’s actually common sense! We do projects to enhance our operational baseline, but the latter is a moving target. We cannot freeze our business for half a year! So be aware of this…

Study
The first step before any project should be a “study”. Do a requirements analysis, update your views on the operational baseline and define the target flag of what you want to reach. Now you can do a fit-gap analysis and see what needs to be done. If the entire matter is way to big… Slice it into smaller / manageable chunks. In the past, we often saw “big bang”-projects which have shifted towards “Roadmaps”. In a Roadmap, the road towards the end goal is mapped via smaller / more realistic paths (projects). The conjunction of all these projects ensure that you reach your path. Though where it might be possible to enter all these projects into one RFP, in most cases it might be more interesting to spread them as your operational baseline is (with due reason!) a moving target.

RFI
Your job is mostly focussed to serving your internal business processes. It is not wrong to say that you are not an expert in the sector you want to purchase from. This is not something to be ashamed of! Though, be aware that your vendor IS an expert in the matter. During the “RFI” (Request for Information”) you are going to study the relative sector from which you are looking to acquire services/products. Research into the products and do not be shy to invite vendors over to discuss their products. Learn to know their (dis)advantages and how they can serve your business. In the end… always translate certain “features” / “technologies” into basic requirements. For instance ; IT Storage projects revolve around “capacity”, “performance”, “availability” & “integration”. Thin provisioning, snapshotting, deduplication, … all revolve around “capacity”. So do not be fooled by the nice “bling bling” that vendors portray and search for the essence of what you want to achieve. During this round, you will also define your list of requirements and selection criteria! So be sure to look for the elements that should compose these requirements/criteria.

RFP/RFQ

Phases

• Start-up ; Invite the vendors to take part and ask them to confirm. After receiving confirmations, send the RFP to all vendors at the same time.
• Round One ; During the first round, you will allow the vendors some time (typically one to two weeks) to process the RFP. At the end of that period, they will need to have sent all their answers to you. You will process these and provide all vendors with a list of all questions & answers. After which, you will allow them again a given period to adjust their proposal to fit these answers. After the deadline, you will do a “downselect” of the vendors to reach the number of vendors you want in round two.
• Round Two ; When going through the answers of round one, you will notice that there are fundamental differences between vendors. Now you will adjust your requirements to align all the vendors towards one target. In addition, you will invite the vendors to explain their proposals into more detail. This will give you a more profound insight into the reality of things. At the end of this round, you will once again to a downselect to reach the last contestants (typically two or three).
• Last Round ; At the beginning of the last round, be sure to provide the remaining vendors with a clear-cut baseline that everyone should meet. Now you do not want any structural differences between the parties anymore where the main focus will be around meeting the target and pricing. Clearly indicate that this should be their “Best And Final Offer” (“BAFO”), which will be presented at CxO level. At the end, choose the party which ranks the highest in relation to your selection criteria.
• Contract negotiations ; After the selection, contract negotiations will start. In some cases, an “LOI” (“Letter of Intent”) will be signed to create a non-linear relation between the contract negotiations and the project start.
• Project Start ; The project will start with a due diligence; Here an investigation will be done by the vendor to check if all the assumptions made (and agreed upon) are valid. After which the project will kick-off!

Be aware that these kind of processes can take up to half a year! So be sure to initiate them with ample time left before your deadline. Also be aware that these things will have a delay and in most cases this is caused by yourself! You still have your regular job to do… and you will get questions that you did not consider and need time to analyze.

RFP/RFQ Document Contents
So how should a typical RFP/RFQ document look?

• Management Summary ; Create a one-pager for executives from the vendors to read through.
• Context ; Why do you launch this RFP/RFQ? Provide an insight into your way of working/environment. How does this project interact with it?
• Timing ; Setup a clear timing table. Each phase should have a clear deadline… An RFP/RFQ is a project so be sure to manage it like a project. This is also important for the vendors to allocate resources towards the process of answering the proposal. It is in your best interest to ensure that they can prepare themself properly.
• Selection Criteria ; Always use (and communicate!) selection criteria. You, and the vendors, should know how you will quote their proposals and make the final selection. Be ware that these will become the core driver for the proposals! If you hand out more than 50% on price, then you will get skimmed down offers.
• Requirements & Product/Service/Project Definition ; Apart from the selection criteria, also be aware that the vendor will provide you the most slim answer to meet your requirements. So if you didn’t define it, you will not receive it! Do not assume anything… This might again look like a no-brainer, though… 😦
• Constraints ; Actually, these can also be considered requirements… Yet be sure to state that a vendor should take certain constraints into account. Do you require a certain transition / honeymoon period? Do their employees need to have NATO-clearance, …
• Pricing Table ; You do not want all vendors to provide their own pricing table… You will not be able to compare apples with oranges. So provide your own pricing table and adjust it according to the feedback from each round. In fact, your RFI phase should have already provided you with ample information to create a pretty stable pricing sheet.

The IT Crowd stance on writing Advice Documents

After writing the a post about writing an advice document a while back. Now I’ve created a storyline presentation themed by “the IT Crowd” ;

Lingo Explained : Child / Beginner’s Mind

In Zen Buddhism they have a concept called “Shoshin (初心)” meaning “a beginner’s mind”. Sometimes it is also referred to as “a Child’s mind”. It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject.

Due to our experience, we often already have certain prejudgements about the scenarios we are in. These limit our vision, narrowing our view on the matter at hand. Going one step back, starting from a blank slate & posing question is the way to think as a “beginner”. The view of a beginner will make us look at a situation from another viewpoint, thus providing us with additional information to which we may have been blinded.

Lingo Explained : Plain Vanilla

“Plain vanilla is an adjective describing the simplest version of something, without any optional extras, by analogy with vanilla ice cream, the default flavour. Some Financial instruments like put options or call options are often described as plain vanilla options. The opposite of plain vanilla options are exotic options.”

Lingo Explained : Push The Envelope

Another idiom I see myself using occasionally is the “Push The Envelope”, where it’s come to my attention that it’s not that commonly spread as I would have imagined.

push the envelope
Fig. to expand the definition, categorization, dimensions, or perimeters of something.

The following website has a nice debrief on the matter ;

Meaning

To attempt to extend the current limits of performance. To innovate, or go beyond commonly accepted boundaries.

Origin

This phrase came into general use following the publication Tom Wolfe’s book about the space programme – The Right Stuff, 1979:

“One of the phrases that kept running through the conversation was ‘pushing the outside of the envelope’… [That] seemed to be the great challenge and satisfaction of flight test.”

Wolfe didn’t originate the term, although it’s appropriate that he used it in a technical and engineering context, as it was first used in the field of mathematics.

The envelope here isn’t the container for letters, but the mathematical envelope, which is defined as ‘the locus of the ultimate intersections of consecutive curves’. In a two-dimensional example, the set of lines described by the various positions of a ladder sliding down a wall forms an envelope – in this case an arc, gently curving away from the intersection of the wall and floor. Inside that envelope you will be hit by the ladder; outside you won’t.

(Note for the mathematically inclined: it might seem intuitive that the centre point of the ladder would follow that same arc. In fact it describes a circle centred around the origin).

That’s enough mathematics. The point is that an envelope is that which envelops. The phrase has something in common with an earlier one – ‘beyond the pale’. Inside the pale you were safe; outside, at risk.

In aviation and aeronautics the term ‘flight envelope’ had been in use since WWII, as here from the Journal of the Royal Aeronautical Society, 1944:

“The best known of the envelope cases is the ‘flight envelope’, which is in general use in this country and in the United States… The ‘flight envelope’ covers all probable conditions of symmetrical manoeuvring flight.”

That envelope is the description of the upper and lower limits of the various factors that it is safe to fly at, that is, speed, engine power, manoeuvrability, wind speed, altitude etc. By ‘pushing the envelope’, that is, testing those limits, test pilots were able to determine just how far it was safe to go. By 1978 the phrase was in use in print. In July that year, Aviation Week & Space Technology magazine had:

“The aircraft’s altitude envelope must be expanded to permit a ferry flight across the nation. NASA pilots were to push the envelope to 10,000 ft.”

The following year, Wolfe picked up the phrase and it went from a piece of specialist technical jargon into the general language.

And on a personal note, I always link it to the following scene from my younger years…

Anyhow, it is one of the perks of acting as a fox to “push the envelope”!

How to write an advice document?

Too often… I notice that people stumble with writing advice. With some basic guidance, this shouldn’t be that hard!

So what should an advice document look like? Let’s start with the high level skeleton of this document ;

Management Summary
Most (upper) management does not have the time / interested to go into details. Do not get annoyed by this, it’s just how it is… Therefor start off your document with a “management summary”! This in fact an Elevator Pitch or the details of the document below. In regards to timing, this is the last chapter you write. Yet do NOT put it at the end as a “Conclusion”, but in front as a “Management Summary”.

Context
Context matters! Really… CONTEXT MATTERS! 😉 Describe the specifics of the environment you are working in. Describe the culture, the principles at hand, the history of things, … anything that matters into shaping your advice.

Current Situation
Do not jump to conclusions! First describe the starting point… Why do you want to advice things? There is nothing wrong with the way we are working now, or is there? Give an indication towards the circumstances and the effect of those aspects.

Ideal Situation
Now describe your “ideal” (given the context!) situation. Provide a thorough insight into the aspects the ideal situation solves and the motivation why you want to change things.

Path to…
Now we know the starting & the targeted goal, so it is time to set the path. In most cases, an immediate jump towards the end goal is not feasible. In that case, describe the intermediate steps that need to be accomplished to reach the goal.

I hope this was helpful and improves the advice documents you write. Anyhow, here is a quick cheat sheet to in case of emergency… 😉

What kind of person or company are you? A fox or a hedgehog?

In the past I’ve already blogged about the “Fox or Hedgehog” story. Today I want to do it once again.. Simply because there are still a lot of people who aren’t familiar with the story yet.

A fox and a hedgehog were strolling through a country path. Periodically, they were threatened by hungry wolves. The fox —being blessed with smarts, speed and agility — would lead packs of wolves on a wild chase through the fields, up and down trees, and over hill and dale. Eventually the fox would return to the path, breathless but having lost the wolves, and continue walking. The hedgehog, being endowed with a coat of spikes, simply hunkered down on its haunches when menaced by the wolves and fended them off without moving. When they gave up, he would return to his stroll unperturbed.

The Fox

• Complex Thinkers, who account for a variety of circumstances & experiences
• More cautious, centrist, likely to adjust their views, pragmatic, prone to self-doubt, inclined to see complexity & nuances

The Hedgehoge

• Keen ability to focus & drive a single path
• Focused world view, ideological leaning & strong convictions

So what is the best type? Like with every consultancy answer… It depends!

Hedgehogs have the benefit of focus and ability to keep their heads out of trouble during though times. They avoid substantial risk and will try to conserve their current state. The disadvantage is that this conservatism holds them back and markets move past them. They cannot release their defense mechanism of focusing on that one thing.

Foxes have the benefit of broad vision and ability to oversee complex situations. They succeed because they have the ability to step outside of the market path. The disadvantage is that their vision can exceed the market or that they have a difficulty maintaining focus to see things through.

So in the end, you will need both… Just like nature tried to balance everything out. Envision Steve Jobs as the Fox, and Wozniak as the hedgehog. Apple wouldn’t have been the apple we know today if it wasn’t for BOTH of them!