A recent study by McKinsey & Company, for example, found that many companies’ cloud investments have not helped them to fully reach their transformation goals.
At least part of the problem is that digital transformation isn’t about any single technology. Digital transformation isn’t per se about launching more mobile apps or migrating to the cloud or leveraging machine learning or most of the other finite things people associate with it.
Digital transformation can include all of those things—but the point isn’t any one project or even any combination of projects; it’s to achieve an ongoing state of IT agility that lets an enterprise continually adapt to changes in customer preference and marketplace dynamics.
To be clear, achieving a state of IT agility does not in and of itself transform business outcomes—but as we will explore in this article, it is a precondition for creating the leverage to create transformative business outcomes. As agility improves, so too does an enterprise’s ability to increase efficiency; evolve how it interacts with partners, suppliers, and customers; and make money in new ways.
This agility starts with IT architecture. This doesn’t mean cloud vs. on-premises. Rather, it’s about the ease and agility with which businesses can leverage and recompose their proprietary capabilities for different purposes.
Digital transformation requires achieving an ongoing state of agility and responsiveness
All enterprises have valuable digital assets, whether data or functionality. But these capabilities are only strategic assets if the company can do things with them—that is, if the capabilities can be securely leveraged, reused, combined, and shared with partners, all with little friction.
This means it’s not always important where a service sits—in the cloud, in an on-premise server, or in both through a hybrid configuration. Rather, what is often more important is whether the enterprise can move the service to another environment if it becomes advantageous to do so.
Likewise, it may not be all-important that a mobile application includes certain functionality—what’s all-important is how easily that functionality can be reused or leveraged for a new purpose in the future. And so on.
This is a significant change for many enterprises, scores of which are more accustomed to monolithic architecture styles in which functionality within an application is tightly-coupled. This approach makes it difficult to update an application without breaking it or to use a single piece of functionality within the application for new projects. It also makes it difficult for developers to work without impacting one another, limiting their overall speed, autonomy, and ability to introduce new digital experiences to customers.
The key to agility, and to the transformative business outcomes it can enable, is to decouple these kinds of dependencies.
What does an agile architecture look like?
Rather than building monolithic applications, digitally-savvy enterprises are increasingly building small, single-function microservices, and then assembling numerous microservices to create applications and digital experiences. These microservices decouple functionality from the application, and because each is independently deployable, developers can work without getting in one another’s way.
This enables a shift from large, plodding development teams to smaller, faster, more independent teams. These parallel development teams can more quickly build and release new features and experiences, learn from them, and rapidly iterate, increasing the enterprise’s overall pace of innovation.
Developers have to be able to access these microservices, however, which brings up the role of application programming interfaces (APIs).
The role of APIs
APIs decouple back-end complexity from front-end development, abstracting that complexity into an interface that developers can use for new applications and experiences even if they are unfamiliar with underlying technical minutiae.
This not only facilitates the sharing of microservices across teams and with external partners, but can also more generally inject agility into a heterogeneous environment of different systems and technologies from different eras.
An enterprise is unlikely to decompose all of its monolithic applications into microservices, for instance—but it still may need to connect those older applications to newer technologies, a use case for which APIs are perfect.
A loosely-coupled architecture oriented around containers, APIs, and microservices can, when properly managed, make it easier for enterprises to leverage their digital assets.
Microservices are often associated with containers, which raises another opportunity to generate agility from modern architectures. Containers decouple applications from both underlying hardware and operating systems, which is a meaningful advance over virtualization techniques that only decoupled the former.
This can unlock many benefits. When developers write containerized microservices, for example, they don’t have to worry about including code for policies, as those can be rolled out en mass to the shared operating system resources at the container level.
Containers also allow for a degree of agnosticism about what kind of hardware services run on, meaning enterprises no longer have to deploy multiple servers for multiple applications and can more easily move services between environments, such as from one cloud to another or from on-prem to a cloud.
The importance of management tools in an agile architecture
Modern IT architectures let developers use digital assets more modularly, increase interoperability among different systems, and increase software portability—but they also significantly increase complexity. This complexity means that beyond containerized microservices and APIs themselves, management tools are an important piece of an agile, loosely-coupled approach.
For example, to keep customer-facing services online, an enterprise may have to orchestrate thousands of services, many of which may be hosted in different places. Management tools need to automate service-to-service communication, as it is too complex to rely on human operators, and should provide consistent, unified, holistic views of API and microservice usage across environments.
Similarly, if an enterprise wants its developers to make the most of microservices and APIs, it cannot encumber them with heavy governance processes, which means it needs ways to provide self-service while maintaining control over who is using its assets; maintain comprehensive visibility into how assets are being used; and create automated responses and alerts for operations and security teams if anything goes wrong.
How agility fuels business outcomes
There are deeper technical weeds to wade into, of course, but the above overview shows us how a loosely-coupled architecture oriented around containers, APIs, and microservices can, when properly managed, make it easier for enterprises to leverage their digital assets.
This leads to the final issue—turning this IT agility into opportunities to grow the business. There are many ways this agility can manifest in a business strategy, but ecosystem participation is one of the most exciting and instructive examples.
APIs make it easy not only for a company to recombine its own APIs to make new digital experiences, but also to combine their APIs with those of partners. Many enterprises use mapping and navigational capabilities in their applications, for example, but most of them don’t build these capabilities in-house—rather, they combine third-party APIs, such as Google Maps or Google Directions, with their own technology—a store location API, perhaps.
In fact, many of today’s most immersive customer experiences are not produced by a single company but by many companies’ services coming together through APIs to offer the right content or options at the right time.
This means that rather than shouldering the top-to-bottom cost of building and maintaining the infrastructure needed to attract customers, as is often required in the physical world, a business can use APIs to insert itself into the digital transformation contexts where consumer interactions already occur or leverage partner APIs to augment internal capabilities.
How major businesses are leveraging APIs
For example: not so long ago, a major U.S. ticket sales and distribution company’s business revolved around phone sales, physical ticket booths, and first-party apps as its primary sales channels. All of these are approaches in which the company carries the responsibility of attracting customers and shoulders the most of cost of expanding its reach. But in recent years, the company has expressed capabilities such as event discovery and ticket purchasing as APIs, allowing its core business to be inserted into digital experiences where would-be customers are already assembled, such as social media platforms.
Or consider how Pitney Bowes has evolved from the physical postage meters of yesteryear to shipping and logistics APIs, such as those for looking up known addresses or finding the cheapest shipping cost, that can be implemented into a range of partners’ applications and exposed to those partners’ customers.
Look at how AccuWeather, by selling access to its APIs through various subscription models, has monetized its data and expanded the range of developers innovating with its intellectual property.
The examples go on and on, but the point is—these significant evolutions in the ways these enterprises operate weren’t just based on finite mobile apps or cloud migrations but rather via decoupled architectures that facilitate ongoing agility while maintaining control and manageability.
Think of digital transformation less as a technology project to be finished than as a state of perpetual agility, always ready to evolve for whatever customers want next, and you’ll be pointed down the right path.
Learn how to decouple infrastructure, services and teams. Get our free report on best practices for developing a successful hybrid and multi-cloud strategy.
For a deep-dive discussion on APIs and what lies ahead, check out this video interview with Amit Zavery.