Developing a Hybrid Cloud model

In the process of developing and refining our company hybrid cloud, enterprise consultancy offering I've come to finally bundle my experience in cloud of the last 10 years. It's been a long road of more than a year now, with ups, downs, enthusiastic customers and colleagues, both in consultancy role and in internal architect designing capacity. As the hybrid cloud and the accompanying landing-zone concepts for classification and roadmap development are mature enough, I want to share a bit of how a simple concept can help you focus on when, how and why cloud fits your organization.

Starting a journey..

First, for our current effort of defining enterprise cloud, we had to recognize a pattern. We see a lot of cloud scenario's replay repeatedly at different stages of sourcing efforts, in different companies and industries. We're not the only one's seeing these scenario's play out, so we assume some of it is a repeat of what is common in cloud adoption strategies. My own journey starts in 2012 as the Enterprise Infrastructure Architect at PostNL (the former state-owned Dutch postal service). Here I'm charged with envisioning a roadmap for the company towards a data-center-free, completely cloud-based IT service landscape. Even though I now think a cloud-only strategy is not applicable in most situations, the way such a target frames your thinking can be very effective. So this framing helped me to manage a playing field which involved the PostNL organization, but also a multitude of suppliers and partners on what it means for a large Enterprise to become a Cloud-only company.

Uphill climb

Creating adoption with both vendors and internal stakeholders was sometimes an uphill struggle, where you need to take three steps in quick succession to slide back one or two steps. In both vendors and internal power structures we had to overcome a lot of loss aversion patterns. It takes more effort and evidence to change. Numerous hours were spend with vendors trying to sell us their idea of cloud. Most vendors kept focusing on their center of the universe approach, which was not focused on creating value for us (their customer). Also internally I had many discussions on current vs future roles and way of working. In the end, success of any large scale change is fostered by a growth mind-set, not by spreading your bets and keeping your old ideas afloat like zombies feeding of the collective brain-power, more on that later with regards to a hybrid approach.

..getting lost in the hype

So.. should I burn down all my existing data-centers then? No you shouldn't, at least not while you still have a valid business reason to keep them. Being a launching customer (for more than one vendor at scale) has some drawbacks. Inventing everything yourself is a big risk, as vendors tend to lean back and adopt a classic tell me what you want and we'll send a price estimate. Here I used business value as a guiding principle on which you should base your decision making. One of the aspect of business value is the capability for your organization to realistically adopt the new way of working. So your new way of working has to include you as a customer, but also your suppliers and partners. When focusing these vendors on your business value, don't tell them how to do their job. Tell them of the outcome you expect for your business from their offerings.

Staying on course

In a hybrid approach you define where you as company want be after a transformation, how you engage with your customers and how you approach your Eco-system of competitors, vendors and what you do best to differentiate or be recognized within this eco-system. A hybrid categorization approach offers a way for you to focus your attention on things that matter, define the approach per category of how to get there, who does what and how your future ongoing organizational change will be able to thrive using a hybrid approach. You select the partners, platforms, where to adopt market standards, where to differentiate and where you will take the lead in this eco-system, based on your (future) market position.  

In areas of work where you want to be efficient and conforming to market standards you select a BPOS or  SAAS approach. Where you want to make something unique, something you can't buy, you have foster a development mindset and create the supporting technology platform.

Remember that change is not a one time exercise, the change capability is one of the most important traits an organization has to foster, change being the only constant factor. Once you have a categorization this can help you evaluate your different change adoption scenario's, it helps your organization to visualize to stay on course. The hybrid mapping approach can help visualize this process see the effect. Other approaches of categorization are also useful, a well known approach like Wardley mapping comes to mind. Wardley mapping works best in detailed and focused use cases, where the hybrid mapping approach gives you insight into change over time in a larger landscape.

Assisting fellow travelers

You're not alone, in your ecosystem you'll find customers, partners, suppliers and even competitors, which are all dealing with the same issue of constant change. By making sure that you extend into the ecosystem, use it and offer help, not only when it improves the specific goals of a line of business, it will benefit your company as well.

The Model

The model is loosely based on how you in the past would carve out landscapes for sourcing strategies. You would sometimes create competence centers, for adopting technology and sometimes even a silo-ed way of working. The difference with this approach is that it should be more technology agnostic, with a strong emphasis on business outcome. On the horizontal axis you define 3 to 4 different approaches to certain business value, way of working (and ultimately the differing technical implementations). The vertical layering is build-up top-down (business value first, then way-of-working and finally the technology layering). Because it is a cloud based approach we define the classic IT layering on services types and not technology implementation. As long as you can match your organization's value on such a digital service, it's merits (or sometimes dis-qualifiers) can be assessed for the intended purpose.

We've seen the concept of landing zones repeated multiple time in the past 20 years, even the NIST cloud service model (IaaS, PaaS, SaaS) can be seen as some form of landing zone categorization, although it's mainly IT service driven segmentation. That's why our enterprise cloud model is so easy to grasp for everyone who's seen these models. You can use our basic model and it's principles to create a tailor made landing zone definition for your own company, to help focus discussion and communicate roadmaps.

The main difference with all the previous models and our current iteration is that as IT moves up the stack, this model also moves up the stack. It's coupled to business goals, outcome driven, taking culture and way of working into account, and with it every meaningful development out of the DevOps and Agile learning's. The era of internal client - delivery organizational divide between a business and it's cost-center IT approach, should finally become a thing of the past. Approaching your internal change by focusing your efforts out-side in, from business and client outcome towards implementation.

The future

This governing model of course is not the actual game-changer, many people have come up with similar ideas and a model can never actually replace people working on real world improvements. But without a framing of improvements and why they could have a potential value would be like plotting a course without a map, compass or notion of staying on course. When used well, the models you adopt can even be used to navigate through uncharted territory.