On the surface, data-centric thinking sounds like a straightforward concept. After all, centering business thought around the principles of data management surely equates to both internal efficiency and external efficacy, if only due to just how prevalent data is in the modern business world. Yet for a philosophy so dependent on objective measurements and calculations, data management as a discipline is surprisingly ill-defined. We know that data-centric thinking is good, but what precisely is data-centric thinking—and more importantly, what does it look like in practice?

For the last fifteen years, the Agile Manifesto has addressed these kinds of obstacles within the context of software development, and done so with widespread success and acceptance. When it comes to more data-centric matters, though, Agile is only a step in the right direction, as it presently doesn’t do enough to remedy the fundamental challenges unique to IT. To that end, the modern organization’s data architecture must evolve to be flexible, adaptable, and risk-averse.

In an attempt to codify the methodology behind successful data management, and taking inspiration from numerous sources including the original Agile Manifesto, we have developed The Data Doctrine. The Data Doctrine states that in order to provide maximal organizational value, data-centric management strategies must adhere to the following tenets:

  • Value Data Programmes Before Software Projects

In order to verify that they’re executing data management processes correctly, business leaders need a formal understanding of data-centric systems, as well as the components that comprise them: hardware, software, people, processes, and of course data. Effective incorporation of data assets into organizational strategy requires an established data management programme that is separate from, external to, and precedes all software development projects. As such, data management and software development must be separated and sequenced, as programmes and projects differ in many critical ways.

While projects are finite and can often function on a small scale with few personnel involved, programs are ongoing, tied to organizational financial calendars, and governance-intensive, and tend to have a greater scope of financial management in terms of budget flexibility and complexity. Furthermore, program change management is an executive leadership capability driven by organizational strategy and subject to market conditions and shifts in business goals. In order to emphasize these differences we use the British spelling of “programme” to differentiate between data programmes and software programs.

  • Value Stable Data Structures Before Stable Code

During a typical software development project, moon lighting and job sharing—the association of zero, one, or more employees with one person or position, respectively—can lead to confusion over specific responsibilities and permissions. In such a scenario, the underlying code being worked with is stable, but the organization of the data that goes into that code is not. By manually managing moon lighting and job sharing so that one employee is respectively associated with one person and one position, a stable data structure can provide a firm foundation from which stable code can then be developed.

  • Value Shared Data Before Completed Software

In theory, the software development process transitions smoothly through predetermined steps: once requirements are established, the project progresses from the design stage into implementation, verification, and maintenance. However, this approach can only work when no sharing of data occurs, a qualification which virtually no data management programmes can claim. Shared data structures require programmatic development and evaluation, and before any of that can happen, you must have stable shared data.

  • Value Reusable Data Before Reusable Code

Even within a single project, various application domains can contain various programs necessary to their operation, many of which may not be universal to multiple or even more than one of those domains. Reusable code is far from a myth, but as this scenario shows, labeling it a priority can sometimes be more trouble than it’s worth. Alternatively, reusable data should leverage shared software routines, and can help simplify decisions about the range and scope of common data usage.

We consider the Data Doctrine necessary not just because of the shortcomings of Agile for data management, but also because of the potential consequences of ignoring the foundational role that data plays in our organizations. Inadequate or non-existent data education at all levels leads to knowledge workers under-appreciating the value of shared data assets. This in turn leads organizations to focus on “holy grail” efforts such as software development, while omitting data programmes and instead trying to manage shared organizational data assets at the project level.

Inevitably, problems arise and organizations increase IT spending to compensate, and consequently overstretch resources on activities like integrating, cleaning up, and managing far more data than is strategically necessary. Altogether, this pattern is inefficient, ineffective, and—most critically—easily avoided with an appropriate degree of data management and data-centric thinking.

The Data Doctrine came from a realization that “data-centric thinking” is an innovative concept with no firm definition, without which it became almost impossible to implement to its fullest extent. With its practical meaning thus established, it’s our hope that data-centric thinking grows to be adopted and put into practice industry-wide just as the Agile Manifesto has, and as a result data is identified and respected as the renewable, non-degradable, and powerful business asset it is.


About The Author

Data Blueprint

Leave a Reply

  • (will not be published)

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>