Scrum for integrations
Scrum is a framework that centers around:
- – roles (scrum master, product owner, etc.)
- – events (sprints, planning, review, retrospective, daily scrum)
- – artefacts (product backlog, sprint backlog, increment)
Scrum is intended to increase agility. One of its core notions is to ‘fail fast and fix’.
For integrations, I doubt if Scrum outperforms waterfall methods. Integrations on existing applications are normally clearly specified, without fundamentally changing business needs on the fly. Usually, it is the context of an integration that is your challenge:
- – multiple teams
- – lack of documentation
- – original developers no longer with the company – often calling for woeful reverse engineering
- – functional and technical people in close interaction – likely with a big wall between them
- – nitty gritty analysis how to cross the bridge between two different systems (data mapping)
Here, Scrum won’t contribute much to your agility. Such a context is often the result of many years of short term decisions and neglected maintenance.
So, the first point to make is that Scrum’s relative importance for integrations is lower than average.
Non-automated deployment
Monolithic applications are not agile when it comes to rolling out bug fixes, patch sets or releases. First of all, there is the procedural aspect: change management procedures tend to be a real plague, especially in larger organizations. As for the technical aspects, deployment on DTAP environments takes time, as well as the associated testing. Without automation, such manual tasks can easily take weeks, especially when the test capacity is insufficient – as is so often the case.
Therefore, the second point to make is that traditional, non-automated deployment can be a real hassle, seriously hampering your agility. This is especially true for integrations, normally involving multiple parties. In practice, monolithic applications are upgraded at a low frequency. Without any further, this applies to WSO2 in much the same way. However, that’s not the end of the story!
Automated deployment for integrations
So, what does contribute to the agility of your integrations? An automated deployment pipeline in your integration platform certainly does. It speeds up the deployment of platform changes and integration artefacts, while improving consistency. And indeed, speed and consistent quality are critical elements to your agility. Over and above, an automated deployment pipeline supports an important agile goal, i.e. to reduce handovers – each human handover presents a risk for error.
Finally, a consistently delivering deployment pipeline creates confidence, offering the opportunity to cut change management bureaucracy.
Automated checks at deployment time
When considering automated deployment, the following elements deserve attention:
– automated build creation after checking in bug fixes, patch sets or releases, e.g. in GitHub
– automated deployment of a build to the proper DTAP environment
– a dashboard that makes the deployment process and the platform health status transparent
– automated health checks, for example:
— accessibility of WSO2 components
— subscription and consumption of API’s
— Identity & Access Management, Single Sign On, token handling
— availability of end points
— proper encryption
— log file collection
Such checks reduce your risks at deployment time.
Integrations and agility
Today’s world is changing fast. For integrations, an automated deployment pipeline ensures that your integration platform remains up-to-date. And automated health checks help to detect errors in the process. As such, I believe that this contributes more to the agility of your integrations than Scrum will ever do.
Summary
In this blog, I have made a case that automated deployment contributes more to integration agility than Scrum. Integrations are often clear cut, in which case the benefits of Scrum are less evident. However, automated deployment provides direct benefits, helping you to react faster to market demands. To me, automated deployment is like a pear that I prefer over the more commonly requested apple called Scrum.
In this context, it should be noted that the use of Ballerina and microservices holds a promise to improve agility as well. We’ll cover that in another blog.
Yenlo Connext
Coincidentally, you may want to check if Connext incorporates automated deployment and automated health checks. Connext is Yenlo’s cloud-enabled, managed middleware Platform-as-a-Service, based on the open source WSO2 product. It’s a stateless integration platform, using auto-scaling and auto-healing, with a comprehensive dashboard, an automated deployment pipeline and automated health checks. If it is secure enough for a German bank, why not for you?
