Key senior information management leaders are continually confronted with decisions about adopting one data management tool or another, or launching the data management program du jour (“master data management,” “data governance,” “data lake,” etc.). There is a frequently occurring pattern, though, where people in the organization have already assumed the need for a “solution” even though that solution doesn’t actually solve any specific data management problem. This desire to adopt a new technology or start a new program triggers all sorts of internal machinations – series of meetings to discuss architecture, interminable iterations of PowerPoint slide decks, parades of product dog and pony shows, all intended to launch some new initiative.

Some examples include those triggered in reaction to some management directive (“move everything to Hadoop” and “we need to be doing analytics” are two examples), and leads to the initiation of a series of projects for designing and building components or infrastructure (such as a master data management system, a data governance council, or a metadata repository).

And although ultimately, the intended result would be a positive outcome for the organization, many of these cases are inherently solution-motivated. What I mean is that the main driver for the solution is the perceived need for a solution, rather than some specific set of well-defined business problems that are motivating the need for the design and development of an information management infrastructure.

In these types of situations, the sequence of events is relatively predictable: the project spins up, an acquisition process is begun to select a vendor, tools are tested, and one is selected and installed in the data center. And even though no one has really thought out what to do with the tool, the project is declared a success and the organization moves along to the next shiny object. Yet the absence of both formal business drivers and performance metrics means that no one takes the time to set clear objectives that can be measured to determine how any of these new tools are positively impacting the business.

We recommend adopting a strategic approach that evaluates all proposed technology acquisitions and architecture changes in the context of addressing business problems and opportunities that are motivating the need for any changes in the ways that information is managed. 

Soliciting input from representatives of the various business functions to determine organizational business needs:

• Provides a clear vision about what the key business motivations are within each business function and how achieving business objectives are linked to information use.
• Specifies the criteria to be used in evaluating how well technical methods and new tools and technologies contribute to meeting business needs.
• Highlights who the key stakeholders are who will most benefit from new tools and techniques.

As a byproduct, this process establishes the business justification for a data strategy, defines metrics for monitoring progress and success, and identifies the champions for supporting an enterprise data strategy. Use these ideas to develop a “strategic” data strategy instead of an organically-evolved one:

1. Identify the business data consumers.
2. Assess their data consumption expectations and needs.
3. Determine what their “burning platform” issues are and prioritize in terms of corporate business direction.
4. Document the existing data management landscape and map each data asset to its user community.
5. Evaluate how gaps in the existing data management environment impede the achievement of the stakeholders’ business objectives.
6. Quantify the degree to which these gaps impact the corporate bottom line.

Of course, this is still a high-level set of steps to pursue, requiring some additional legwork to break them down into an operationalizable project plan. This will help tease out key business motivating factors for devising a data strategy by isolating aspects of the existing environment that are the sources of the most critical issues. Exposing these critical issues will allow your data architects to provide guidance for prioritizing areas for remediation. At the same time, devising a strategy whose progress can be effectively measured means identifying business metrics to be used to link technical infrastructure activities to real business impact.