A featured contribution from Leadership Perspectives, a curated forum for enterprise technology leaders, nominated by our subscribers and vetted by the CIOApplications Editorial Board.
Red Hat
How to Stand Up an Agile Integration Infrastructure Using APIs
As competition from all corners heats up, IT leaders who have made only limited changes to the “old” ways of doing things must start to think differently. They must strive for agility too, getting the most they can out of existing resources—often times spread across hybrid environments encompassing multiple data centers and disparate public cloud environments—while at the same time ensuring their existing systems continue to deliver value.
These IT environments can be incredibly complex, making it difficult for CIOs to know where to invest. To make this all work, organizations need to be able to accelerate and scale application development, make it easier to integrate system assets regardless of what or where they are, and enable apps to run in environments that makes the most sense at any particular point in time. With a flick of the wrist, they must be able to migrate apps back and forth in these hybrid environments.
The old ways of doing system integration, for example, using Enterprise Service Buses (ESBs) as a central point to tie one system to another, are no longer enough. ESBs don’t increase the speed at which the business can adapt systems and processes to modern digital requirements. CIOs are keen to have a better way to deal with the real meaning of business transformation—that is, preparing their IT ecosystems to support ongoing change. Looking at the state of their infrastructures now and envisioning where they want them to be soon. This is prompting many CIOs to consider three critical ways they can boost their agility: containers, APIs, and distributing integration. We call this combination agile integration.
In an agile integration infrastructure, centralized integration is replaced by distributed integration, using independently scalable microservices that typically are packaged into containers and that connect with each other via reusable APIs. REST APIs provide uniform and easier connectivity to accommodate data requests coming from a front-end interface to an internal system, making transactions, and getting data back to the interface from the back-end system. These APIs can be reused by tens or even hundreds of software clients for a range of purposes.
The Enterprise Embraces Change
The move to distributed integration and containers opens the door to using the entire hybrid cloud estate to run enterprise software.
Reusable APIs also are the foundation that makes it easier to evolve existing back-end systems, because they streamline building new software more quickly in relationship to these previously immutable assets. Now, building a customer-facing or workforce-saving website or mobile property that requires resources from multiple back-end systems isn’t the nearly insurmountable hurdle it once was.
The move to distributed integration and containers opens the door to using the entire hybrid cloud estate to run enterprise software
It’s a significant change to the enterprise when agile integration capabilities can be “dropped into” the infrastructure to enhance and accelerate the creation of new services. That change is complemented by the APIs themselves adapting over time, with these evolutions used to build new services, and by container creation becoming accessible to anyone developing software, at least for testing purposes. It’s a matter of thinking of containers, distributed integration, and APIs as capabilities within the organization that can be spun up at any point by anyone who needs to do it. Tooling for automating these capabilities ultimately will be critical to the success of agile integration.
Even in its early stages, though, building the APIs essential to agile integration can create more opportunities for digital teams to feel that they are real contributors to the organization. That allows developers to take ownership of the APIs they generate, and indeed treat them as products for users—who they should start to think of as their customers.
That’s what happened at a large Asia-Pacific airline, a Red Hat customer. It was having a hard time holding on to talent due to constant complaints and frustration by users over delays in delivering new services because of the lack of reusable integrations. Things changed when APIs became part of the picture. Now that APIs are seen as an “owned” product by digital teams, they are very conscious of documenting each one for their customers; of providing a roadmap description for it about how long it will be supported and when it will change; and transmitting how notifications related to the API will be handled. That creates a more collaborative relationship between API owners and users, and it speaks to building a healthier computing environment by acknowledging the reality of ongoing change for all participants in the enterprise.
What’s next
Right now, we see that CIOs have great interest in the potential of agile integration, but there is some concern about the costs of taking this approach. To manage this, a good starting point is to use agile integration as a blueprint design template for few projects, already on the roadmap. Once honed in that environment and the benefits realized, it can be rolled out to other activities.
Those benefits should include getting greater development efficiency without having to expand the team. With these individuals feeling that their work resonates throughout the enterprise, they’ll likely be happier at their jobs and more productive. Taking on an initial project or two should also demonstrate how APIs which open up silos to digital teams via more flexible, robust, visible, and accessible interfaces should create a less fragile IT environment.
By starting with a few projects, even the initial benefits realized by the organization are likely to convince CIOs to bring all the components together in the end.
