Loading...

Loading...

The need for data: Integrate everything

  • Posted on May 21, 2021
  • Estimated reading time 5 minutes
Data Integration And Services Architecture

This article was originally written by Avanade alum Eric Laan.

Employees and customers are always online and connected, expecting more: “What I want, when I want it, on whatever device I want.” Today our lives are spent online, now even more since COVID-19.

With this push for digitization and transformation, the need for data and integration has been increasing rapidly. This results in challenges that business and IT professionals are struggling with:

  • Businesses understand the value of making data available but are often confronted with complex change and IT projects, with some organizations avoiding formal integration practices altogether
  • Exposing data requires a solid integration and services architecture with specialized tools and skills when trying to oversee the challenge, solutions are over-simplified
  • One-size-fits-all integration platforms are often implemented at great expense while only delivering a subset of required functionality, damaging team morale, and impacting productivity on the way

In this series of blog posts, I’ll go into our approach for establishing an integration and services architecture and platform to counter these challenges. This gives flexibility in implementation, and allows an evolutionary approach allowing the organization to develop the integration capabilities it needs based on modern principles and approach tackling the aforementioned challenges. We will use Gartner’s pace-layered application strategy, which is a methodology for categorizing, selecting, managing, and governing applications. It defines three application categories, or "layers," to distinguish application types:

  1. Systems of record —packaged applications or legacy homegrown systems that support core transaction processing and manage the organization's critical master data. The rate of change is low because the processes are well-established and common to most organizations.
  2. Systems of differentiation — Applications that enable unique company processes or industry-specific capabilities. They have a medium life cycle (one to three years) but need to be reconfigured frequently to accommodate changing business practices or customer requirements.
  3. Systems of innovation — New applications that are built on an ad hoc basis to address new business requirements or opportunities. These are typically short life cycle projects (zero to 12 months) using departmental or outside resources and consumer-grade technologies.

Scope of the platform
Let’s first define what we see as the integration and services layer and platform, what purpose it serves, and where it sits in the landscape.

The integration and services layer should provide not just ETL/ELT workloads or facilitate messaging. It should provide all 3 enterprise integration patterns: file transfer, API, and messaging and should be extendable.

Integrations happen anywhere between the layers within the systems in the landscape.

As integrations happen anywhere between layers, the platform should also be available to accommodate the integrations. This means the platform should have hybrid capabilities, be available on premises and in any cloud to ensure that the platform itself does not become the bottleneck.

  1. As defined on CIO Wiki
  2. I intentionally leave out the shared database pattern because this should be avoided to prevent schema coupling, performance bottlenecks, etc.

Decreasing lead times for IT projects
Expensive, long-running, big-bang transformation projects are a relic of the past. Why risk time and money investing in a project that delivers the same old features as before – while the competition races past?

So how to realize value with shorter engagements? If we take a closer look to the Systems of Differentiation and Innovation, we see these share characteristics. The systems are in these layers are becoming smaller and are built on cloud platform services, often expose API’s, and share data through events.

With this move from monolithic to more granular systems we are introducing (micro)services that provide capabilities that are not delivered OOTB in standard systems and allow us to differentiate and innovate. We choose to build these services ourselves and with this create a layer of services that is unique to the business domain.

These services in the new layer are either synchronous (API based) or asynchronous (event-driven) or a mix of both. These new services become integration points and can have considerable amounts of business logic.

Systems Of Innovation Integration

With the event-driven services a new and 4th pattern evolved as well. It is closely related to the 3rd (messaging) pattern but differs in the point that events have producers and consumers which are loosely coupled.

Integration and services platforms
The aforementioned patterns (primarily messaging/events and API’s) focus on enabling the digitization and digital transformation and enable a gradual and evolutionary approach. The collection of these 4 patterns and their related principles, concepts, practices, governance, and platform services together is what a platform should cover. In addition, it should enable industry specific use cases. For example, for manufacturing it should enable use cases like intelligent supply chain, predictive maintenance, and worker safety.

Integration and Services Platform

Within Avanade we combined the platform approach with the technical services that the Azure platform provides. This combination provides many benefits and is focused on enabling the digital transformation. In the next blogs I’ll discuss in more detail what the platform is made up from, the benefits it brings, and how it can be used to liberate data.

Techs and Specs Newsletter

Stay up to date with our latest news.

Share this page
CLOSE
Modal window
Contract