I often get asked the question, “What is your data strategy?” It’s a bit of a tricky question as in some areas we do a lot with data, and in other areas, we do very little with it. The market has trained folks to believe they need to become ‘data-centric’ via a data strategy — and so it goes.
The data tools market has various solutions with overlap amongst the different segments which are defined differently by the analysts that cover them. Many of these segments include data integration as a core competency simply because all data tools need to get access to data in order to perform their chosen function. The net result is a challenge in positioning integration tools and platforms through the lens of a data strategy.
Of course, an organization must think about its data assets strategically. It must identify, store, provision, process, and govern it. More importantly, an enterprise must put its data strategy in the context of its business goals and its application portfolio. This is where an application network comes into play. An application network, while not central to the data strategy, is key to the higher-order goal of realization of business value. Put another way, data is one of the key ingredients used by the application network to deliver business value.
Visualize the data lifecycle — from creation through to consumption. A piece of data might start life when a user clicks a button, or a temperature gauge hitting a new degree. From then, that piece of data might flow into transactional or reporting storage. This might be the end of the road or some outlet might flush that data further into a lake or warehouse for further consideration. For the purpose of discussion, I call these data hubs. But they are more correctly any type of data storage substrate where data processing may or may not occur.
At these early stages in the data lifecycle, Mule plays a role primarily in the movement of this data between hubs, maybe securing or transforming it, and having limited to no understanding of the data at rest in a hub. This is effectively the system layer in an API-led architecture. In these hubs, data processing can occur — master data management (MDM), anonymization, merge-purge, quality control, AI training, etc. Hubs are spaces where major data components are assembled.
As data flows further into the application network it might get repackaged and surfaced in an application or dashboard. This is where the application network comes to the fore. Mule, on the consumption side, asks what data is required to deliver business value, and then through a variety of integration techniques such as data visualization, orchestration, APIs, citizen integration, etc., collects data from data hubs and delivers it to consumers. This is the essence of the experience and process layers in an API-led architecture.
One of the unique aspects of this approach is that in order to rapidly deliver business capability the application network has processing tools that can mine raw data from deeper hubs in the data supply chain, in addition to data access technologies, like APIs and legacy transports. This might be through the reuse of an earlier transit service or the building of new services that goes directly to the data source to get data needed to realize a business goal. This is how an application network delivers agility to an enterprise and allows the rapid delivery of applications. This is why we often refer to Mule as an agility layer for your enterprise. The presence of these data capabilities should not be confused with capabilities in the data management space where the focus is more on the uniformity, accuracy, stewardship, governance, semantic consistency, and accountability aspects of data.
To detail this picture, it’s important to consider some of the data management capabilities of the application network. The first is the application network graph — Google Maps for the application network. The application network graph can tell you where APIs exist, it may give you a couple of reviews on the quality of these APIs, but it does serve up an implementation for you. Rather it provides metadata to applications to help them do that work. The second is the notion of interfaces — specifications that describe what data is held behind specific APIs. While interfaces can type and check for the form, it serves the data consumer more than it does the higher-order data consistency master. These two capabilities highlight how Mule is orientated more toward the final assembly and delivery of data than the manufacture and maintenance of raw data. This greatly helps with things like securing data but less with aspects such as data lineage. As I said — in some areas we do lots with data and other areas not so much.
Mule is not your data strategy — rather an application network brings that data strategy to life through data assembly and delivery to consumers. One can think of the applications network as a fabric, or nervous system, that we lay over the top of a data strategy. It serves to unlock the data in order to rapidly deliver high-value business services.
