More and more organizations have adopted APIs as a major part of their integration platform. Integration is becoming an increasingly bigger part of the software development process, there is even studies showing that over 50% of development efforts will be integration related as early as 2020.
With this increasing need for integration and increasing time spent developing integrations the old way of working with a central COE managing all work integration related has to be kicked out the door. Integration needs to go agile.
So what does it mean to be integration agile?
Distributed integration development
As mentioned earlier the concept of a COE doesn’t scale very well with the increasing amount of efforts put in to integration, the workload needs to be spread out. This can be done by pushing the responsibility of the integration to the development teams.
Every team needs to hold up its own pants and take responsibility for their integration needs. Some teams can be very reluctant to this since this might cause them more work. They prefer the old way of working where they call the COE, order an integration and then sit back and relax for three weeks.
However do they really want this? It should be in the teams best interest to have as much control of their application as they can. What if the integration starts failing? What if the COE is super busy and can’t deliver in time and threatens the teams deadline?
The team needs to be challenged and we need to explain the benefits that they will get for taking responsibility for their own integrations.
If they still don’t want to do it, force them. Digital transformation requires strong leadership and we need to be ready to use both the carrot and the stick.
For more information on this topic and how you can organize your development teams WSO2 has an interesting concept called cell based architecture that you can read more about here. We also did a blog post about this recently.
The integration gap
So let’s say all your teams are on board and wants to start building their own integrations. How should they do it? We need something that’s cloud native, that teams can deploy and manage themselves and that’s easily scalable.
Just as we have seen the emergence of micro gateways we are also starting to see micro ESBs. This way teams can deploy an ESB that they can manage on their own, are close to their application, and can scale when needed. However this would force the developer to learn a DSL.
This might impose limitations to them because suddenly they cannot do what they are used to do with their favourite general purpose language, and this brakes the development flow. At the same time their favourite general purpose language imposes limitations because implementing common enterprise integration patterns can be quite hard and cumbersome. Meet the integration gap.
To bridge this integration gap WSO2 has introduced a new programming language called Ballerina. Ballerina is claimed to be a cloud native general purpose language with a lot of integration concepts built in as first class citizens. This means there is no need for third party dependencies for common integration scenarios such as managing XML and JSON payloads, and transformations between the two. It also has concepts such as circuit breaking and load balancing built into the language itself.
Ballerina has not reached a stable v.1 version yet but you can go ahead and try it out and learn more at ballerina.io. However introducing a new programming language is not a trivial task. Even if the language itself is a success and delivers what it promises there is a lot of competition out there.
Getting through to developers and convince them to learn a new language is perhaps even more of challenge than building the language itself. So if ballerina is a success or if the gap is filled by some other piece of technology or language remains to be seen.
With integration playing an increasingly important role in the IT landscape the way your organization works with integration needs to change. The old way of working with a central COE will risk to put a halt to your businesses digital transformation or at the best severely slow down its velocity. Integration should be an enabler for your business, not a disabler.