Anew breed of citizen integrators is on the rise. They are bubbling up as a result of the growing self-service trend in IT. We know how effective self-service can be in the case of Cloud. It allows business users to procure infrastructure and capabilities with a single click. Now, the trend is expanding to data and application integration. Business users are taking integration into their own hands. For organizations where IT departments are swamped by non-core requests from Lines of Business (LoBs), this can provide much-needed breathing space. Unfortunately, in many instances, it is also setting off the alarm bells. These citizen integrators are creating jerry-rigged solutions over which IT has no visibility and control, creating a minefield of future problems. It is in the interest of IT and the enterprise to find ways to automate the integration and empower citizen integrators —but with a healthy degree of oversight.
Analysts predict that citizen integrators will be an unstoppable trend. There are two convincing reasons for this. First, business users know their data, they are experts in business processes such as Order to Cash and financial reporting, they understand business needs, and many who are technically savvy are already using SaaS applications. Second, applications in the digital age are expected to change rapidly, and IT will not be able to keep pace; there will be no option other than to provide automated integration self-service.
A good problem to have
In other words, citizen integrators are both—a problem and a solution. How can organizations maintain a balance between the two to fuel agile innovation and turn it into a good problem to have? How can an enterprise ensure that internal Integration Competency Centers (ICCs), COEs and citizen integrators are empowered to take over from third-party System Integrators (SIs)? What are the building blocks to integration that enable citizen integrators?
The logical view is to look for tools and features through the user’s lens, taking into consideration the goals of each user. Users can be divided into four categories: specialists that address the needs of central IT, ad hoc integrators focused on LoB applications, business users in a hurry to access applications and data for day-to-day operations and faster time to market, and digital integrators addressing digital business projects.
A GUI for good outcomes
Among the four types of users, we have already seen that it is the business user—the citizen integrator—who needs immediate attention in a rapidly changing technological environment. We believe that citizen integrators would benefit most by providing them with simplified designer GUIs, which can be used to create integration workflows. The system would also support built-in monitoring and process adherence (including DevOps).
A broad example sheds light on the simplicity of the approach. Assume that an e-commerce portal aggregates consumer product vendors. Typically, such a portal has a variety of APIs that allow vendors to plug capabilities such as viewing transactions, accepting customer orders, getting customer feedback and deploying product return processes. Can a business user of the portal change any of these components without impacting other components? In the normal course, such a change would require the business user/analyst to write a requirements document, bring in front-end developers who would write code from scratch, get integration teams to design the integration along with the system owner – all this while, the clock would be ticking.
Inside the integration tool
There is a way to cut through all this: central IT provides assets that need to be exposed, a business user or developer knows how to use these and leverages a GUI to complete the integration between assets. The GUI generates the code for integration workflows. The code follows enterprise integration patterns identified for customer scenarios on, say, Apache Camel. An integration platform such as Apache Kafka can be used as part of the integration framework to complete the integration. The entire microservice is in ready-to-use containers and moves to production.
The integration tool that consists of data transformation maps, business rules, connectors, and templates—the building blocks we spoke about earlier—should not be too restrictive or too liberal. If they are restrictive, they will often need intervention from IT, defeating the purpose of the tool. If they are too liberal, it will lead to chaos as citizen integrators will experiment beyond the limits of enterprise tolerance. The tools must be just right so that the connectors and templates can be adjusted to meet custom requirements.