Sounds familiar?
Competitive advantage
The report predicts further: “By 2003, in most industries, enterprises that adopt a more virtual, recombinant business model will gain a substantial competitive advantage over those that do not”. It’s still a great read. “All c-commerce efforts (collaborative commerce) will rely on a robust, integrated, enterprise-centric suite of applications that are based on open architectures and capable of real-time information exchange”.
This single report has been widely recognized as a major driving force for companies to adopt a service-oriented architecture and focus more on value chain integration and collaboration. The ‘3-tier’ architecture model became the logical outcome: separate the ERP registry from the collaboration process and the user interfaces for the different channels. You needed to break up your silos to be successful in the digital age, remember? It all made sense then, and it still makes sense today.
Or does it?
Domain driven design
Well, it turns out that if you split a big monolith in three tiers, you risk ending up in parts that are still too big to manage. Business changes frequently impact more than just one tier, requiring careful coordination and often taking significant amounts of time. Attempts to try and tackle this with just adding more people to the job have largely failed. More teams bring more coordination and more ceremony, hurting your ability to change and innovate at speed.
That’s where domain driven design comes to the rescue. Instead of splitting a large monolith in technical tiers, we split it in dozens of functional domains, aligned with business capabilities, each served by its own team. The team is end-to-end responsible for its domain. In order to become nimble, these teams work largely independently, each building their own microservice. Ideally, a change in one domain should have no impact in another domain whatsoever. Effectively, microservices are in fact mini-silos.
Overcoming Drawbacks
We all know that silos have drawbacks. The world is simply not structured in a way that you can easily assign each individual to exactly one silo. And everyone who works cross-silo knows there can be a myriad of inconsistencies. This is independent of your involvement role – customer, employee, manager or supplier. User-interaction logic, naming, inconsistent data, different outcomes of calculations, inconsistent logistics, financial and legal differences, it can easily become a confusing and even frustrating experience. So how could having more silos be advantageous?
The solution lies in technology. Think about your phone. You have dozens if not hundreds of apps installed. Yes, there are differences in the way they work. But nothing that’s not manageable. And yes, different weather apps present different forecasts. But that’s not necessarily problematic. It might even be good. There can be, and often there are, different realities that we deliberately do not want to harmonize away.
Massively distributed design
The reason this all works, without becoming utterly chaotic, is in the frameworks and middleware shared by all apps. Just a few app stores are offering millions of apps. There is a single notification system. There is one clock with a single worldwide-synchronized time. There is one settings app. You can often use a single user account. One calendar. A common authentication mechanism. And even payments are being harmonized now.
With business systems, this could work similarly. Big systems can be split into multiple apps. Each app might have more than one implementation. Specific complexities, such as national standards and legislation, can be implemented in a specific client – deliberately designing away the need to bring all complexity of all localizations into a single global app. Of course, inside a company, requirements for data consistency are strict. You cannot allow an order that’s been paid not making it to delivery. Or an order cancellation not being reimbursed. So, when there are different microservices at play, and a multitude of apps that consume them (in other word: with a massively distributed system), service integration is more important than ever.
From the success of the phone model, we should understand that there is more to an integrated experience than just data integration. In fact, you should design for harmony and consistency across your ecosystem. That’s not only on the user side, but also at the backend. You need a universal event backbone, object storage, observability, service mesh, log analytics, container orchestration, to name just a few. That’s what’s now being called your outer architecture.
Outer Architecture
Your outer architecture has to support a multitude of techniques. Data integration, file-based integration, message-driven integration, streaming integration and event-driven integration, to name the most important. In the microservice world, Kafka has a lot of momentum. Kafka is a reliable, event-driven data stream with integrity and scale. Of course, you publish all your APIs in a single API store. You manage your API policies in a single policy manager. You have a single Identity Provider for all types of identities. The list goes on.
Think back of the app ecosystem on your mobile device. Numerous are the stories of developers who have transformed an idea into a successful app over the span of a couple of days or weeks. Go viral first, add features later. This is the tremendous power of those ecosystems. The richer the development frameworks and app infrastructure, the easier development becomes. Equally, your digital platform services have become a vital part of your digital ecosystem. But someone still has to put all those out of the box features in the box first. Who is ready to assume the role of Apple or Google in your own ecosystem?
Go Connext
Connext is our Digital Integration Hub we offer as a virtual private platform. In fact, it’s a well-integrated amalgam for the outer architecture of your microservices as well as the middleware layer for your internal systems and cloud services. Hence, is your one-stop-shop for hybrid integration solutions. You can develop your own integrations with the ease of developing a mobile app and build a rich experience meeting the highest quality standards – be it event-driven microservices or low-code orchestration services. It does tick all your boxes.
Not convinced yet? Download the case study to read how Utrecht University uses Connext. Or you can call us for a demo, anytime. Seeing is believing.
