Today's organizations are in different places on the road to digital transformation. As businesses formulate their digital transformation strategy, there is much to be learned from IT leaders who have already begun their journeys.

To help us learn more about how businesses are modernizing their applications and infrastructure, we sat down with Thomas Squeo, CTO for Intrado, a global technology partner that offers cloud-based solutions to connect organizations.

How did your team acknowledge that digital transformation was needed? Where did you begin?

Squeo: Due to the scope and scale of our company (and that we acquired several businesses to build our portfolio), we had a range of technology solutions: from legacy monoliths to leading-and-bleeding edge solutions. In 2016, I was asked to explore how to modernize our internal cloud to make it as attractive as what we were seeing emerging in the marketplace. We started looking at how to make our internal infrastructure as attractive to our product development teams as the external environment.

In doing so, we were able to reduce friction from our teams by being able to provision infrastructure and move from inception to operations in a short period. We wanted an opinionated platform that could enforce and ensure the software development was highly efficient and highly effective and had an outcome-based focus.

Ultimately, we decided to separate the application decisions from the platform decisions. This gave us the ability to abstract not only in VMware vSphere and VMware NSX-T environments, but also look at how we put those environments into the big three clouds. We were able to run our platform, abstracted, over AWS, Microsoft Azure and Google Cloud Platform.

By the time we made significant pivots to a multi-cloud operating model, we made some business decisions early on for those applications that are running in our Google application service. We focused on our on-prem environments and those environments that we're going to leverage Kubernetes as a way of bringing them into a cloud-native operating model. We encouraged them to use public cloud in that environment. This had a bit of variability in our decision-making as far as how we manage not only our public cloud team but also how our platform teams interoperated with them, as well.

Where are you today? Have any results surprised you, in terms of value and opportunities?

Squeo: We've been able to get over 170 applications onto the platform at this point. We have line of sight into what we want to accomplish in the original business case.

Intrado acquired about nine companies since the original business case was submitted. Those portfolios, as well as initiatives that were spun up after the fact, are now on the platform.

We see the benefits around speed, stability, scalability, a more secure environment with a more predictable threat surface and, ultimately, the business of software economics—or we could largely classify under the savings tier.

We evaluate every application in the portfolio along those dimensions. We have a standardized set of metrics in which we can report the health of an application. It's very easy to be effective and costly, but we want to be both effective and efficient for what we consume.

How do you decide which legacy app to transform, refactor or retire amidst demands for new apps and systems?

Squeo: There was a legacy set of applications where we had to build a platform, product modernization and an end-of-life strategy. Out of the 400 applications in the first and last category, 160-200 were retired.

We then modernized the core set to be included in that go-forward platform. Thinking about those mainframe applications, the juice would not be worth the squeeze. Not every application is destined for the cloud in its current structure.

When we did our initial qualification criteria, we worked with the enterprise architecture team, technical leads and technical anchors and also brought in third parties from account teams. When we qualify those applications, they were validating or invalidating things, as opposed to looking at things from scratch. Each application is a set of discoveries. Many companies would come to us as a third party and offer a free analysis of the appropriateness to go onto the platform. After seeing how far downrange we were, some of the vendors that were more self-aware agreed that it wasn't a fit.

We're not early on in this journey. We're very far down.

Did Intrado need to make a significant change culturally and organizationally to make this massive shift?

Squeo: What I found in my career is that technology is rarely the problem. It's the people, personnel, culture and acceptance of risk. If employees don't have the competencies on day one, what is the path to either augment and supplement them or get the professional development necessary so that they can have both an intrinsic transformation and extrinsic transformation?

One of the core shifts that had to change for Intrado was the notion that we're no longer an operator-first organization. We need operators that think like engineers and act like engineers, not only for continuous improvement to the platform but also to incorporate techniques that serve as guidelines. We had to be able to build swim lanes to operate in while they were building software.

Next, we built a culture of trust. That gave employees the latitude to be successful without assuming the worst.

I view the people, the process, the culture and the competencies. Then, I view the technology we're using to solve the business problem. Thinking at scale, it's important to look at the span of control and centralization to be sure the right people are reporting upward—and also observe how they work alongside each other.

How has this new operational model impacted the way you look at enterprise security?

Squeo: We focus on how to bring security as "far-left" in the value chain as possible.

Security is broad and evolving and organizations have to be able to maintain a good posture. We had to look at our practices and learn to build our software to ensure that the threat surface is minimized at the point of inception and delivery. Then, we looked at what happens as the software is deployed, operationalized and monitored through logging and observability.

We look at how to instrument automated security testing, best practices, post-deployment testing. We can rotate, repave and redeploy environments regularly to reduce the amount of time a bad actor can sit inside a system.

We are not a DevSecOps shop at scale, but we aspire to be. We look at the capability models around best practices and set ourselves up to have the most mature and capable teams that are considering security at the point of inception, as opposed to after something's operationalized.