Digital disruption has changed the way businesses do business, naturally the way business software is developed, deployed and maintained, and inevitably the software that vendors sell and most importantly how they sell it.
This disruption is reflected in new software architectural styles adopted (i.e. Reactive manifesto, 12 factor app) and in most cases shared by the likes of Netflix, LinkedIn, Amazon, eBAY, Uber and others. Although at first glance they just seem as an evolution of Service Oriented Architectures (SOA), one can't close the eyes and pretend that nothing has changed. The truth is, a lot has changed.
Specially with the introduction of Microservices Architecture, and "the cloud" as "the" preferred way to deliver/adopt business software with speed, agility and low costs, it might seem as if the days of SOA are ending and that traditional enterprise integration patterns patterns no longer apply and have become legacy.... The addition of new technologies in support of Internet of Things, Artificial Intelligence, Mobility, Responsive Web Apps and API Management, is making it more difficult for architects (those who still care about architecture) to come up with elegant designs that truly deliver blended and balanced capabilities that bring together the old with the new whilst still delivering business benefits.
The truth is that most organisations in the world aren't Netflix or LinkedIn and were not born digital. They don't have the luxury of starting from a blank sheet of paper. Most businesses still run legacy systems and traditional (on-premise) software. For them moving to a Microservices Architecture and adopting cloud is not necessarily a trivial task and will require careful planning and thinking.
The Open Modern Enterprise Software Architecture (OMESA) project was born with the purpose to bring back architectural best practices into modern architectures whilst keeping in mind that the "new" most co-exists with the "old". It provides reference architectures and guiding principles to help architects from any organisation realise the benefits that modern technologies and architectures can bring to the business whilst avoiding the creation of "micro-silos" or ad-hoc solutions.
OMESA has 4 main objectives:
- To deliver a modern and enterprise-wide software reference architecture suitable to combine ”existing" with the "new”.
- Provide guiding principles and definition of terms to ensure the architecture can be interpreted and applied.
- Deliver a vendor agnostic capability model that can add tangible business value to organisations.
- Bring back architectural best practices (based on real live experiences) into modern solutions that are suitable for organisations of any size and industry.
OMESA proposes the following fundamental building blocks:
These four categories constitute a fairly simple entry point to the model, but should be comprehensive enough to encompass a high variety of concepts related to software architecture and design:
- Delivery Experience
- API
- Service Implementation
- Persistence
Once the fundamental building blocks have been established, the OMESA model aims to simplify software design by relying on a reference architecture which can be further decomposed into smaller, more specific blocks. All of these elements can be part of an enterprise architecture but none of them are necessarily enforced.
Within this context, identifying Core Capabilities becomes key when it comes to justifying the presence of any particular building block and ultimately producing a cohesive design by bridging the gap between high-level (conception: fundamental building blocks) and low-level (execution: design patterns) perspectives. For example:
A huge part of our body of work is focused on identifying and describing these Core Capabilities, as well as mapping them to qualified design patterns accross the architectural model.
In addition to the core capabilities we need to provide more operational aspects, denoted by the vertical segments:
- Management
- Business Analytics
- Monitoring
- Security
Besides the conceptual model, OMESA introduces also a simple standard notation which can be used to put together architectural blueprints based on its principles:
As shown by the example above, the OMESA notation is perfectly capable of expressing the basic architectural characteristics of a solution based on either a Monolithic or a Microservices design approach.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Copyright 2017 omesagroup