The Need for Middleware (5 of 5)

Our final blog in this series is about a solution that is “outside the box” thinking.  Rather than force a decision to change, we believed that an interim step to integrate systems would allow for the least disruption.

The solution of having a middleware platform would allow users to continue to use the systems they are familiar, but provide synchronized data, either through syndicating it on the backend, or re-inserting it on the front end.

As part of our recommendation, we proposed Middleware with the Data Warehouse.  Therefore, the existing systems would feed their data into the Middleware, where there would be a series of business rules, validations, normalization routines, and mapping functions – all based on business rules derived from the Data Dictionary work.  From there, we envisioned this Middleware acting as the Constituent MDM with a single user who would be the expert on the business rules and Data Governance. The MW/MDM would feed the Data Warehouse (DWH), which would also be receiving the transactional data.  From there, business consumers would be able to access the transactional data with the normalized constituent data.

The next step in the progression of the Middleware solution would be to have the Constituent MDM as the main entry point, therefore having multiple users.  The Constituent data would then get fed to the Middleware, matching it with the transactional data and then on to the business consumers.

A final step in the progression would be the paring down of any non-critical databases or apps, therefore further eliminating up-front redundancies and only mildly taxing the Middleware rules prior to the DWH delivery.

Data Dictionary Creation (4 of 5)

Although the Data Dictionary was the tactical focus of the engagement described in the previous blogs, we gave it a back seat to the Culture and Data Governance activities … believing those to be foundational in order to make the Data Dictionary a viable tool.

The organization had more than 40 different apps or databases that contained redundant data that has not been correlated.  Our challenge was to develop a process and a format for identifying and capturing the correlations among and between those redundant data elements, the Data Dictionary being the result. Our approach was to involve the organization’s resources in the process, and to limit our scope to the three most significant systems:

1.     Constituent Information

2.     Contact Relationship Management

3.     Human Resources (Insurance Benefits & Payroll)

The goal was to enable the organization’s resources to continue the process for the remaining systems after our departure. While this effort was under way, they were in the process of evaluating replacement or consolidation solutions for Constituent and HR, but there was really nothing sacred at this point.

After reviewing each of the systems, we compiled key fields, descriptions, data types, and validation rules into a single multi-tab spreadsheet for strategic alignment. Acquiring adequate documentation for two of the systems proved to be a challenge.

After analyzing the data elements of the three source systems, we compiled a list of the unique constituent-related attributes that appeared in one or more of the systems. Working with the organization’s team, we identified Harmonized Names for all of the attributes, established data types and validation rules for them, and started the process of mapping them to the corresponding attributes in each of the source systems.

As an aid to understanding their data structures, we developed entity relationship diagrams for two of the source systems based on documentation provided. We also generated a diagram representing the recommended data structure of their standardized constituent dataset.

Overall, the Data Dictionary documented the mission-critical data attributes that are maintained across the entire application landscape. In the absence of either MDM or a strategic middleware strategy, the Data Dictionary will function as the rulebook that will govern the migration of data from the various applications into the Data Warehouse. Critical decisions regarding common identifiers, data rationalization, and transformation rules will be based on the contents of the Data Dictionary.  However, the Data Dictionary is also a dynamic document, and its maintenance will be the responsibility of the Data Governance Council.

Data Governance Charter and Council Initiative (3 of 5)

This third blog in the series of five will address the Data Governance Charter and Data Governance Council (DGC), which will solidify the Data Governance initiative. I would say they are a pre-requisite, but really they’re more of a positive Catch 22 … you can’t have a Data Governance initiative without a DG Council or Charter, and, Vice Versa.

Following through on the previous post on that organization’s cultural maturity, similarly there can be a wide variance in the way data is governed in an organization. Some organizations may have NO Data Governance initiative, but are handling their data just fine; while other organizations may have a governing body, documented processes and still be dysfunctional.  But, it’s best to set up a Charter and Council that is designed to ensure consistent and maintained data governance standards.

Being on the DGC should be an honor.  The Executive Committee or the President/CEO will sanction it.  The Charter is owned and governed by the DGC. It outlines the structure and operating guidelines of the DGC.

The general purpose of the DGC is to maintain, oversee and promote the use of data governance according to best practices and business needs. The DGC will ensure that management of all systems is done with a global view of their data.

The data governance procedures are designed to keep data governance consistent and maintain informed guidelines for data standards, accuracy and efficiency.

The DGC is a committee sanctioned by the organization's Administrative Team and responsible for developing, maintaining, validating and governing data. The DGC is also responsible for recommending actions to be taken with respect to any data–related issue, including projects that will affect or be affected by any metadata (Enumerations/List-of-Values, Taxonomies, etc.).

The DGC’s role includes the following functions related to the management of the data governance process:

• Review, approve and implement changes to data governance;
• Manage the quality and relevancy of data governance;
• Provide oversight and direction on the use of data governance within the organization;
• Provide and maintain documentation regarding the appropriate use of data governance, data governance training, and data governance rules and standards;
• Provide and maintain documentation regarding the data governance management process;
• Communicate data governance issues and changes to stakeholders, and publish changes to the data governance deliverables on a regular basis.

Here is a typical Table of Contents for a Data Governance Charter:

• Revision Table – Detailed to track all changes to the charter
• Council Responsibilities and Tools – This will include some key dynamic processes as well as any new obstacles or requirements. Here are  few:
• RASCI Charts
• Maturity Model
• Priority Factoring
• Project Management
• Data Flow Diagrams
• Data Dictionary and its Maintenance
• Council Responsibilities and Tools – This will include some key dynamic processes as well as any new obstacles or requirements. Here are  few:
• Team Membership – DGC membership will be fulfilled by representatives from the major stakeholder groups and shall assume the responsibilities according to his or her role. Appropriate stakeholder groups will appoint resources.
• Roles & Responsibilities – Example of Roles:
• Data Governance Sponsor
• Data Governance Lead
• Line of Business Representatives
• IT/System Owners
• Meeting Protocols – All meetings should be held in the highest regard and considered mandatory for the team. Here are a few areas to consider for this section:
• Roberts Rules of Order
• Frequency
• Cancellation & Changes
• Attendance
• Decision–Making – For overarching DG issues, decisions generally are made by consensus of team members.
• Shared activities require a consensus of all representatives listed as “C” (consulted) and “A” (accountable) in the DG RASCI matrix.
• The Functional Area Representatives that own individual activities of the DG (no other areas require consultation) will have final decision authority on those respective DG facets.  Those changes may be implemented without going through the official decision-making process. However, such changes may be reviewed and contested by any member of the DGC.
• On changes impacting the overall structure of DG, other groups in the organization, specific IT systems or diverging from organizational standards, consensus is required.
• The DG Sponsor and the DG Lead are responsible for helping the team achieve consensus. If consensus is unattainable, the DG Sponsor makes the final decision.
• There is no quorum required for decision-making. All members are required to submit feedback on pending changes either during regular meetings or by email if they are unable to attend. Feedback must be received by the date and time of the meeting.
• Communications – Example documentations to consider:
• Meeting Minutes recaps
• Change Request Forms
• Functional department Status Reporting

Cultural Change Management Analysis for Technology & Life (2 of 5)

In my previous post about the private organization that wanted a Data Dictionary, but had reluctance to do some foundational work to make the initiative a long-term success, I touched on the idea of Cultural Change Management – the ability for people and departments to “play well together.”

There are a number of factors that can cause situations to fester and result in poor culture.  Although this private organization did not have all of these, here are a few symptoms to be aware of:

·      Executives that don’t walk the talk

·      Management more concerned with CYA than taking responsibility

·      Management more willing to take credit than give credit

·      Micromanaging and managing by fear or power exertion

·      The “challenge-your-decisions” atmosphere

·      Enabling poor performance

·      No all-business goals aligned throughout the organization

·      Not understanding the relationships between capacity, resources, project dependencies, demand, productivity and efficiency to reach the best sequential prioritization of projects

As you can see, these are entirely the responsibility of the Executive and Management teams … because, as they go, then the employees will follow.

So, here are some tools, exercises and attitudes to follow to build the appropriate culture:

·      Have a model to follow for change – This will create an environment of knowing expectations. If you do it this way every time, then there will be fewer surprises and everyone will know what it will take for change to get accepted, coordinated and implemented. Here’s a classic six-step approach:

1.     Define the project – Is it worthy?

2.     Understand the Current Workflow – You have to know where you are.

3.     Develop the Optimal Workflow – Based on what you know now.

4.     Implementation Development – A step sometimes omitted.  You can’t implement without it being contextual.

5.     Implementation – The best ones are those that are well planned.

6.     Ongoing Maintenance – It won’t run itself.

7.     The Silence  - Sit back and bask in the glory of success.

·      Hire an executive in charge of culture – This person should only have reporting responsibility to the CEO/President.  There will be no agenda for his/her motives, just the good of the company.  It takes a special breed to avoid the politics, but they are out there.  Find one.

·      Nurture your evangelists – Find those people with passion in your organization and help them develop.  Don’t hold them back.

·      Find out what are perceived and what are real resources. If you’re going to take on change, it might have to be a trade off for other duties, projects or initiatives.  Your resources will need the time to serve the project appropriately.  Give them that time for success – the short-term loss will yield long-term success.

·      Don’t allow anonymity – If it’s going to be said, it needs to come from a source. If the source isn’t willing to provide a face to the comment, then there is no comment.

·      There needs to be a sacred place to meet – this place will be the “war room,” where participants leave their agendas at the door.  The meetings will be facilitated by a third-party (it can be a manager from a non-involved department if the VP of Organization Development is not available).  This room will provide the best place to develop the change – think walls of white board or corkboard.  Get rid of the tables if you can – remove any barriers, physical or mental.  And, leave those devices at the door – focus on the project.

·      Live by these five principles, originally developed by Zenger-Miller:

1.     Focus on the situation, issue or behavior, not on the person.

2.     Maintain the self-esteem and self-confidence of others.

3.     Maintain constructive relationships.

4.     Take the initiative to make things better.

5.     Lead by example.

·      Most importantly, learn this approach: “What” is the question (period).  This takes away the defensiveness of responses. If you can ask a question using “what” rather than “why”, you’ll find a life-changing experience awaits.  I dare you.

·      Key books for your constituents to read:

·      The 7 Habits of Highly Effective People

·      Who Moved My Cheese

·      Journey to the Heroic Environment

·      Flawless Consulting

·      Leader as Coach

·      Crucial Conversations

Software just doesn’t get implemented without a complex Change Management process.  But, it goes beyond the processes and the software.  The success lies in the people, the leadership and the belief that something greater will happen as a result of the change.

Few organizations have had the hierarchy, the insight, or the resources to accomplish this change in total as described in this paper.  Many want to rush to the end, but the mantra of doing something “Right Up Front” (RUF) can result in payoffs well beyond expectations.  Good luck!

Having a foundational strategy to a Data Dictionary (1 of 5)

This is the first of a five-blog series, based on an engagement this past year. We were approached by a private organization to provide a Data Dictionary, which is one of those terms we sometimes have a bit of skepticism.  The immediate questions were:

• ·      What is your definition of a Data Dictionary?
• ·      How many systems are involved that would require the Data Dictionary?
• ·      Are you ready to maintain a Data Dictionary?
• ·      What kinds of changes are going on at the company that may be causing this request?
• ·      What kinds of pain points are being experienced that may be causing this request?
• ·      What is the overall knowledge of the data management?

After several meetings, it became clear that there were some misinterpretations of definitions and some key foundational requirements that were not aligned between what we would consider a successful approach and one that may not be best for their long-term needs.

So, our proposal was not just to give them the Data Dictionary, but to get them “to” the Data Dictionary.  (Think about the old proverb: “Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime.”)

There was reluctance from the organization, as they wanted to have the final product but at the expense of not having to do the work up front to make sure the final product was going to succeed.

This brings up an interesting paradigm that we preach at Liaison.  The mantra is “Right Up Front” (RUF).  So, in order to have the best Data Dictionary and process to maintain the Data Dictionary, we were compelled to propose several RUF initiatives to make sure it was successful.  We’re not just going to turn over a Data Dictionary without engaging with the prospect on the foundation to make it work. So, we stood firm on several additional exercises to lay that foundation:

• ·      Data Governance – This included workflow processes, resource capacity, resource responsibilities and setting up of a governing council.
• ·      Cultural Change Management – This included finding out more about how well the company gets along internally.  If you can’t play well together, you may not be able to handle data well together, either.
• ·      Strategic Thinking – This included a common goal, how those goals will be achieved and an asynchronous attitude to bring those strategies to fruition.

It is Liaison’s model to make sure these are in place (or at least understood) and with a plan to have the right tools in order to proceed down the data management path. Without this, data management will be data mismanagement – then both the customer and Liaison reputation could be at risk.