Application architecture and integration requirements have undergone a sea of change over the past few years. The number of end-users, connected devices, and applications are increasing exponentially. All the while, enterprise data resources, systems of record and computing infrastructure are pushed out to an array of new cloud-based services that are connected – yet separated – by an unknown network. This unknown and unmanaged network resource is of course the internet, and it sits at the center of today’s app architecture.

The internet has evolved faster than anyone could have imagined – back in 2000, the total number of network users was only 400m. Today the internet has over 3.3 billion users. Furthermore, a single app today handles more traffic than the entire internet infrastructure did just a decade ago. Considering these stats, it’s easy to see that we have an ever increasing reliance upon the internet in our day-to-day lives, and as a result, we’re facing issues of scale. With this in mind, it’s also easy to imagine that some integration paradigms, systems architectures and app technologies of the past may not be the best choice for today, and certainly won’t scale for the future.

Traditional enterprise IT is reliant on monolithic solutions from a small number of vendors. Until recently, there was little need for these solutions to interact with other systems, never mind with the outside world. Even over the past three to five years, most organizations have been able to design and architect for well-known IT problems and tightly controlled application integration scenarios.

But the world of “traditional IT” has come to an end.

Today, businesses, partners, customers, and employees all demand more flexibility and capability.

Rather than a tactical approach to integration, a broad enabling fabric will deliver the breadth of capability users’ demand with the performance, scale and resilience they expect. So when it comes to IT infrastructure, it is no longer viable to simply invest in products and services that cover only the requirements of today. Architects, in any environment, must think about creating a sufficiently generic layer of infrastructure that can be applied to many different projects and serve the unknown requirements of tomorrow.

What Can be Done?

Systems need to be reactive. Reactive systems are inherently more flexible, loosely-coupled, and scalable – making them faster to develop and easier to change. This allows developers to build systems that deliver highly responsive user experiences with a realtime feel, backed by an elastic and resilient application stack. One huge part of building reactive systems is realtime messaging.

Across much of today’s application integration, there is no ability for systems to react in ‘realtime.’ To explain this better, for example, system A will ask system B if new data is available based on a set of query parameters. A request is made; a response is given (polling or long polling). However, rather than polling back-end systems for changes, realtime messaging can be used to create responsive, event-driven applications. This allows you to scale your applications, without adding unnecessary load to the back-end. Integrating realtime messaging seamlessly with modern development frameworks for the web (Angular, Meteor, React, etc.) means users see data changes as they happen. This means applications are no longer delivering “point-in-time” data, and instead, focus on realtime, event-driven, responsive, engaging data.

If you would like to read more about reactive systems (building systems that are responsive, resilient, elastic and message-driven), data efficient messaging and its uses, and how a ‘reactive data layer’ could transform your business, read our latest whitepaper: “A New Approach to Enterprise Architecture: Reactive Systems”. If you like to read more specifically about a ‘reactive data layer’ check out Ross’s blog: “Migrating Towards a Reactive Data Layer”.