In the Field with our Experts

Where’s Your Stuff? The Importance of BI Program Artifacts

By Mary Anne Hopper, Senior Consultant

Do you have young kids with toys with little pieces all thrown together?  Do you have boxes of organized holiday decorations but every year the hangers or replacement bulbs are missing?  Do you have a Tupperware cabinet that is a constant juggle matching containers and lids?  Is your toolbox organized but the smallest screw driver lives in the kitchen junk drawer?

Now let me ask the same types of questions a different way:  Do you have a repository for your BI Program documentation?  Is it complete?  Can you find what you’re looking for?  Or, do important artifacts needed to support and grow the application exist in many different places?

Oftentimes, I see important BI documents buried in project folders.  This can be everything from database design to ETL design to source-to-target to data load scheduling.  Case in point, at a recent client, I asked to see a complete source-to-target artifact so I could add on to it for a second phase of a BI initiative.  I was given a link to a spreadsheet in a document repository and then two additional links.  The entire source-to-target picture of the environment was already stored in three places with the intent to create yet another one. The client’s reasoning? They didn’t have access to the right tools and all project artifacts had to exist in a certain place in their taxonomy for the project to be complete.

While many BI vendors offer knowledge management tools for BI projects, most of our clients are stuck with spreadsheets in the short-term. My recommendation to the client was to merge the various spreadsheets together and put them along with the accompanying program level documentation in a centralized location.  That way, one artifact could be utilized by future projects, resulting in reduced time and effort for next imitative.  And if they didn’t, important documents would continue to spread through their directory structure and future project teams would spend more and more time with each new project—as they tried to piece together what the application looks like and where their project needs fit, resulting in longer implementation timelines.

Next time you’re kicking off a BI initiative, take some time to think about what others need to know and what they need to find.  Be deliberate about creating—and annotating—your knowledge management system for BI. Some organization, process, and consolidation upfront will save you time the next time around.

photo by e0nn via Flickr

---

Mary Anne has 15 years of experience as a data management professional in all aspects of successful delivery of data solutions to support business needs.  She has worked in the capacity of both project manager and business analyst to lead business and technical project teams through data warehouse/data mart implementation, data integration, tool selection and implementation, and process automation projects.

The “Temporary” Building

By Stephen Putman, Senior Consultant

I was walking my dog on a sunny morning recently when we cut a path through my daughter’s middle school. I saw a group of temporary buildings attached to the main wings of the school, operating as additional classrooms. These new buildings were made to appear to be integrated with the existing classrooms, but it was obvious that they didn’t quite fit.

I thought back to my own years in middle school in the 1970s. My school was a recently-converted elementary school, and there were several temporary buildings constructed to provide facilities appropriate to a middle school, just like at my daughter’s school. I went back to that school a couple of years ago, and those temporary buildings were still there, 35 years later. I thought, “Aren’t these building called temporary for a reason?”

I believe that these buildings are still being used well past their original lives because of short-term, tactical thinking - it’s easier to keep things going as they are than to endure short-term disruption to build more long-lasting, integrated structures. Years of this tactical decision-making extend the lives of these buildings, even though it is likely that it is more expensive to maintain these buildings than the cost of erecting solid and permanent structures.

This reminds me of some data warehouses I’ve seen at our clients. Their enterprise reporting capabilities are built like these temporary buildings, with mismatched parts that are not integrated and often maintained at a higher cost than a solid, foundational system. I have seen many instances of reporting systems that are maintained constantly, manually, and reactively, nursed along over the years in the mistaken belief that maintaining these systems are less costly than building a permanent, integrated system, ignoring the cost and synergy benefits.

Don’t spend your time, effort, and money maintaining temporary structures--they may stay around much longer than you intend, and cost you much more in the long run.

photo by teofilo via Flickr.

---

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.

MDM and the Psychology of Data Management Maturity

By Bob Wall, Senior Consultant

I recently read an interesting article on the web entitled “Ascending the Data Infrastructure Hierarchy: The Five Stages of Data Infrastructure Maturity." ¹

In it the author discusses Maslow’s self-actualization psychology² and the Hierarchy of Needs (further information here) and creating an enduring Data Management Infrastructure. I believe it has implications to achieving data management maturity, which is a fundamental ingredient for MDM success.

As Baseline partner Evan Levy has explained in his MDM presentations, MDM is comprised of both “(Master Data) Management—capabilities to support master subject areas such as Customer, Product or Account—and Master (Data Management), in other words sustaining data management via standards, guidelines, and procedures. This includes the following Data Management functions:

• Data stewardship
• Data architecture, analysis and design
• Database administration
• Data security management
• Data quality improvement
• Reference/master data management
• Metadata management  


In trying to better manage these data management functions, reach an optimal level of data management maturity, and support a successful MDM implementation, Maslow’s hierarchy of needs and self-actualization psychology provides some helpful insight. In his epic psychology writing, Maslow organized human need into three broad levels: first, the physiological - air, food and water; then the psychological - safety, love, self-esteem; and finally, self-actualization. His insight was that the higher needs were as much a part of our nature as the lower, indeed were instinctive and biological. Maslow's greatness was in re-imagining what a human being could be.

The following schematic shows Maslow’s Hierarchy of Needs and an analogous Data Management Hierarchy.

 

Maslow’s Hierarchy of Needs and an analogous representation of a Data Management Hierarchy





We can see the 5 areas of the Data Management Hierarchy, mimicking Maslow’s Hierarchy of Needs, as follows:

Level 1: Tribal – Basic Needs (survival) 

At this level, an organization functions from day to day, but without any formal processes or systematic management. Instead, data management is left to the decisions of knowledgeable and skilled individuals.

Level 2: Enforced – Safety Needs (comfort)

As a company advances to the next level of the Data Management Hierarchy, the Enforced stage, it begins to adopt some semblance of governance, which includes documented standard operating procedures and putting in place change controls to better manage workflow within its data environment.

Level 3: Standardized – Psychological Needs

As organizations advance from the Enforced stage to the next level, they reach the Standardized stage, in which, as the name suggests, processes are established to handle various aspects of data management and less importance is placed on individual decision making.

Level 4: Actualized – Self-Actualization

In the Actualized stage, organizations are able to start getting more creative with their data. Data can be extracted from across the enterprise - as well as from outside sources - and combined to create useful information and made actionable to create new knowledge and value added business propositions.

Level 5: Peak Performance Peak Experiences

At last, the organization reaches the height of data management development, where it can devote all its resources to high-level strategic initiatives, rather than administrative issues.

MDM success is directly proportional to how well an organization integrates data management principles and reaches a peak performance/experiences maturity level.  Hence we can see the possibilities of the gradual application of Maslow’s Psychology of the Hierarchy of Needs, leading to the ascendance of data management maturity and re-imagining what a successful MDM project could be.

¹ John Bostic, Ascending the Data Infrastructure Hierarchy: The Five Stages of Data Infrastructure Management Maturity (Auerbach Publishing, 2007).
² Abraham Maslow, A Theory of Human Motivation (Psychosomatic Medicine, 1943).

---

Bob Wall is a senior consultant with Baseline Consulting. He is an information technology specialist with 30 years experience in all areas of data warehouse administration, data architecture, data resource management, training, and applications systems development, as well as in corporate management.