53210

Guest post by Glen Hobbs

Today’s enterprises are distributed ecosystems. Employees, customers, partners and suppliers with different processes and systems need to connect. But the proliferation of endpoints (apps, systems, processes, data, mobile devices, etc.) coupled with the influx of third-party cloud services has made current traditional and piecemeal integration approaches obsolete.

An Abbreviated History of Enterprise Integration

Integration arose along side networked computing in the 80s and continues today. Businesses wired applications via “point-to-point” connections and grappled with two challenges:

1. elaborate coding to enable applications to talk to each other
2. the n2 problem – for every new endpoint added, new connections multiply exponentially, resulting in hairball-architectures. This is still common now.

The second stage of integration—Service Oriented Architecture (SOA)—was designed to detangle the hairball and reduce the brittleness of the systems. SOA hid complexity behind “services” and created a single connection from the service to the hub or bus. In theory, any service could be changed without affecting everything else in the SOA approach. In reality, success is predicated on achieving consensus between all participants on a common data model. Reaching agreement is difficult. Negotiating changes is even more daunting. Now, this type of SOA is increasingly untenable in the midst of a rapid, far-flung business environment.

Perpetuating the problem is the piecemeal, project-driven approach to application integration that corporations have taken coupled with their neglect of synergizing business processes, master data, customer data, user experience, etc. Along the way businesses got caught up in the allure of applications and lost sight of the fact that applications are merely a means to power business processes. Applications have no backbone to plug into and draw power, intelligence and organization from.

New and Emerging Approaches Still Require Data Model Consensus

To synergize applications, most CIOs still employ a combination of the first and second stages of the integration evolution, point-to-point and SOA. But, increasingly CIOs are moving beyond these architecture approaches to new and emerging integration methods:

• Application Programming Interfaces (APIs) put the onus on the subscriber to consume per the published API.
• Microservices is a more extreme, consumer-centric version where unique single function services are created for each consumer’s need.

Both of these approaches demand sophisticated developer skills and management of API proliferation is a must. While the API approach is code-heavy, there is a parallel path that takes a code-light approach and focuses more on providing rich tooling where more business analyst-type skills can visually configure integration solutions. But, neither of these approaches completely overcomes the requirement of consensus on data models.

The ability for CIOs to wrangle consensus on data models is impossible in a business environment where enterprise technology spending and deployment is out of the CIO’s hands. CIOs need an integration approach they can control.

In the next post in this integration series, we’ll tell the story of how a company can break free of their old integration ways with an approach we consider more revolution than evolution. In the meantime, share your thoughts on the past, present and future of integration.

Image shared by Mark Skipper

53210