Managing Data Governance in a Small Shop

In some ways, data governance in a small shop (let us say less than one hundred IT staff) is relatively easy. Smaller companies are more flexible, both in terms of what can be done and what will be done, than a large company with thousands of IT staff. A large part of that is the ability, even necessity, of getting a representative from all IT areas together to agree on a strategy.

From 1999 through 2002, I supported a Medicare group system in a single data center. While there were seven total applications (five states, US Railroad employees, and Durable Medical Equipment), each was a clone of one original application. My positions in this organization were data security team lead, DBA for VSAM, IMS and DB2, storage management, IMS on-line support, test system team lead, capacity planning, and backup to CICS on-line support. For data governance purposes, I had two major advantages having so many disparate duties.

The first advantage was a solid, high-level understanding of the entire application picture as well as its parts. I knew in detail what and how a certain change to one aspect of the system would affect the other aspects of the systems. That made it relatively easy to coordinate business needs with technical needs.

The second advantage to being the technical lead for so many IT aspects was that I could more easily present a united front to the business team. In this way, I could create and enforce standards based on ITIL and CMM concepts with little interference from outside as well as demonstrate the value of these standards to the business community. For example, because I was both the RACF administrator and the data administrator I could easily reconcile security needs with dataset naming conventions through enforceable standardization. In a large shop this can be difficult, especially if the security administrators do not have a good rapport with the data administrators.

The one aspect I had no control over was how clean the data was. That responsibility lay with the programmers of the on-line and batch edit programs. Although I had no direct control over this aspect of the business, I made a concerted effort to get to know the programming staff, understand their work, and develop a rapport with them. In this way, I was able to plan for the occasional bad data working its way through the system, and had some indirect influence over cleaning it up. Again, in a large shop this would be next to impossible.

Once the various standardization and data policy rules were in place, it was very easy to accommodate the new HIPAA regulations in 2001 because our data governance policy was already doing most of the things HIPAA required. The Sarbanes-Oxley law, in general, was also relatively easy to implement in 2002 for the same reasons. However, there were some difficulties with SarbOx, mostly minor, but with one major exception.

Managing Data Governance in a Small Shop

One of the major impacts of the Sarbanes-Oxley law, at least from the personnel standpoint, is a concept called separation of duties. This concept is meant to eliminate pathways to fraud by preventing one person from having access without adequate oversight. For example, a security administrator is responsible for maintaining access to data. Therefore, under SarbOx, the security administrator should not have access to the data he or she is protecting. For example, in a zOS mainframe environment using RACF, the RACF administrator for a given application should not also have responsibility to any other aspect of data processing for that application, including access to databases, non-security reports, claim payment systems, and so on.

This concept is relatively easy to implement in a large data processing shop, but almost impossible in a small shop. In my Medicare position, I had the ability not only to change business data (via database administration); I was also in a position to cover it up effectively (as security administrator). If I were an unscrupulous individual, I could have committed Medicare fraud and/or damaged the application beyond repair without being caught, at least not for a long time.

The problem seems to be made worse when data governance is included. A small shop may not have the resources to manage the data’s integrity while also protecting business data from harm. However, as it was possible for me to manage the Medicare systems without crossing any ethical lines, it should be possible to have a small team to manage business data and minimize potential negative impacts from not having separation of duties as per Sarbanes-Oxley rules. For this to happen, it is essential to have a security administrator who is both technically very competent and has very high ethical standards. This person would then manage the ability of the data governance team members to access critical business data.

It is also critical for the IT and business areas to have a good rapport, one in which either side is both free to bring requirements to the other area and is open to feedback and/or criticism from that area. The two areas may have separate areas of responsibility, but they must share the same goals. It is essential no matter the size of the IT staff. Arguably, it is more critical in a large shop where business and IT people often focus on their own goals and not the goals of the company. In my experience, this relationship is potentially easier, both to implement and to manage, in a small shop where everyone knows everyone else.