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:
Cloud
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.
Modular architecture
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
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
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
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.
Comments
Interesting overview on the convergence of; Cloud, DevOps, Agile, Design Thinking, and API's.
It's all about cultural transformation and enterprise adoption.
Same message back to the Yourdon/DeMarco SA/SD methodology days! Yes, I'm old.
The concept of public, and private cloud environments, coupled with loosely coupled singularly purposed microservices, do offer some very distinct advantages. Leveraging services that have been well tested, well defined, and proven to live within secure, yet accessible environments, certainly cuts down on the cost associated with development, deployment, testing, maintenance, and on going support, However, seeing either the cloud and/or microservices as a panacea for every problem domain, could also prove be a grave and very costly mistake.
We have all been subject to marketing trends and sales hype within the technology space They all had widespread industry backing and they certainly had the marketing hype and case studies to support them.
Remember when the fat client /thin server was the answer to reducing our corporate server rooms and decreasing our needs for ever increasing bandwidth issues? Remember when Corba was the answer for heterogeneous program to program communication? Remember when EJBs would make every other form of RMI and persistence mechanisms obsolete? Remember when Ruby on Rails and later PHP, was the answer for all RAD Web centric application development?
Enter the new marketing child and hype hyperstorm for this and the coming decade. The cloud makes virtualization an afterthought. The cloud allows us ubiquity. The cloud means we can centralize our knowledge base to those whose focus is fixed primarily on specific tasks and therefore have staffs that become experts within their respective domains The cloud and cloud based services allow us to focus more on our core business and less on the perfunctory task requisite in self hosted environments. At least that's the promise.
Yes, it all sounds wonderful, just as did every other high profile technology revolution before it. The cloud and cloud based services certainly do have a purpose, and if used reasonably and rationally, can certainly help ease some of the day to day burdens and help with cost constrained budgets. Data sharing can certainly facilitate machine learning and help your business and the world become a more unified and globally accessible place. High availability and redundancy have also been important as well as costly and the Cloud can certainly be applied to answer some of those questions and concerns.
But a cure all? Cloud services and their microservice cousinss can bring a host of problem domains that are just as real as the problems that they are meant to solve.
What happens if/when most your entire business software is built and controlled on someone else's software stack? What happens when most or all of your infrastructure is controlled by relatively few players? How much will customization cost be? Will those cloud services control your business or will your business be able to control them? What happens to your ability to innovate when much of your business operations are subject to a third party's direction and control?
These are just a few of the questions that need to be asked and considered before diving in head deep. Take a logical approach, -- step back and evaluate. Yes the cloud, cloud based services, and building out microservices will no doubt be the right solution for many of your business goals and solving many problem domains. But they may not be the right answer for others and could wind up making you an unwilling hostage and turn you into a follower rather than a leader.
Just some things to consider.