In the Field with our Experts

The Dreaded Stairs

By Stephen Putman, Senior Consultant

Recently, a friend of mine posted a link on Facebook that reinforced a philosophy that I have had for a long time that applies to all activities in life that are not duty-bound:

The Dreaded Stairs (part of The Fun Theory project)

I have long felt that humans do things for two reasons:

A) They're fun

B) They're lucrative

This applies to the field of Data Governance and Quality as it does everything else. One of the reasons data governance and quality initiatives are not more widely adopted and followed is that the work is not terribly fun - data owners must be identified, policies and processes must be adopted, and the entire process must be monitored and attended once it is in place. It's also not seen as lucrative in a direct sense - the act of cleansing the data in a transaction usually doesn't provide immediate financial reward, and while the implementation of governance and quality initiatives can affect the company's bottom line, the benefits are very difficult to quantify in a traditional sense.

Phil Simon has produced a terrific series for The Data Roundtable on incentive ideas for data quality programs, so I will not address these here - he says it much better than I can. I am concerned with "fun." The video above demonstrated an innovative idea to make a mundane but healthy activity (climbing stairs) into a joyful experience. What sort of innovative programs can be created to make managing high-quality data fun?

"Fun" is a difficult concept because it means something different to everyone. One way to find out what is "fun" to your employees is by conducting surveys or workshops to ask them directly. Another possibility could be to have a "company carnival" in your parking lot, and award employees who identify quality issues with raffle tickets or a "boss' dunk tank." The White House holds a yearly contest with government employees for the best quality improvement or cost-savings idea (this is more of an incentive, but some people also consider contests like this fun).

These are just a few ideas off the top of the head - do you have creative people who can come up with other ideas? If it is indeed true that fun makes unpleasant activities more palatable, this would be time well spent to reinforce data governance and quality in your organization.

photo by Robin Fensom via Flickr (Creative Commons license)

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles. He is the co-author of The Data Governance eBook, available at baseline-consulting.com/ebooks.

Three-Dimensional Chess

By Stephen Putman, Senior Consultant

I recently read Rob Gonzalez' blog post I've Got a Federated Bridge to Sell You (A Defense of the Warehouse) with great interest - a Semantic Web professional who is defending a technology that could be displaced by semantics! I agree with Mr. Gonzalez that semantically federated databases are not the answer in all business cases. However, traditional data warehouses and data marts are not the best answer in all cases either, and there are also cases where neither technology is the appropriate solution.

The appropriate technological solution for a given business case depends on a great many factors, which I like to call "Three-Dimensional Chess."

An organization needs to consider many factors in choosing the right technology to solve an analytical requirement, including:

• Efficiency/speed of query return - Is the right data stored or accessed in an efficient manner, and can it be accessed quickly and accurately? 
• Currency of data - How current is the data that is available? 
• Flexibility of model - Can the system accept new data inputs of differing structures with a minimum of remodeling and recoding? 
• Implementation cost, including maintenance - How much does it cost to implement and maintain the system? 
• Ease of use by end users - Can the data be accessed and manipulated by end users in familiar tools without damage to the underlying data set? 
• Relative fit to industry and organizational standards - This deals with long-term maintainability of the system, which I addressed in a recent posting – Making It Fit.
• Current staff skillsets/scarcity of resources to implement and maintain - Can your staff implement and maintain the system, or alternately, can you find the necessary resources in the market to do so at a reasonable cost?

Fortunately, new tools and methodologies are constantly being developed that can optimize one or more of these factors, but balancing all of these sometimes mutually exclusive factors is a very difficult job. There are very few system architects who are well versed in many of the applicable systems, so architects tend to advocate the types of systems they are familiar with, bending requirements to fit the characteristics of the system. This causes the undesirable tendency that is represented in the saying, "When all you have is a hammer, everything looks like a nail."

Make sure that your organization is taking all factors into account when deciding how to solve an analytical requirement by developing or attracting people who are skilled at playing “three-dimensional chess.”

 

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles. He is the co-author of The Data Governance eBook, available at baseline-consulting.com/ebooks.

Linked Data Today!

By Stephen Putman, Senior Consultant

I begin today with an invitation to a headache...click this link: The Linking Open Data Cloud Diagram

Ouch! That is a really complicated diagram. I believe that the Semantic Web suffers from the same difficulty that many worthy technologies do - the relative impossibility to describe the concept in simple terms, using concepts familiar to the vast majority of the audience. When this happens, the technology gets buried under well-meaning but hopelessly complex diagrams like this one. If you take the time to understand it, the concept is very powerful, but all the circles and lines immediately turn off most people.

Fortunately, there are simple things that you can do in your organization today that will introduce the concept of linked data to your staff and begin to leverage the great power that the concept holds. It will take a little bit of transition, but once the idea takes hold you can take it in several more powerful directions.

Many companies treat their applications as islands unto themselves in their basic operations, regardless of any external feeds or reporting that occurs. One result of this is that basic, seldom-changing concepts such as Country, State, and Date/Time are replicated in each system throughout the company. A basic tenet of data management states that managing data in one place is preferable to managing it in several - every time something changes, it must be maintained in however many systems use it.

One of the basic concepts of linked data is that applications will use a common repository for data like State, for example, and publish Uniform Resource Identifiers (URIs), or standardized location values that act much like Web-based URLs, for each value in the repository. Applications will then link to the URI for the lookup value instead of proprietary codes in use today. There are efforts to make global shared repositories for this type of data, but it is not necessary to place your trust in these data stores right away - all of this can occur within your company's firewall.

The transition to linked data does not need to be sudden or comprehensive, but can be accomplished in an incremental fashion to mitigate disruption to existing systems. Here are actions that you can begin right now to start the transition:

• If you are coding an application that uses these common lookups, store the URI in the parent table instead of the proprietary code.
• If you are using "shrink wrap" applications, construct views that reconcile the URIs and the proprietary codes, and encourage their use by end users.
• Investigate usage of common repositories in all future development and packaged software acquisition.
• Begin investigation of linking company-specific common data concepts, such as department, location, etc.

 Once the transition to a common data store is under way, your organization will have lower administration costs and more consistent data throughout the company. You will also be leading your company into the future of linked data processing that is coming soon.

photo by steve_lodefink via Flickr (Creative Commons License)

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles. He is the co-author of The Data Governance eBook, available at information-management.com.