CIOs wish for simpler ways to wrangle data and experiment with business models – but change remains hard to scale. Also, it may be time to stop chasing “alignment.”
SunTrust CIO's formula for speed relies on cloud, DevOps
Technology has never played a more critical role in the financial services industry. To keep pace, it’s imperative that CIOs position their IT organizations to move faster and better serve their clients. At SunTrust, we’ve been hyper-focused on changing the way we deliver products and technologies to our clients and teammates. We strive to be closer to our clients and be more precise and agile around the problems we’re trying to solve for them.
To do this, we have pioneered a concept we call the Business Accelerator in IT. Our Business Accelerator stack is made up of five layers: cloud, modular architecture, DevOps, agile development, and design thinking. Each plays a critical role in allowing us to better serve our clients and to move faster.
Here’s how we’re approaching the Business Accelerator, and some lessons we’ve learned along the way:
Many organizations today are improving their use of cloud technologies, but too much of the focus tends to be on development, testing, and infrastructure. Cloud in the context of our Business Accelerator is focused on real workloads and leveraging cloud technology to more actively manage utilization and provisioning. The ultimate goal is to be able to use platforms and services when we need them rather than build out that capacity.
To get there, we had to examine our core assets in order to understand our ideal migration path to the cloud. Like many other financial services organizations, for us, that meant looking at the risk associated with our platforms and factors such as business continuity, resilience, and key financial applications. This analysis enabled us to determine which of our workloads could exist on a public cloud or multiple public cloud providers, which needed to be on a Platform-as-a-Service cloud provider, and which workloads we didn’t want to have anywhere but within our own firewall and manage from a private cloud perspective.
Defining the method, framework, and migration thought process is where we are today, and we’re making a lot of progress in some areas and having good conversations in others. But what’s important to note is that this can’t be driven by a technology-only team. It has to be a combination of business and technology stakeholders – including product, operations, strategy, legal, risk, audit, and data governance.
I’m not saying you need 5,000 people to make every decision as it relates to cloud. But in order to build the right framework, you need to have the right conversations from the outset. For us, that meant bringing all of these people to the table to kick off our strategy and work through initial questions.
A lot of organizations today are moving away from the traditional point-to-point solutions and services-oriented architectures (SOA) toward microservices and APIs. But, in order to make that transition, you really need a more modular way of looking at the overall architecture. That’s where modular architecture comes into the Business Accelerator stack.
If you’re a company that’s been in existence for many years, you undoubtedly have legacy platforms, systems, and applications. That is the case for SunTrust, and it created some complexity in terms of moving toward modular architecture. We had to take into consideration the business value of these legacy platforms, the various architecture roadmaps across all lines of the business, and integration concerns.
In other words, it’s easy for a bunch of architects to draw on a board and say, “Here’s what a modular architecture looks like.” The hard part is making the migration happen in conjunction with existing programs and projects that are delivering business value.
But, for us, figuring this out was important. Traditional SOAs are centrally managed and governed, and after a while, they become bottlenecks. As soon as you move to APIs and microservices, you eliminate those bottlenecks – the governance can become much more decentralized, and that allows for a lot more flexibility. That’s the heart of the reason why we want to move towards modular architecture.
DevOps really just means connecting the development and the ops teams together in a more meaningful way, but it seems everybody has their own idea as to what that should look like. I think, fundamentally, DevOps is about talent. It doesn’t matter if you have the right tools and the right methodologies. Of course, they are important, but you also need the right mindset across teams to effectively collaborate early in the delivery life cycle, and the right framework under which you can have those conversations.
For too many years, people have been sitting in silos. It takes real effort on both sides to begin understanding and work together in a more agile and iterative fashion, and all of that needs to happen before you can even think about calling your approach “DevOps.”
We tackled this culture change with pilots. We started three pilots at varying levels of what might be considered “true DevOps,” and we’re learning from those pilots along the way. One of our Business Accelerator pilots recently went into production. The teams have really learned how to work together, and as a result, we’re breaking down the cross-functional silos within IT.
We’re also learning what DevOps means for our organization so that we can work toward meaningful goals – goals we couldn’t have developed without piloting, testing, and learning. For example, we’ve discovered that it’s not just the infrastructure and the application development team that benefit from DevOps. We’ve identified security and access management benefit as well. We’ve learned not to get too hung up on the ultimate, 100 percent purist view of what DevOps is, but rather put our focus and energy into changing the culture and driving outcomes.
Agile development is not a new concept for us. In fact, we’ve had agile trainers within the organization for 10-15 years. But we needed to rewrite our methodology for agile so that we could expand it more broadly throughout the organization. We needed to remove the shackles around our agile teams.
The battle that we ran into was that our team was effectively doing agile build work with scrum masters, multiple threads of work, parallel iterations, and so on. But they were surrounded by a layer of what I’d call traditional waterfall watchers, checkers, and auditors. Control functions are typically more waterfall-oriented. The hard part for us was figuring out a way to break through that enveloping layer of waterfall and more effectively tie “agile” into things like release management, deployment, and integration testing. It’s got to be the full stack, and that’s why agile development must be part of our Business Accelerator.
Design thinking is really at the core of our Business Accelerator. It enables us to look at problems from a client-end viewpoint and come up with the right solutions from the start.
The real challenge is that both business and technology need to change their mindset in order to start using design-thinking principles. They need to ask: What are the real problems we’re trying to solve? What are we trying to accomplish? What options do we have? What are we currently using such that we can make incremental changes rather than try to find 100 percent solutions and thereby insist on writing large requirements documents? You also need people who deeply know the business, deeply understand the client and the current technology involved in these interactions. Again, it’s more about talent and culture change than anything else.
As a full stack, the Business Accelerator is helping SunTrust keep pace with technology, become more agile, and better anticipate client needs. Along the way, it’s also helped us to identify critical talent and culture issues standing in the way of our success. I’d encourage other CIOs to consider incorporating all or as many of these components as they can into their IT strategies moving forward.