One day I was asked to draw how the applications we have are interfacing with other applications. It was a quite big task to come out with such diagram, but I managed to do it.

The diagram looks like this.

(of course, I need to remove the details)

When I presented the diagram, the most comments were about how messy the applications are.

I disagreed. Such messiness, in fact, should be EMBRACED.

Firstly, there is no application that can do all the functions that the organisation needs. An organisation typically uses different applications and integrate them at the back-end so that to achieve a good user experience across different applications.

When an organisation moves to the cloud, it opens up even more applications it can use. The integration between cloud-based applications (and also with Intranet-installed applications) would even be more pervasive.

With the advent of microservices and container, the integration would even more complex than typical application-to-application integration. A particular business function may be served by multiple microservices, each may call other microservices.

Microservices and container when combined with DevOps also introduces more complexity. If properly configured, a container can run in different hosting environment at different time, transparent to the user, but introducing a more (at least to what some people think of) another dimension of messiness (and complexity) as the service has no ‘permanent home’.

Trying to simplify the interfaces between applications would simply not work. What the organisation needs to do is to embrace such messiness with some measures to prevent chaos.

For a start, the organisation should put in place governance. The organisation should know what interfaces are being deployed, who is calling what, version, security, schema and which interfaces to be retired. This will also allow the organisation to better reuse existing interfaces, rather creating new ones.

However, governance itself is a rather tricky concept as may hinder application development. Governance implies set of rules that must be followed by developers otherwise there would be some kind of penalties. The scrum team may also see governance slowing down their works as they need to go through ‘review’ process. Some pragmatic approaches on governance needs to be applied.

The organisation may also consider to implement some systems, such as API Gateway or message queue to provide the layer of governance on interfaces. It also provides additional layer of security with the cost of additional complexity and reduced reliability as such systems may become a single-point of failure in the whole organisation.

Data governance is also important. An entity should have consistent data structure throughout organisation and across all applications. An inconsistency would simply create confusion, not only for users but also for integration. It would make interfaces more complex as application would need to transform the data to its own data structure. Intermediary systems such as API Gateway could used to do transformation; however it would simply move the complexity into such system and with more complex governance as there is a need to track the transformation logic.

</BH>