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 DTAP-Street : a phased approach to a development / deployment cycle

The acronym DTAP finds its origin in the words Development, Testing, Acceptance and Production. The DTAP-street is a commonly accepted method to have a phased approach to software development / deployment.

A typical flow works as follows :

• Development – This environment is where the software is developed. It is the first environment that is used. Changes are very frequent here, as this is the first area where creativity is forged into a product.
• Test – A developer is (hopefully) not alone. In the test environment, the complete code base is merged and forged into one single product. The first attempts at standardization and alignment towards the future production environment are made here.
• Acceptation – Once the development team feels that the product is ready, it will be deployed to acceptance. This is a look-alike of the production and used by operations as a staging environment for production releases.
• Production – The real deal… Here the product surely needs to be ready for prime-time.

Sometimes the following are also added ;

• Education / Training – Sometimes a dedicated environment is needed where people can test drive the software in a safe sand box. Due to efficiency reasons, this environment is often time shared with acceptation.
• Backup / Disaster Recovery – Disasters can happen… Therefore some disaster recovery plans may rely on a dedicated backup / disaster recovery location.
• Integration – An environment that is sometimes located between “Test” & “Acceptance” as an intermediate step to test certain partner integrations. Just as with the “eduction” environment, this environment is often time shared with acceptation.

What are the most commonly used formations?

• Live – Production – Many companies rely solely on a production environment. The risk reduction is often neglected in favor of the cost benefit of having one environment.
• Staging – Production/Test – If no real customization are done to the implemented software, then two environments may suffice.
• DTAP – Development/Test/Acceptation/Production – Once customization hit… then a full DTAP-street is needed to reduce the amount of risks involved with software development.
• DTAPB – Development/Test/Acceptation/Production/Backup – This is an enhanced DTAP-street that is capable of doing a disaster recovery. (Sidenote ; The Test/Development environment is often shared with the backup location. This provides the advantage that the resources of the Test/Development can be sacrificed during a disaster.)

What Code / Data flows occur between the environments?

• Software Versions – Software releases go from Development to Test to Acceptation to Production… The timing varies from the chose release management cycle, though typical times are as follows ; Development (Continuous Builds), Test (Daily Build), Acceptation (Once per quarter, three weeks before production), Production (Once per quarter)
• Data – Data flows in the opposite direction as software versions. Data is taken from production and copied to Acceptance / Test / Development. Depending on the environment (and relative security compliancy), the data may be anonymized or even reduced to have a representative production workload of a limited size.

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.

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!

IT Budget : Run, Grow & Transform

One method of coping with your IT budget is by working with the “Run, Grow & Transform – Your business”-model. In essence is sets you to categorize your budget into three areas.

Run covers the general day to day expenses of keeping the IT infrastructure running. Actually, this is your “SIB” (“Stay In Business”). Think in terms of lifecycle management and the human resource costs to maintain your environment.

Grow covers the expenses for expansion of services or growth of the company. Things like extending your virtualization or storage farm probably fall under this category. This budget aims to help the organization introduce new capabilities or improve existing ones.

And Transform covers the costs are made to change your nature. Here you should think of things like implementing a shopfloor system when coming from a paper workflow within an industry. These initiatives might seek to identify, for example, the right technologies for new organizational capabilities; fundamental changes to business processes; or a new product or service offering.

When managing a budget in this manner, you should be able to gather tour full “Run” budget and a part of the “Grow” budget. If you fail to do so, then you have lost the confidence of your board. This part of the budget is in reality the minimal level you need to stay on par. A lower level will force you to start phasing out services from your service catalog!

Organizations that have to trim IT budgets should avoid cutting Run initiatives. Such cuts would introduce operational risk. If an organization already is going through a tough stretch, the last thing it needs is a server, application or network failure. This really is your “Stay in Business” IT budget.

Grow budget items should tie directly to the organization’s strategic initiatives. These initiatives usually are not as mission critical as Run initiatives and often have some time flexibility, which means that they are good candidates for starting early when additional cash is available, or for deferral if cash is tight.

When finances are tight, transform initiatives often are the first to be cut or deferred—unless they are associated with key strategic initiatives that the organization views as essential to its continued operation. Even if the organization doesn’t deem certain Transform initiatives immediately essential, care should be taken when considering cutting or deferring them. That’s because Transform initiatives often are key to the organization’s long-term health. Failure to provide adequate resources to Transform initiatives can stunt an organization’s future success.

Mimicking doesn’t work! Understand why you do things…

Cargo Cult
Ever hear of “Cargo Cult“?

“A cargo cult is a religious practice that has appeared in many traditional pre-industrial tribal societies in the wake of interaction with technologically advanced cultures. The cults focus on obtaining the material wealth (the “cargo”) of the advanced culture through magic and religious rituals and practices. Cult members believe that the wealth was intended for them by their deities and ancestors. Cargo cults developed primarily in remote parts of New Guinea and other Melanesian and Micronesian societies in the southwest Pacific Ocean, beginning with the first significant arrivals of Westerners in the 19th century. Similar behaviors have, however, also appeared elsewhere in the world.

Cargo cult activity in the Pacific region increased significantly during and immediately after World War II, when the residents of these regions observed the Japanese and American combatants bringing in large amounts of matériel. When the war ended, the military bases closed and the flow of goods and materials ceased. In an attempt to attract further deliveries of goods, followers of the cults engaged in ritualistic practices such as building crude imitation landing strips, aircraft and radio equipment, and mimicking the behavior that they had observed of the military personnel operating them.”

The red thin line throughout this story is that mimicking doesn’t work! Attempting to recreate succesful outcome by replicating circumstances associated with the outcome, although those circumstances are unrelated to the causes of the outcome or insufficient to produce them by themselves, will fail! In our day-to-day lives, we come across this situation frequently. People who repeat a given ritual just because they were told to do so, without knowing why they actually do it. Let’s get down to earth, and reflect by looking towards our own job… Are their aspects where we just repeat things we’re said, without actually knowing why we do it? *silence*

The tail of the fish
There is another, not so known story, that reflects to the same situation.

A mother is baking a fish. Before she throws in the fish, she chops of the tail. The little daughter asks; “Mommy, why do you chop of the tail?”. The mother replies; “Because my mother did so.” The little daughter visits the grandmother a week later and asks ; “Granny, why do you chop of the tail of a fish before baking it?”. The grandmother replies; “Because my mother did so.” That week, the little girl visits her great-grandmother in the nursing home and ask here ; “Nana, why do you chop of the tail of a fish before baking it?”. The great-grandmother replies; “Because the pan was to small for the fish. So we chopped of the tail so it would fit!”.

So know why you are doing this… Mimicking might work out sometimes, yet in most of the cases you will not be working efficiently.

Welcome to WordPress.com

After having hosted my own blog myself since the beginning, I’ve decided to move to WordPress.com. It might look like an odd choice to make, yet this leaves me without the worries of maintaining (upgrades/upgrades/security/…) of my own.

Fluent change management in Project Management

Source : How To Be A Change Agent In Project Management

Talk the Talk You are more likely to gain support from upper level management if you can speak their language. There are many aspects of project management knowledge that overlap with other disciplines. Communicating in a way that demonstrates your understanding of a peer’s area of expertise will help them trust that you know what you are doing in your sphere of specialization. So, when you speak to Accounting you might pepper your conversation with terms like short term ROI and amortization. Just be careful not to use jargon unless you really know what it means. If you don’t use terminology correctly and in context you will simply end up looking foolish.

Big Picture/Small Picture Be aware that not everyone wants or needs to hear your grand vision for creating positive change through updated project management methodology. You should develop two spiels. One is for people who like a lot of context. Diagrams showing how project management is related to other business processes and how changes will affect the company over time are useful for these audiences. – Others want you to cut to the chase since they only care about how your suggested changes will affect them or their department directly. For these individuals, a short bullet list of what you need from them is the best tool you can use to gain support. It keeps things simple and shows that you understand the value of people’s time.

Showing Value Besides communicating what you need from others, you also need to show specifically what you are going to do for them in return. For example, a discussion with the HR director needs to focus on human capital management. This is the time to make realistic predictions about how greater project management efficiency will translate to lower labor costs. You can also seek feedback regarding how your new way of handling projects may impact employee engagement. – For IT, you could talk about how using a particular version of project management software would relieve them of the burden of ongoing development and maintenance. When you are negotiating with stakeholders, be sure that what you are offering actually has value to them. If you aren’t sure what they want, ask. Then, you will know where you stand in negotiations.

Wage cut or wage freeze?

Source : Sticky Wages

Check out the above story… It refers to the term “sticky wage” where companies didn’t cut wages in recessions. They just made them “grow slower”… Yet lately there have been actions where wages were cut and it’s an odd move when thinking of the following statements (which are quoted from the article).

• 1. Employee Morale: Truman Bewley found out that pay-cuts affected everyone’s morale, while firings only affected the minority. I am sure all of you, who have seen layoffs agree that the people left behind, are much more productive than they were ever before. When you see your colleague getting fired, you work extra hard to make sure that you are not next in line. Pay-cuts don’t have the same effect, as everyone is on the same boat, and there is no shock effect to spur employees.
• 2. Fear of the best people leaving: The job market has slowed down in the recession, but there are still plenty of firms that are hiring. If an employer cuts salaries across the board, it is quite likely that the better workers will find work elsewhere. So, firms which implement across the board wage cuts, risk disgruntling their better employees and have them leave for greener pastures elsewhere. This factor is a major contributor to sticky wages.
• 3. Get rid of Wally: Not all employees are created equal; some are more efficient than others. In all companies there is some deadweight. Some of your employees will be like Dilbert, some like Alice and then you will have a Wally. If you kept Dilbert and Alice, and fired Wally – your team will still do well, if anything the overall productivity of your team will increase. Even the Pointy – Haired boss knows that it is far better for him to fire Wally, than to take a chance by cutting the salaries of Alice and Dilbert, and risk losing them to Elbonians.
• 4. Preparing for the turnaround: Another factor that contributes to sticky wages is the hope of a turnaround. I know several people who are hanging around in companies without any work or pay – cuts. While there isn’t much demand for their skills now; their employer doesn’t want to take a chance. The employer is worried that if they let this person go, the competitors will build a strong team in this particular area, and drive them out of business when the market eventually turns.