Application or enterprise architecture has become a fast moving world of late, with many voices talking loudly and often about technology choices, integration patterns, standards, etc. Yet throughout all this noise, one simple rule prevails – you must limit coupling between services, and especially between frontend apps and backend resources.

Unfortunately, we often fail to remember this rule when building applications. For many developers – and organizations in general – time pressures, competitive situations, and other market forces mean that best practice takes a back seat and we are forced to just “ship it!”. While there is no shame in this, we know that technical debt mounts behind the shortcuts taken, and onward feature development becomes increasingly expensive and difficult to maintain.

Architecting for the future

The reality is, many of today’s applications – whether Web or mobile apps – are constrained by the poor choices made under the expectations of time-to-market. But it’s now 2016. Digital product expectations and the associated application requirements are even more grandiose. Apps simply cannot be delivered cost effectively unless a more considered approach to underlying architecture is enforced from the get-go and reaffirmed across existing projects. We know that most integration requirements are no longer confined to the controlled world of enterprise IT, but instead extend out to a multitude of cloud services, mobile applications and increasingly Internet-connected devices.

A new, flexible, reactive architecture is required.

Decouple Everything!

As we said, loosely coupled services and clear functional boundaries are the rule of thumb regardless of technology fashion – and this applies now more than ever.

1. Any integration model that assumes or imposes that one service know about another, or respond synchronously to another is often a sign that you have imposed unnecessary coupling.
2. Any application interface that directly reflects the architecture or data model of a backend resource will lead to functional dependencies in the future.
3. Any business event that maps to data that multiple applications or services must leverage, suggests that an event-driven architecture is the best choice.

Architecting for change

Paraphrasing Darwin for a moment, “it’s not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change”. This holds true for application architecture and enterprise IT. In the past IT has been resistant to change, wary of new business requirements, and evasive in the face of market demands. But this has brought incredible disruption – and not just amongst technology companies. IT must now embrace this change, and think strategically and critically about existing architectural choices. No longer will conceptual simplicity be enough to manage mounting IT costs, and so integration requirements must be served with the best possible technology rather than hoping that a one-size-fits-all approach will win the day.

Think Reactive!

We at Push believe firmly in a reactive architecture that extends and evolves your existing IT investments. With data and computing resources delivered from a wide range of cloud services, and end users expecting mobile access to everything, everywhere – you need to adapt how your business data moves.

Consider Real-Time Messaging technology, designed to adapt to your business and application needs as they evolve. As backend data resources grow, change, or move to the cloud Internet Messaging provides a layer of insulation and decoupling that has long been missing within your application architecture of today. The value of an event-driven messaging layer becomes even more valuable as app experiences demand greater levels of interactivity and assume real-time access to data. Finally, data movement across the Internet is not trivial and your data delivery platform needs to react as network conditions vary.

Over the next few weeks we’ll be giving some examples of where your current architecture falls short and how Real-Time Messaging can be used. Download our Real-Time Messaging eBook in the meantime to give you an overview of why you need it for your web and mobile apps.