In Software Engineering usability and reusability are two different terms. IEEE defines usability as “the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component”, respectively reusability as “the degree to which a software module or other work product can be used in more than one computer program or software system”. I’m mentioning this because even if a bit old, the two definitions apply to data products as software products.
(Re)usability and similar terms like discoverability and observability can be used as intrinsic characteristics of software, respectively as acceptance criteria, metrics or, upon case, principles. Such a term as principle can be included in a data strategy document and say a few words about it, especially about the relationship between an organization’s values or maybe even objectives. As metric it has only a chance if the term is a KPI, which doesn’t seem to be the case. As acceptance criteria one can maybe mention it and give a definition, though it has nothing to do with the strategy document itself. Maybe one can mention such terms in an objective, for example adopting a data-product approach with X, Y, Z as characteristics though this can have other implications of scope and it’s better to be left out.
However, within data governance it makes sense to include such terms as acceptance criteria categories into the set of policies defined for data products, though then one needs to clarify what the terms mean (e.g. by providing guidance) and derive “usable” and “useful” rules. If one does this, there’s no need to include the terms in the data strategy!
Usability applies as acceptance criteria for any report or data-based deliverable, otherwise all the data professionals until now haven’t done their job (which might be the case occasionally). Reusability didn’t apply to all data-based deliverables, though it was one of the principles used to build data warehouses and similar data architectures.
“Impact from data”: I was arguing the other day that data has value by itself as it’s the blood of processes. When it comes to data analytics or analysis is about harnessing the potential of data. What comes after the mentioned keywords makes sense to some degree, even if might be differences between data product and data asset. I’m trying to understand though what “impactful actions” are. An action always has a reaction even if the result can be barely perceived or is delayed in time.
Just because one changes the name of a set of components that act together to data product and adds a set of acceptance criteria won’t change (by much) the quality of software products unless one educates the business users, the team members of such projects, and improves organization’s data culture. In many organizations departments had autonomy in building data marts and other software products and the approach proved to be often ineffective and inefficient. Even if there’s a distributed governance in place, that won’t change by much the quality of data deliverables. Yes, maybe the previous architectures look like silos, don’t scale that much, and may have other downsides, though technology is seldom the issue when one goes with market leaders. What one ignores is that for each apparent advantage gained in one area there will appear a downside in another area. It’s hard to believe that there’s a methodology or philosophy which provides only wins.
It makes sense to treat data-as-product and data-as-an-asset, to give certain topics the importance they deserve though all philosophical mumbo-jumbo doesn’t make sense to me. One should be pragmatic. What Microsoft Fabric does for the moment and the relaxed definition for a data product makes more sense than what I read until in various books or blog post on the topic.
