Data fabric vs. a data fabric
People generally use data fabric (without “a” or “the”) when talking about the general concept we’re discussing here, sort of the way that people talk about big data: “We’re looking into data fabric to break down organizational silos,” for instance. But if you’re talking about a specific implementation, you’re more likely to use an article: “We hired SAP to build a data fabric for the company.”
Data fabric architecture: Key components
Broadly speaking, data fabric consists of two parts: an app or web-based front end, where users can see and configure the various sources of data, and the systems on which they reside. From this front end, users can create data models and see all their organization’s data.
The front end is interacting with a back-end engine (or engines) that power the data connection under the hood. These engines automatically keep track of the connections to data sources and available storage, sync and tune data, and so on.
Usually when people talk about data fabric architecture, they’re talking about the back end, and the components necessary to make that magic happen. As noted, there’s no single universally accepted structure for a data fabric architecture. You can check out several different takes on the subject — IBM outlines Forrester’s definition, SAP has its own ideas, and Qlik, another vendor, offers a different version.