At a customer site recently, we were discussing how to establish a process within their organization to better assist in maintaining data coherence across the life cycle of their information. What brought this issue up was a conflict in application changes from two different groups using the same application database. Due to the change, one of the groups would no longer be able to obtain the report they needed at the end of the month. In this case, HR was not going to be able to tell the CFO how many hours their contractors were going to bill. However, the other group needed more isolation on contract execution due to regulations just enforced by the government. Now that there is a real problem to solve, both groups, along with IT, are willing to engage in a discussion about the need to control changes to their information systems.
To get back to our topic at hand, Roles and Responsibilities of Data Governance, this organization has clearly not defined a process for handling these requests due to IT just servicing projects, and not paying close enough attention to the complete informatoin lifecycle. The first area our discussion led was to who should decide how to implement these changes. Seems like a simple question, but the answer was a Working Group, not an individual. This working group then provided their recommendations, along with their preference, to the stakeholders, who would be making funding decisions on the projects.
Our second issue that was raised from our working group was the need to establish the position of Data Steward within the IT Architecture group. This person has the additional duty of reviewing projects for their effect on the information life cycle and definiion and use of data. The organization supported this request, but was not willing to accept additional costs to implement it. The reality will be an increased project timeline once the process is in full swing due to workload, but that is a lower cost than a full time equivalent in their mind... but not the architects..
The final area that was discussed was the formation of a Data Governance Board that would meet as needed with a representative from each stakeholder group and each architecture team. This meetingboard has three objectives:
- Review all Appllication changes since the past meeting that affect data
- Certify the impact on down stream information to not impact reporting requirements
- Issue change requests for issues not resolved during the meeting
Now, this is NOT a comprehensive list of a DGB, but what we decided this organization needed today. So far, two months laster, this process is a success for both the organization, and also the implementers. They have succesfully integrated an information life cycle review into their project plans, created an method for resolving issues between groups, and established a larger interest group for discussing the value of information to the business.
Hope this review helps a little bit, I will post on their progress when I touchbase with them in a few months.
