Why Do I Need Enterprise Mediation and What Does it Do?

POINT OF VIEW

Enterprise Mediation provides physical connectivity and interpretation between two or more systems and is a logical capability that can be delivered using one or more products.

The Enterprise Mediation capability facilitates enterprise connectivity, including synchronising data and making it available for new applications. It provides centralised access to hard-to-reach data and creates a natural place to impose regulatory controls (SOX, GDPR), Audit, and Security checks.

The role of enterprise mediation is fundamental. How it is physically implemented can be called anything you like, be constructed from a wide selection of technologies, and may support a wide variety of integration patterns.

It brokers the conversation, providing services such as language translation, adding information to communications, and obscuring sensitive information.

This means that systems sharing data do not have to directly understand each other’s language, protocol, or semantic. There is no need for direct connections, and no need for all systems to be available at the same time. None of the systems need to know whether they are speaking to one or many other systems.

Products relevant to this point of view include Enterprise Connectivity, Enterprise Automation. IBM Integration, IBM Automation, Responsiv Unity, IBM Application Connect Enterprise (ACE), WebSphere, IBM MQ, IBM API Connect, IBM Business Process Manager, IBM Business Automation Workflow (BAW).

Other terms for specific implementations of Enterprise mediation are Service Bus, API Gateway, Broker, Message Broker, Integration Hub, RPA.

Bridge between strategy and implementation

Aligning IT investment and enterprise capabilities with the business strategy is a time sensitive and potentially disruptive undertaking. The ability to deliver change quickly and efficiently is a critical competence for any high-performance organisation.

Structure the Enterprise IT landscape to simplify and accommodate change and additional capabilities.

It makes sense to organise the structure of your enterprise technology landscape to simplify change and to accommodate new, as yet unknown, capabilities.

The business strategy sets objectives and highlights requirements for changes or additions to the IT portfolio. A gap analysis is often required to understand what capabilities are needed to deliver the strategy, compared to what is already available.

Enterprise Mediation supports change, improves reliability, and reduces the cost of enterprise connectivity and operations.

Having a structured enterprise landscape can help the thought process by reducing the clutter and providing clear mechanisms for adding new features, as well as offering options for how to implement changes.

Recognise that the IT landscape has areas of special interest

Like any landscape the broad view may suggest that it is all the same from one horizon to another. Close inspection will reveal that areas can be classified according to risk-of-change, need-for-agility, complexity, lack-of-skills, and many others.

We use Enterprise Mediation to separate these areas to allow them to be addressed in ways appropriate to them. It allows us to avoid contagion in the event that changes are made, and the impact needs to be contained.

Gartner coined the phrase “Bimodal IT” to describe the need to accommodate two separate but coherent styles of work: one focused on predictability; the other on exploration.

The greatest separation is between user-facing systems (Mode 2) that must change rapidly to accommodate new mobile devices and user interface styles but do not store data; from core systems (Mode 1), which store important enterprise data and have a high change risk.

Gartner: https://www.gartner.com/en/information-technology/glossary/bimodal

Looking after the enterprise mediation

Mode 1(core systems) is optimized for maintaining high availability and service in areas of the business that are predictable and deliver core-capabilities.

The mainframe and core systems are mode 1 capabilities. They control the enterprise information and important checks and balances that protect the business. An error in implementation can cause significant, wide ranging, and long-lasting damage.

Mode 2 (User Interfaces) is technology that is more exploratory in nature and more fast-paced, with the pace of change driven by external forces, for example a new mobile device, or demand for new user experience.

These kinds of initiative often begin with a hypothesis that is tested and adapted during a process involving short iterations, potentially adopting a minimum viable product (MVP) approach.

The risk of change here is limited to the specific users of an interface or feature and is not to be ignored, however close monitoring, soft launch changes, and the ability to revert are well understood and effective remediations.

Both modes are essential to create substantial value and drive significant organizational change, and neither is static.

Marrying a more predictable evolution of products and technologies (Mode 1) with the new and innovative (Mode 2) is the essence of an enterprise bimodal capability and is facilitated by a well specified Enterprise Mediation component or strategy.

Enterprise Mediation facilitates and reduces cost of change

Enterprise Mediation must support changing functionality, scale, capacity, technology, and functional placement across the enterprise.

This means that it allows individual systems or functions to be scaled and changed independently of all others, that it prevents contagion from failures, and that it reduces the time and cost of those changes.

Enterprise Mediation supports change, improves reliability, and reduces the cost of enterprise connectivity and operations.

Keeping to principles of isolation, separation of concerns, independence, and low coupling is the only way to futureproof investment and deliver sustainable enterprise automation.

Futureproof Investment

Futureproofing a fixed component is a dream that will never be achieved. The essence of futureproofing is the ability to learn and adapt.

This means that your IT landscape must be structured to allow it to easily adapt to new technology and business need; that your strategy and marketing people must be undaunted by the prospect of asking IT to change what they are doing.

It means that change must be enabled to be completed in a timely manner.

Let me explain.

Consider an Airforce. It is possible for the Airforce to maintain its credibility and capability because it can learn and adapt. A specific aircraft will quickly become obsolete.

The trick is to recognise this reality and create a structure that allows it to happen in a controlled and efficient way. It is not to request the aircraft designers on the left to design a futureproof aircraft.

To futureproof the biplane perhaps we should design a jet fighter. All we would need is sight of the future, improved materials and fuel, computers to calculate the aerodynamics, invent oxygen and Perspex, and let’s not forget aluminium and avionics. Oh, and a bit more time and money.

Build for today, create a foundation for tomorrow

To build for today at a price and time that makes sense while at the same time creating a foundation for learning and adaption is actually not so hard, or expensive. It does require thought.

Attempting to build individual systems for the future is unlikely to return the investment and is very likely to add complexity that inhibits change and adds future cost. Futureproofing should be in the landscape.

Enterprise architects understand the key principles that help us create the adaptable IT landscape to be (1) Isolation and encapsulation to control the impact of change (contagion) and reduce the cost of testing, (2) Independent implementation allows horizontal scaling and change, (3) Separation of concerns to allow each concern to adapt and scale at its own pace without impacting unrelated things, (4) Backward compatibility to allow components to be upgraded or replaced without impacting others, (5) being consistent and seeking simplicity to maintain costs and control complexity.

For more information about principles visit Responsiv.co.uk

Standards change, protocols change, technology changes, the functions we need, and the opportunities we pursue all change.

We achieve most of these through the proper use of an Enterprise Mediation capability and appropriate use of industry standards.

The landscape (foundation) is populated by “Minimum Viable Product” or MVP products that can deliver exactly what is required for the business strategy and considered to be disposable. If they can be re-purposed in future, or re-engineered, then great; but don’t plan for it.

Alternatively, don’t do Enterprise Mediation

Most companies work to the “Minimum Viable Product” or MVP, which means that all effort is focused on delivering the minimum to overcome the immediate challenge. The resulting (emergent) IT infrastructure is often brittle and does not have tolerance for variation from the specified need.

Living only for today is expensive and does not provide a foundation for growth. Conversely, building only for tomorrow is expensive and often mis-directed.

Using these tools, we can build a set of systems that can be adapted, supports differentiated testing and bi-modal management, and that provides a place to augment communication with those systems that cannot be changed.

Service Oriented Architecture (SOA). What went wrong?

SOA failed because it took too long to get to value. The initial implementations created dependencies between the service bus and the end-point systems by interfering with payloads without fully embracing and transforming them. When a consumer and provider use the same schema, then accessing the body (schema), for example to add validation, adds complexity without value.

The fundamental model is solid. It embraces the key principles and provides a consistent and consumable catalogue of services can underpin micro-service, API management, and many other approaches to Enterprise Mediation.

SOA Service interfaces should be designed to be consumed by business processes. They should not leak details of the implementation (backward compatibility). They should focus on data entities (customer, agreement, …)

Each API or Service should be named for its business function to create a set of verbs and nouns that can be used in non-technical discussions.

Application interfaces are designed by considering what the application has and does, and what might be useful to external parties.

One of the problems encountered by SOA implementations is that developers have designed SOA services in the same way as application interfaces. Indeed, often they are simply passed through the enterprise mediation, which completely undermines the value.

Micro Services. What’s the opportunity?

Microservices seek to address some of the problems with SOA, most notably to improve the time to value and place more emphasis on separation and isolation. Like many silver-bullets they are not magic and poor implementation will still lead to failure.

Enterprise Mediation with RPA?

Enterprise Mediation defines a line of control across the enterprise. It separates two different worlds; the slow-moving, high-risk world of data storage and protection, and the world of fast-moving user expectation, connected devices, and situational applications. It protects you from the impact of change. It starts with some ground rules. We call these principles, and there are only a handful that are critical to your success.

Enterprise Mediation is just as important with Business Process Automation, Robotic Process Automation, and other enterprise automation solutions.

Our Point of View

Delivering competitive advantage requires strategic alignment between digital services and organizational objectives. A properly specified service catalogue can be a key enabler to meet the challenges of agility, alignment, and sustainability in the face of dynamically changing enterprise requirements.  The service bus or API gateway is a critical point to enforce governance policies.

You need an enterprise mediation to create a pinch-point between consumers and providers, one that can mediate between the two such that neither knows the customs, language, or location of the other.

The API gateway must be independent of other systems

The pure adapter-pattern has been adopted by organisations with varying success. Fundamentally it does not support the agility of change (regardless of DevOps) and does not properly support services that must aggregate multiple sources. It introduces dependences that should not be there and causes ad-hoc approaches to problems to spring (sic) up.

For an interface to aggregate data or function from several sources, and to scale and move without notice means that the interface MUST be deployed and controlled separately from the implementation.

Internal “Enterprise Mediation” and separate “API gateway”

These are similar capabilities that have different functions – remember the separation of concerns?

Whether you use the same software for both purposes is irrelevant. The important thing is that the two functions are deployed separately and that they are clearly managed for the purpose they serve.

An enterprise API gateway separates internal consumers and providers, adds audit and policy enforcement, and structures integration across the platform.

Its work is to mediate and do enrichment and routing, temporal compensation, and other “heavy functions”.

An external API gateway promotes service interfaces to untrusted external consumers (mobile, partners), supports market differentiation, throttling and protection of internal services, protocol translation, and provides developer support.

It does not do all the heavy integration work that is expected from an enterprise API gateway.

Conclusion and next steps

Adoption of an enterprise API gateway or reviewing an existing Enterprise Service Bus starts with an ideation conversation with Responsiv to flesh out ideas, consider the options, and decide whether it is right for you at this particular time.

We know that companies have a great deal going on, and API management can be tactical or strategic, and can move from being tactical to strategic. Either way the initial implementation needs to deliver value and demonstrate the opportunity, otherwise what’s the point?

If you decide to give it a go, then we will start with a discovery phase. This involves reviewing the APIs that may be candidates for publication and identifying two or three that can be delivered quickly and that will demonstrate value.

We have no doubt that a consistent and cohesive API gateway can bring significant efficiencies to your organisation and look forward to our first conversations.