“Figuring out how to think about the problem.” That’s what Albert Einstein said when asked what single event was most helpful in developing the Theory of Relativity. Application integration is a problem. A big problem. Not to mention data, B2B, and other domains of integration. As an industry analyst and solution architect, what I’m most interested in first is how to think about the problem.
Pop Quiz: The Goal of Integration
Which of the following statements best articulates the goal of integration strategy?
The goal of integration is to keep data in sync across two or more siloed applications.
The goal of integration is to improve business outcomes by achieving consistent, coherent, effective business operations.
The correct answer is B. Was that too easy? Apparently not, because most of the integration strategies I see are framed as if the answer were A. Most, but not all — and it’s the ones framed around B that I’m most interested in. Here’s the difference:
A-style integration centers on technology. It begins with data and business logic fractured across application silos, and then asks, “How can integration technologies make it easier to live with this siloed mess?”
B-style integration centers on business design. It begins with a businessperson’s view of well-oiled business operations: streamlined processes, consistent transactions, unified tools for each user role, purpose-built views of data, and the like. It designs these first — that is, it centers on business design — and then asks, “How can integration technologies give us coherent business operations despite our application silos?”
My Forrester colleagues Ted Schadler and John McCarthy have written about the differences between Systems of Reference (SoR) and Systems of Engagement (SoE) in the customer-facing systems and mobility, but after further conversations with some very smart people at IBM, I think there are also important reasons for infrastructure architects to understand this dichotomy. Scalable and flexible systems of engagement, engagement, built with the latest in dynamic web technology and the back-end systems of record, highly stateful usually transactional systems designed to keep track of the “true” state of corporate assets are very different animals from an infrastructure standpoint in two fundamental areas:
Suitability to cloud (private or public) deployment – SoE environments, by their nature, are generally constructed using horizontally scalable technologies, generally based on some level of standards including web standards, Linux or Windows OS, and some scalalable middleware that hides the messy details of horizontally scaling a complex application. In addition, the workloads are generally highly parallel, with each individual interaction being of low value. This characteristic leads to very different demands on the necessity for consistency and resiliency.
If your organization is like nearly every other one I've talked to in the past 20+ years, you have a spaghetti chart of integration connections between all the siloed applications that run your business. Your customer is fractured across five applications. Your fulfillment process is broken across eight applications. Just try to pull together the data necessary to tell how profitable one of your products is. Or, as you implement mobile, external APIs, custom B2B connections, and more, how will you provide consistent, coherent access to your transactions and data?
Making sense of all the mess has been an important priority for years. The question is "how?" Forrester's latest research finds that it's time for a new kind of integration strategy. We call it "Digital Business Design":
A business-centered approach to solution architecture, implementation, and integration that brings business and technology design together by placing design priority on user roles, business transactions, processes, canonical information, events, and other business aspects that embody a complete definition of a business.