Blog: Richard Skriletz http://www.b-eye-network.com/blogs/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. Copyright 2013 Mon, 23 Jul 2012 11:46:58 -0700 http://www.movabletype.org/?v=4.261 http://blogs.law.harvard.edu/tech/rss Why I Emphasize Data - and Why You Should, Too (Part 1) Normal 0 false false false EN-US X-NONE X-NONE

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.

]]>
http://www.b-eye-network.com/blogs/skriletz/archives/2012/07/why_i_emphasize.php http://www.b-eye-network.com/blogs/skriletz/archives/2012/07/why_i_emphasize.php Mon, 23 Jul 2012 11:46:58 -0700
The Third Step to Become Data-Centric: Be Data-Centric in Practice Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

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.

]]>
http://www.b-eye-network.com/blogs/skriletz/archives/2012/06/the_third_step.php http://www.b-eye-network.com/blogs/skriletz/archives/2012/06/the_third_step.php Mon, 11 Jun 2012 12:19:36 -0700
The Second Step to Become Data-Centric Normal 0 false false false EN-US X-NONE X-NONE

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.

]]>
http://www.b-eye-network.com/blogs/skriletz/archives/2012/04/the_second_step.php http://www.b-eye-network.com/blogs/skriletz/archives/2012/04/the_second_step.php Fri, 27 Apr 2012 12:52:02 -0700
Get Your Terminology Straight: The Importance of a Business Data Glossary 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.

]]>
http://www.b-eye-network.com/blogs/skriletz/archives/2012/03/get_your_termin.php http://www.b-eye-network.com/blogs/skriletz/archives/2012/03/get_your_termin.php Information Management Tue, 13 Mar 2012 15:25:47 -0700
The First Step to Becoming Data-Centric Normal 0 false false false EN-US X-NONE X-NONE

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.

]]>
http://www.b-eye-network.com/blogs/skriletz/archives/2012/02/the_first_step.php http://www.b-eye-network.com/blogs/skriletz/archives/2012/02/the_first_step.php Information Management Fri, 03 Feb 2012 12:58:21 -0700
It Is Time for IT to Become Data-Centric 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.

]]>
http://www.b-eye-network.com/blogs/skriletz/archives/2012/01/its_time_for_it.php http://www.b-eye-network.com/blogs/skriletz/archives/2012/01/its_time_for_it.php Information Management Fri, 20 Jan 2012 08:15:00 -0700