In an earlier post I outlined the first step to become data-centric: determine what your business data is.   This requires that business data be (1) named; (2) defined; and (3) published.  This first step requires IT to implement a data discipline and governance program that commits to the published business data as the means to interact with the business community on their data and information usage and needs.  Another way to think of this is as defining the semantic layer between the business and the data and information IT delivers to the business. 

The second step to becoming data-centric focuses on the rules that govern business data.  These rules take several forms:

      Data Specification - these rules define the characteristics of a data element:

o   specifying a type of data (date, number, string)

o   specify the form  of the data (numeric, alphabetic, alphanumeric, and so forth)

o   specify the format (identifying whether a date format is mm-dd-yyyy, dd-mm-yyyy, yyyy-mm-dd; number of decimal places in a number; and so forth)

      Data Combination - these rules define data elements such as an Address that are a combination of specific data elements, such as Street (street number and name), City, State, and Zipcode

      Data Validation - these rules define the valid content of a data element:

o   valid values, a list of states to validate whether a state data element, such as is found in an Address, that has been entered is valid, for example

o   valid ranges, to validate a Zipcode that should be in a range of 08800 to 08899, for example

o   table validation, to validate a medical procedure code for a person against the person's gender, age, and so forth, for example

     Data Derivation - these rules define how data is derived from other data elements:

o   life insurance premium, for example, may be derived from a person's age, weight, smoker status, and so forth

o   salary paid, for example, may be derived from the annual salary divided by the number of pay periods in a year, or the hourly salary multiplied by the hours worked in the pay period

o   more complicated algorithms may be required, depending on the derivation to be performed

       Data Usage - these rules define how data is used and presented:

o   conditional display, perhaps an entry for data elements, such as for passport number, passport country, and so forth, should not be allowed unless "Yes" is the response for a "Do you have a passport?" data element

o   presentation format, to allow for presenting numbers, for example, in thousands or millions rather than the full number of digits

These define the range of rules that govern data, what it should be, and how it is used.  This information should be included in the Glossary of Business Terms and used in your data governance process.  I'll discuss rules more in my next post.

In my last post I outlined the first step to becoming data-centric.  In summary, this step consists of identifying the data your business uses, naming it, defining it, and publishing it.  I am consistently amazed that the Business Data Glossary Glossary of Business Terms, which is a simple and straightforward artifact, is rarely produced and used as an essential business and information management document.

When developed, the Business Data Glossary Glossary of Business Terms has business value.  Yes, it contains definitions known to most business users.  However, 'most business users' is not everyone and while a business term may be used frequently, even daily, in the normal course of business, a universal and consistent understanding of terms common to a business is not what I've found in my experience.  This is truer when it comes to business acronyms.  I have seen the surprise expressed by managers and executives with decades of experience in their companies when they read the complete names for the acronyms used in their company.

Establishing an authoritative resource for the terms used in a business is an essential data management document.  It is the official source for the meaning of a business term, the rules for deriving it, if a data rule is required (I'll address data rules as my "Second Step to Becoming Data-Centric" in my next post), and identifies the universe of data for which IT ought to be responsible.

Think about this for a moment: focusing on business information rather than the applications that use it is the essence of being data-centric.   Business requirements can be thought of as specifying business data used in a discrete business action and an application as a collection of business actions. From a data management perspective does this business data used in these business actions in the Business Data Glossary Glossary of Business Terms or do new names and definitions need to be added?  In other words, is the universe of business data expanding?

Thinking about data and applications in this way requires us to rethink physical data, how we structure it, and what we will expect of it in the future.  These issues are coming to a head with the challenge of "big" data, unstructured data, and supporting data access and data delivery for mobile devices.  I'll have more to say about physical data storage in a future post.

The Business Data Glossary Glossary of Business Terms is a source of enterprise knowledge that every company should have and there is no technical or business reason why it can't be created now.  Beyond data names, definitions, and acronyms, the can be extended to correlate a data name with the applications that use it, and even include the database, table, and column names where it can be found.  Get your terminology straight is the first step to becoming data-centric.  Every journey begins with a first step, so take your first step today.

UPDATE: Changed for consistency of meaning and clarity.

In my last post I outlined the importance of IT making the change from being application-centric to becoming data-centric.  What does this mean?  And what are the steps IT should take to become data-centric?  I will address this in my next series of posts.

The first step is to determine what your business data is.  Occasionally, IT has performed business data investigations an exercise to determine which applications contain certain data such as customer data.  This was an exercise to identify which applications use and/or change this data.  While it is necessary to know these things, this is not the way to become data-centric.

Back to Step 1 for becoming data-centric:  To determine what your business data is requires that business data be (1) named; (2) defined; and (3) published.  Let's look at these individually:

• Named business data - This seems trivial yet very few organizations have a list of the data used by the business.  Naming the data is the first action.

• Defined business data - Defining the data is the second action.  This is a descriptive definition for the meaning of each datum and the rigorous specification of the rules to which the datum must adhere for it to have the basic level of integrity, that is satisfy the constraints on the values or the datum that allow it to be considered valid outside of further business contexts.

• Published business data - In order to be data-centric, it is necessary to be able to interact with the universe of data used in the business.  This means a business glossary, a directory of business terminology, or another definitive form of published information about the data.

Taking this step will require IT to implement a data discipline and governance program that commits to the published business data as the means to interact with the business community on their data and information usage and needs.  Another way to think of this is as defining the semantic layer between the business and the data and information IT delivers to the business.  

Using a published business glossary will also change the way in which business requirements are gathered and the way in which business applications are designed and managed.  But these are topics for future posts.

This blog will investigate putting data first rather than having business data be treated as exclusive to applications.  While functionality is important, software functionality is based on consistent operations on data or groups of data.  The application-centric view holds this consistency within the boundaries of one or more, but not all, applications.  The problems that arise from application-centric IT are well known: disparate data in data silos, making it difficult to share data across applications; inconsistent and redundant data; and the need to transform and integrate data for enterprise reporting and analytics.

A data-centric view maintains that any consistent operations on data or groups of data must hold for all applications, eliminating data transformations and making it easy to share data across applications.  Putting data first means we ensure the data is what we want it to be for the business and all its business uses before we build any functionality.  The consistent operations become data rules that are employed whenever an operation, such as data entry or reporting, occurs. Thus software functionality is no more that the execution of pre-defined data rules combined with usage rules for the user interface, such as for a web page, report, or query, a function is performing. 

The benefits of this are clear: data-centric data is standardized and correct across all applications and uses; there is easy sharing of data across applications; there is little, if any, need to transform or change data before it can be used with other data; data rules are known and applied consistently across all uses of data; all data is ready to be used for new reports, business uses, and software functionality; and, most importantly, new software functionality is purely incremental, comprised of new data, new data rules, and usage rules for new user interface components that build upon existing data, data rules, and usage rules without replicating, duplicating, or redoing any data or data rule. 

While becoming data-centric may sound like it is an ideal that is impossible to achieve, we are at a time when technology exists to make this possible. I will explore these in future articles and blog posts.  The challenge for IT is to move from its current application-centric environment where all old applications are legacy silos, and that any new application immediately becomes, to a data-centric environment where data, rules, and usage are unified, consistent, and always good-to-go. We know the problems of application-centric IT cannot be overcome easily--we live with them every day. It's time to make IT data-centric.