Enterprise middleware: why and how

When dealing with Enterprise architectures, you’re often faced with a plethora of systems and data silos that don’t talk to each other; think OMS, WMS, PCM, ERP, analytics platforms, CRM, CMS…

Add to this uneven levels of sophistication, format or reliability and you’re left with an integration mess as soon as you need to build cross-channel applications, which is often the case with consumer facing experiences.

Middleware systems act as the glue that ties all these systems and buckets of data together, and offer a convenient and consistent interface for developers to build consumer facing apps.

Since we exclusively work with MNCs, that’s a lot of what we do.

Whether it’s Burberry, Nike, Hilton or Starbucks, we’ve had to develop middleware systems to help us get things done and deliver modern apps that span across multiple channels and scale to tens of millions of users.

Let me share a few of the learnings we picked up along the way.

Common Problems and Anti-Patterns

• The Black box. Some vendor (or internal team) built an API a while ago, and the development of the digital strategy has since stagnated. Making any change is hard and slow, and nobody really knows how the system works or how to integrate with it. This slows down any further innovation.
• Single Channel System. The whole system is built around one specific channel (often the website). Support for any additional channel is done as a one-off and requires an outsized investment of time and resources every single time.
• Closed System. The system doesn’t have open APIs and is close to impossible to integrate with other systems, be it data or features. This often leads to resilient data silos.

If you work with a large organization, you’ll likely run into multiple instances of these anti-patterns, and will need to deal with it in a sustainable way.

So let’s look at what we usually build around these systems.

Patterns that we follow and recommend

• Omnichannel. We design our middleware systems to be channel agnostic. If you use it to build your website, you’ll be able to use the same components and features to support your iOS app or your WeChat mini-program, with minimal changes required.
• API driven components. We make data and features accessible through standard interfaces for other components to leverage. This prevents data fragmentation and encourages feature re-use.
• Microservices architecture. We set clear responsibilities for each component and no direct coupling between them (no shared databases for example). Separation of concerns is a must for maintainability, scalability and extensibility.
• Open Cooperation and technology partnership. We openly work with our clients on digital strategy, roadmap and development to guarantee that everything is aligned when it comes to the middleware. We need to know what’s coming, to know what we should focus on and how we avoid blockers.
• Start Simple. We almost always scale back our client’s expectation for the first release. You should concentrate on the most critical problems first and use that first phase to assess the gaps and challenges of your existing infrastructure, as well as aligning the team on more complex integration patterns or features that may come in the next phases.

This is the secret sauce

These are simple points, but often the simple things are the hard ones.

Our middleware approach is usually key in helping large organizations move faster and remain agile without sacrificing scalability or security.

While seemingly boring on the surface, this often is the “secret sauce” that has allowed us to help some of the largest organizations in the world innovate faster in China, from Starbucks to Burberry.

If you need help accelerating your digital roadmap in China, just drop us a line or come to one of our workshops.