I often present enterprise application portfolio views to C-level executives. I convey color-coded views of company applications, grouped by function such as financials, CRM, communication and collaboration tools, and so on. Something a bit like the following:
Discussions often emerge around reconciling figures between systems. For example, it’s not uncommon for the sales system to show slightly higher sales transactions than that of the core financial system. After polarized discussion between business heads, someone will often ask the question: “what is our source of truth for sales numbers?”
I’ve come to the realization that given there are often so many applications, each modifying bits and pieces of sales information, the days of single source of truth are long-gone.
In The Old Days it Was Source of Truth
Decades ago, systems were more monolithic. There were mainframes of the 1970s and ‘80s, and soon thereafter the gigantosauras-style ERP systems of the 1990s and early 2000s which aimed to centralize all business functions into a single system. These systems had a tendency of “owning” business objects in their entirety. For example, the HR system owned employee records, the sales system owned sales records, and so on. It was clean and neat, as records were fairly self-encapsulated within these systems.
As the era of cloud computing started to mature in the mid to late 2000s, SaaS companies such as Workday, Salesforce, and ADP commenced a shark-like feeding frenzy that viciously bit deep into traditional ERP install bases, one gory bite at a time. Of course, ERP systems aren’t easily replaced, and consequently these legacy systems had to cohabitate with their newer, highly-networked cloud brethren for some time.
For the legacy systems that still “owned” specific business objects such as sales, inventory, or product definitions, they had to start sharing, and this gave way to the idea of “system of reference.”
This is defined by the system of truth sharing a (usually read-only) copy of its data with other systems.
Today We Have Shards of Truth
As time went on, the extinction of the on-prem ERP behemoth accelerated as more and more business apps ascended to the cloud. While getting data in and out of these cloud systems was initially problematic, APIs emerged and matured, which significantly increased enterprise system interoperability.
In terms of application architecture, we’ve moved away from the one-size-fits-all Swiss Army Knife in favor of the 58-piece toolset approach to business functions. In other words, a business function such as HR now has a half-dozen or more discrete tools for the job: one for recruiting, one for onboarding, one for core HR, another for benefit management, and so forth.
Herein lies the problem: each of these systems wants a copy of the record, just like the system of record / system of reference days. However, nowadays each of these systems also wants to author (modify) a subset of that record. Using our employee business object as an example, the once holistic record is now shattered into pieces, with each piece being authored by a different system.
As each of the discrete pieces are modified within their sub-systems of record, the pieces of records must be stitched back together into logical, holistic records which must then be propagated to every other system; ideally in real-time.
If this sounds complicated, that’s because it is. While SaaS applications have made it incredibly simple to spin-up business functionality, the data integration is getting increasingly complex.
Where We Go From Here
SaaS applications are exciting. In fact they’re like an epic, all-night rock concert. Unfortunately, their data flows are also like the following day’s hangover. Whether we as IT leaders like it or not, the reality of our SaaS proliferation means data complexity is going to be with us for a while.
Nevertheless, there are some steps to take in order to ease the pain associated with SaaS data integration. The first step is knowing which apps you have, and which general data objects they contain; a step easily achieved through basic enterprise data architecture practices. Secondly, you’ll need a means of centralized cloud integration; usually obtained in the form of a technology platform. Finally, and perhaps most important of all, is having a (lightweight) governance process that ensures data is well orchestrated at the enterprise-level.
In this hyper-connected web of cloud systems, a change in one system will have impact in many others. In a way, each SaaS owner is like a pilot, focused on flying only his or her own individual airplane. Without air-traffic controllers, there will be collisions. So, how confident are you of your own airspace, and are you ready to take on the air traffic controller role?
