We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Blog: Richard Skriletz Subscribe to this blog's RSS feed!

Richard Skriletz

This blog is about moving businesses into the Information Age and out of the Age of Programming. It is about centering the focus of IT and business units on business data rather than applications: How will this change business operations and IT's support of them? What will it mean for IT to be data- rather than application-centric? I intend to explore these questions and more as a means to finding new operating principles for business and IT in the Information Age.

About the author >

Richard is a manager and management consultant with more than 35 years experience working in large corporate and start-up environments. His professional focus is on the strategic application of information technology to improving operational performance, managing organizational and technical change, and optimizing business effectiveness. Richard is a Global Managing Principal with RCG Global Services and CEO of InfoNovus Technologies. He can be reached via email at Richard.Skriletz@rcggs.com.

Editor's Note: You will find more articles and resources, and Richard's blog in his BeyeNETWORK Expert Channel. Be sure to visit today!

You may think that my role as an occasional contributor to the BeyeNETWORK makes it obvious why I emphasize data in this blog, but it isn't the case entirely.  Yes, the BeyeNETWORK is focused on data issues and improving the ability of organizations to deliver quality information effectively.  I believe in and support this purpose which is why I am happy to contribute here. 

However, my reasons for emphasizing data goes beyond this: it is clear that the problems that prevent IT from delivering useful information to the business quickly and easily are exclusively data problems brought on by the outdated, in my view, focus on applications and the functionality they deliver.  Let me explain this.

Consider these definitions (source: Wikipedia):

  • "A computer program (also software, or just a program) is a sequence of instructions written to perform a specified task with a computer."
  • "Computer programming (often shortened to programming or coding) is the process of designing, writing, testing, debugging, and maintaining the source code of computer programs. . . . The purpose of programming is to create a set of instructions that computers use to perform specific operations or to exhibit desired behaviors."
  • "Application software, also known as an application or an app, is computer software designed to help the user to perform specific tasks."  [Note that "perform specific operations or to exhibit desired behaviors" is equivalent to "computer software designed to help the user to perform specific tasks."]

This focus on creating (or buying) programs means that programming--automating specific user tasks addressed by the program or application--is front and center.  This has been the story of IT since it first entered into the business world.

This focus on the program has limited the importance of data to what is needed by the program or the application which contains the program.  This has created the problems we face with the duplication, quality, and variations of data in the enterprise.  After all, we wouldn't talk about data quality, master data management, and data governance if there were no data problems.

Only by rethinking what we mean by programs, programming, and applications will we eliminate the root cause of data problems.  My next post will address the characteristics of this shift from a focus on applications and the functionality they deliver can be made and how it can eliminate problems and costs associated with data today.

Posted July 23, 2012 11:46 AM
Permalink | 1 Comment |

Both business terminology and business rules must be managed for consistency and correctness to be reliable sources of information in a business.  Without that consistency, data is unreliable because its meaning or its usage is uncertain.  Being data-centric means it is necessary to be focused on and, when necessary, pedantic ("overly concerned with minute details or formalisms") about data.  So, how can one be data-centric in practice?

First, as described here, data used in the business must be named, defined, and published in a Glossary of Business Terms.  This is the semantic layer between the business and the data and information an application delivers to the business.  In practice, this means that the terminology used by business people must be aligned with data used in and maintained by each business application system.

Because data is acted on, it is necessary to focus on the rules that govern business data that define what data should be to be valid and how data is presented and used.  In practice, this means that it is necessary to ensure that each rule for a datum is applied consistently in all applications used in the business.

So, being data-centric in practice means that the application development process is redefined to be data-driven:

Requirements - drive these through defining the user interface, preferably using prototyping, so that

  • Each user project or information request begins with identifying each data element and ensuring that it is known, named, defined, and published;
  • Each data element rule is correct for the use needed in the user project or information request;
  • Any new data elements and/or rules are defined and added to your Glossary of Business Terms.

Design and Development - use the prototypes to determine data usage patterns so that

  • The data schema design supports the ways that users will access and use data;
  • Application units of code embodying data rules use SPOT (Single Point Of Truth)/DRY (Don't Repeat Yourself) software engineering principles for data and its use.

Being data-centric means data is central to what IT is about.  We must be data-centric to move from the age of applications to the age of information.  While new application capabilities will always be needed, it is dealing with data and analytics that has become the greater challenge for companies today.  From analytics to the pending zettabytes of "big data" of which IT professionals will need to make business sense, it will be consistent meanings and rules that will help IT deal with the data deluge.

Posted June 11, 2012 12:19 PM
Permalink | No Comments |

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.

Posted April 27, 2012 12:52 PM
Permalink | No Comments |
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.

Posted March 13, 2012 3:25 PM
Permalink | No Comments |

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.

Posted February 3, 2012 12:58 PM
Permalink | No Comments |
PREV 1 2