The cloud journey: a look back from 2025

Ten years ago we made the decision to begin to embrace the growing trend of Public Cloud Computing. We started with what we thought was a reasonable goal of moving 25% of our IT portfolio to the cloud. It’s clear that we really didn’t understand what that would mean or how we would get there, but we knew that in making this transition we would learn how to take advantage of the “cloud promise”. It’s hard to underestimate the amount of change that initial goal has wrought on our company and our ability to manage our portfolio. It’s easy to see that impact now! In writing this look-back, I’ll try to capture all the things we learned along our journey to the cloud, and how we approached the solutions we needed to create.

When we first took a look at “the cloud” it was basically a technology looking for a problem to solve. Microsoft and Amazon both approached us -with our four major data centers, a small army of outsourced developers and support, and a typical portfolio of COT and purpose built software – with this new “as-a-service” model, which looked a lot like external hosting. Our assessment of cloud technologies in 2015, was focused on the business value in primarily IT terms of comparative cost to run: IAAS

By the end of this journey we came to the realization that there was no end, however we were able to leverage the cloud to truly enable the business. Beyond the run-cost savings we achieved we also avoided a number of expensive capital purchases to extend our data center in China or build a new data center to serve India as the business shifted (“reach”). Business units like procurement were able to put their licensing application in the cloud and online before IT could even get it through our portfolio process which provided us with a significant competitive advantage. We found IT could guide rather than do and we learned that when we engaged them early in the cycle they provided significant without slowing us down We became a team member on our CEOs scorecard projects for improving our business process. That was a sea change versus the way we used to engage when IT executive engagement was relegated to merger tracks (where the implementation would “go dark” to the business) or an IT-builds-it-all-or-we-don’t-play. The biggest win for our operating discipline as a company was being able to externalize systems easily to customers and suppliers. When we had developed an internal asset to the point of it being useful externally, we could just flip the bit and our partners were able to leverage this capability as well. This provided us competitive wins for the company which accrued to us in IT directly!

When we first started those our initial proofs-of-concept, we realized that we needed to reevaluate some of our processes as well as some of our infrastructure limitations:

That’s not to say that this new platform didn’t exist – our vendors were able to help us understand the mapping from where we had architecture principles baked into our internal “platform” of VMWare images (for common application patterns) to what the equivalent would be in the public cloud, or where we no longer needed certain elements. DR was different, our concept of scalability changed, etc. All the elements were all there, but different. It required us to think differently too.

In hindsight, it’s clear that the elements we complained the most about were actually due to how brittle and inflexible our on-premises systems were rather than whether the cloud addressed them. Our security team, for example, was very concerned and raised a lot of issues and roadblocks around data privacy. What was more interesting though was that we found our own internal audit and control processes didn’t measure up to the to the compliancy and certification story our vendors were able tell. We wouldn’t have passed an audit ourselves, and Microsoft and Amazon had already paved the dirt road here! The other area that stood out was the evergreen nature of the services – that our vendor would keep systems up to date. The subscription model helped with both security updates and more often than not the actual platform itself (we didn’t end up running as many “upgrade” projects from version 1 to 2 across the portfolio). We found that we were able to concentrate on things that made a difference to our business rather than merely running in place trying to keep everything patched.   It was hard for the team to “let go” of some of the control they had but when they made the change, it was clear that the impact was positive very quickly.

We started with one notion of “cloud” and eventually went down a few different “paths” of cloud as very separate opportunities: initially, we did what we knew and started with moving internal private-cloud (VMWare-style) applications to IAAS. After a while, the need for continued on-premises support meant that we didn’t see the across the board operational cost reduction that we had hoped to gain. IAAS was effective, but we weren’t really seeing the efficiency and cost savings we had been led to expect.   Though we saw benefit we definitely felt that we should be able to do more.

We looked at SAAS (Office 365) for a very different set of reasons – here was an initiative that met our annual IT cost reduction targets in just one project! We were able to retire expensive on-premises systems, gained a much better SLA and pulled IT contracted labor out of a situation we hated to manage. We had under-invested in pre-production (development and test) environments for years – a case of the shoemaker having the poorest shoes. We didn’t see much cost savings in moving these systems to the cloud, but it allowed us to really follow our stated application life-cycle and maintenance methodology. For the first time, we could truly build cheap, high-fidelity environments and only pay for them as projects approached deployment. When the project was done, we could turn those environments off!

Finally, we took on the real winner, which was creating a standard application platform model (PAAS). This was a big change to our developer focus – to pull out of application tooling and commit to a vendor platform, which would keep us up to date and would provide the “–ilities” as part of the platform (e.g., scale and reliability). PAAS forced us to think differently and more modularly. Working in this type of environment really drove a new class of home-grown application – one that was more functional and more stable and reduced the outages (and midnight support calls!) Once we had these operating processes working in the cloud, the architects developed a framework to guide our system developers into effective platform selection (our internal private cloud or this new cloud). We introduced more business architecture discussions and enabled our business units around the world to hire a local contractor and get a small system on-boarded quickly through a lightweight process. .

We initially struggled from the skills transformation side, which went in two phases: the initial on-boarding to cloud systems and then systemic changes to the IT organization. At first, we needed deep skills on traditional platform areas like networking, security, virtualization, and monitoring. As we began on boarding business-sponsored applications, integration and service orientation was back in demand. We saw a constant demand after we had the first application of a business unit in the cloud, and identifying which others would logically follow, and determining the right sources of data on-premises or otherwise. We were used to having all these assets close to each other in our data center and not having to worry about latency (or inefficiency, or even tight coupling) between applications in a domain. It required us to approach problems differently. We, of course, had seen this coming in some of the SAAS applications like outsourced HR, and VoIP but those had been atomic moves of single systems to the cloud, not an entire business process with tens or more interdependent applications.

As we moved more of our applications to the cloud, our traditional infrastructure teams did dramatically reduce in size. We didn’t just lose those folks but developed cross-training for new roles in a Cloud focus world. Many of these roles simply didn’t exist in the old world. Many of our infrastructure folks after their initial concerns were actually eager to take on roles less “under the gun”/reactive. They were “freed” of their previous shackles and were able to provide more direct assistance to business units. When they began to see their impact on the company, they really began to buy-in. Within our architecture team, the same transition happened, and we grew our business architecture skills dramatically in order to really consult with the business units on multifaceted problems. We began to quickly identify different ways for customers to work with IT instead of the previous interactions which were much more “our way or the highway”. We began to add value and enable innovation instead of slowing down the very groups who were trying to improve our company.

In conclusion of this note to our former selves, the cloud ended up being a good thing but not for the reasons we initially thought. We used the technology change to fix some of the business engagement issues that had previously minimized IT’s effectiveness. It’s not an argument or negotiation with the business anymore – we don’t have to justify ourselves by obscurity or arcane terminology and process. The business sees directly what resources they use – in the “lite” method or full support from IT – and we plug in much more seamlessly with business objectives and work as one team with our business stakeholders. That team is differently skilled and certainly smaller, even as we move to a global data center model with a larger portfolio. Looking at the decision to move 25% to the cloud, we still have a core of on premise hosting for certain types of work and we probably move 5-10% of systems back and forth between clouds. Different workloads still make sense in different environments; when we do build, we have an easier way to leverage PAAS standards to provide for eventual architectural aspects. We don’t really track that “25% in the cloud” today; with all the business-sponsored systems, we’re okay with not even fully managing the whole corporate portfolio. What we still track is the value IT is providing and how many systems we end up working on versus ones we have the business do on their own. Distributed IT – where IT is not the only one doing IT, where we have business units running at different speeds and able to come to us as a partner, with us having different levels to engage at, and, consequently, opening us up to the next level of driving overall P&L – is the world we live in today.

[1] Per NIST classifications.