Managing data in a small data center when no separation of duties is possible because of a shortage of personnel and/or knowledge.

1. 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.

2. 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.