In my article on redefining integration, we saw, from the technical point of view, developments of integration driven by digital. However, working on it by focusing only on technique would be a serious mistake. Between the diversity of needs, users, skills, and technologies, a single integration service center is no longer enough, and cannot be scalable easily.
Thus, it becomes essential to rethink its organization and its way of carrying out integration.
Of course, the integration services center will survive by continuing its historical work but will cross its own walls to meet the users. All too often, I have come across what I call "slave integration projects." These projects change direction, impose choices contrary to good practices, and do not master well the stakes of integration with all the corollaries that it can produce. It is, therefore, obvious that some changes were needed.
Result! Very often, there has been a link between the "integration" team and the "architecture" team, governed by a methodological framework and a set of rules. We finally had an ally to projects we wanted to help as best we could but who sometimes did not understand it. This has had benefits such as better integration of projects and its associated good practices. However, this did not eliminate the cumbersomeness and perception of the added value of integration.
Besides, have you already calculated the ROI of your integration project? If you start thinking about it, it is better to stop right away, so hard is the task. The time to calculate it finely could cost you your ROI. So, we have to go even further and sell integration (that is to say, to become a product manager!).
This product manager approach already exists and perhaps even in your company without anyone being aware of it. Indeed, the logic of the management API is a logic of productization of integration. The entire underlying project methodology is based on productization. Identifying upstream the future business needs but also ensuring the "profitability" of the implementation in advance of phase is already productization. In short, this product management approach is increasingly influencing integration projects, and I invite the projects concerned to take an interest in lean product management, which explains how to quickly and efficiently achieve an efficient and profitable product.
To be interested only in productization is not enough! We need to sell and train on a large scale. Indeed, one of the major interests of API management solutions is to be used by many different players, from business users to developers. Business people will increasingly make themselves their own integration with simple iSaaS tools like Zapier, Microsoft Flow, Tibco Simplr, or a more evolved one such as Moskitos. It will, therefore, be necessary to train this population so that it can take over these tools and interface with Legacy IT.
It will also be necessary to keep up with the pace of developers who, with a DevOps factory, are increasingly aware of the slowness of an aging integration platform, and quickly want connectors, libraries, and APIs. They are also the only ones able to follow the APIs they make available. In the same way that we will have to train business users, we will have to train developers in order to be able to scale organization effectively. It is necessary to facilitate them on the task of interfacing but also leave them the responsibility on their own part of the integration.
The role of the integration teams will therefore change, and perhaps much more rapidly than expected. Integration teams must:
Think about integration upstream of the needs.
Facilitate the work of business users and developers by proposing "turnkey" solutions.
Train concerned actors.
Learn to delegate the integration to be able to follow the digital frenzy.
This policy has been applied internally at Adobe lately. In just 10 months, 400 people (business users and developers) were formed and 600 integrations and 200 APIs were developed.
It's time to rethink its integration!