Blog: William McKnight Subscribe to this blog's RSS feed!

William McKnight

Hello and welcome to my blog!

I will periodically be sharing my thoughts and observations on information management here in the blog. I am passionate about the effective creation, management and distribution of information for the benefit of company goals, and I'm thrilled to be a part of my clients' growth plans and connect what the industry provides to those goals. I have played many roles, but the perspective I come from is benefit to the end client. I hope the entries can be of some modest benefit to that goal. Please share your thoughts and input to the topics.

About the author >

William is the president of McKnight Consulting Group, a firm focused on delivering business value and solving business challenges utilizing proven, streamlined approaches in data warehousing, master data management and business intelligence, all with a focus on data quality and scalable architectures. William functions as strategist, information architect and program manager for complex, high-volume, full life-cycle implementations worldwide. William is a Southwest Entrepreneur of the Year finalist, a frequent best-practices judge, has authored hundreds of articles and white papers, and given hundreds of international keynotes and public seminars. His team's implementations from both IT and consultant positions have won Best Practices awards. He is a former IT Vice President of a Fortune company, a former software engineer, and holds an MBA. William is author of the book 90 Days to Success in Consulting. Contact William at wmcknight@mcknightcg.com.

Editor's Note: More articles and resources are available in William's BeyeNETWORK Expert Channel. Be sure to visit today!

Recently in Master Data Management Category

I have completed teaching the Master Data Management Course in Sydney.  Thank you to my wonderful students.  Some memorable learning the last 2 days was done around some of these points:

  • Master data, with MDM, can be left where it is or, more commonly, placed in a separate hub
  • Product MDM tends to be more Governance-heavy than Customer
  • In a ragged hierarchy, a node can belong to multiple parents
  • Be selective about the fields you apply change management to
  • Customer lifetime value should ideally look forward, not behind, and should use profit instead of spend
  • Customer analytics can be calculated in MDM or CRM, the debate continues
  • Complex subject areas require multiple group input
  • Critical elements in MDM data security include confidentiality, integrity, non-repudiation, authentication and authorization
  • Syndicated data is becoming increasingly important and MDM is the most leveragable place to put that data
  • The web is also a source of syndicated data
  • Data quality is a value proposition
  • Do you have a data problem or a customer data problem or a product data problem?  It affects your tool selection
  • Care about what matters to your shop when you evaluate vendors
  • The program methodology should be balanced between rigor and creativity
  • In the design phase, you develop your test strategy, data migration plan, non-functional requirements, functional design, interface specifications, workflow design and logical data model
  • Don't mess up by staffing the team with only technicians
  • The purpose of the data conversion maps is to document the requirements for transforming source data into target data
  • Organizational change management is highly correlated to project success
  • Stakeholder management is not a one-time activity
If you're interested in hosting the class in 2012, please contact me.

 


Posted November 10, 2011 2:23 AM
Permalink | No Comments |
IMG_0908.jpg

Day 1 of The 3-day Master Data Management course is in the books here in beautiful Sydney, Australia.  It's been an outstanding day of learning and sharing about the emerging, important discipline of master data management.

Here are my most vivid recollections from today:

  • MDM is highly misunderstood due to the wide range of benefits provided
  • MDM is part of major changes in how we handle data and to information chaos, which will get more complex before it gets less complex
  • MDM can and should support Hadoop data and all manner of data marts
  • Lack of a subject-area orientation in the culture is a challenge for MDM
  • Some MDM is analytical, most is operational
  • MDM subject areas can mix or hybrid across factors of analytical/operational, physical/virtual and the degree of governance needed
  • Often many systems build components of a master record, few work on the same attributes
  • MDM returns are in the improved efficacy of projects targeting business objectives
  • To do a return on investment justification, all project benefits must be converted to cash flow
  • MDM should be tightly aligned with successful projects, creating benefits for the MDM program
  • Personal motivators must be understood and are important in building an MDM roadmap
  • Vendor solutions may be subject area-focused or support multiple subject areas
  • Tactical MDM supports an individual project, enterprise MDM supports the organization for the subject area
  • Strong project management discipline can be more important in that role than MDM domain knowledge
  • The data warehouse will remain relevant in organizations, but many of its functions are moving operational, such as those to MDM
  • You can mix a subject are with the hub persisting frequently used data elements and pointing to source systems with the rest of the data
  • Do not count on the data warehouse for what MDM provides
  • Governance workflows provide the ability to escalate if actions are not taken in a timely manner
  • External sources like EPCID are becoming relevant in the product subject area

More to come on days 2 and 3.



Posted November 5, 2011 11:57 PM
Permalink | No Comments |

Finally, the MDM team needs to consider how many environments it maintains.  Often, 2 development environments are required.  One is a replica of production, which is used to work on production hot fixes and quick development activities as a result of production findings.  The other is the environment that MDM is doing its ongoing development on. From the development environments, MDM maintains the path-to-production which incorporates all other pre-production environments.

 

It could come up as to which MDM environment application development environments will use and who will maintain those environments.  If applications are going to use one of the MDM environments, there may be conflict with MDM's development.  If a copy is used, space must be procured and that copy must be managed.

 

There are also MDM workflows, where we find a ton of confusion in regards to who will update them, since they are very focused on the business.   If the project is providing data to MDM, the data will need to be sourced.  If an ESB is present in the shop, its utilization must be considered. 

 

Pre-production testing will likely need to involve multiple teams.  Certainly, this is nothing new as many projects have had this need before.  However, it increases the need for coordination of personnel, environments and testing resources.  It is likely that each team will have its own set of tests, as well as the overall integrated test.

 

And finally, let's not forget good old production support.  MDM normally needs to be on a 24 x 7 x 365 support schedule.  Shops vary in terms of activity that might occur with MDM data overnight.  Regardless, production support carries with it all the usual concerns of utilizing and educating existing first level support personnel and creating the escalation plan.


Posted March 8, 2011 12:46 PM
Permalink | No Comments |

As applications discover the need to work with MDM for their projects to be successful, and the data and the parties are identified, the MDM team needs to be able to engage the requirement.  This is what I call setting up shop. 

 

You will need to balance structure and agility.

 

Early in the project's planning/research phase, a general conversation about the project and its data needs should be conducted with MDM Leadership.  As enough information is made available to complete the project plan tasks, the MDM team could provide the project team with the appropriate tasks for inclusion into their project plan.  A description of a superset of those tasks follows.   

 

All projects engaging MDM data need to share these documents with the MDM team or put MDM Leadership on outright sign-off for the following documents during the Requirements phase:

 

  • Business Requirements  
  • Non-functional Requirements  

 

The Business Requirements should contain diagrams and commentary on the interface(s) that the project will have to MDM.  Depending on your working model, either the MDM team or the application team provides the technical aspects of the application integration with MDM.  Figure out which in the manifesto or be prepared for MDM to be labeled "hard to work with."

MDM should also have a set of documents that it will maintain under revision or with a new document, for its purposes.  These documents include:

 

  • Business Requirements  
  • Functional Design  
  • Technical Specifications  
  • Non-functional requirements
  • Architectural Decisions
  • Data Model

 

The MDM team also needs to continually estimate if any new data will affect its available space (in all environments - development, QA, other pre-production and production) and begin the process to procure that space.


Posted February 19, 2011 9:39 AM
Permalink | No Comments |

Several MDM programs out there are in development and about to go to production.  Several others are struggling in production as they try to move the program into a second subject area or to engage more publishing or subscribing systems to the information.  Others need to extend the data governance beyond a single business group.

 

Few have made the leap to successfully setting up their MDM program as a fully functioning member of the 'major system' ecosystem of the company.  The guidelines in these blog entries will help those shops make that transition and address the questions that the REST of the company may have about MDM.  It is absolutely essential that MDM be properly positioned to these important evaluators of the program success.

 

Enterprise MDM cannot be successful "in a vacuum" - built to meet the need of a single application/subject area that is well-known.  Building MDM with this hyper-focus to the exclusion of all concerns for scalability results in just what I am seeing now: MDM re-dos and multiple MDMs where there could be one, enterprise MDM.

 

These questions include (again, from the perspective of those not in the MDM team):

 

What is MDM?

What data is available there?

Do I have to use MDM's data?

Do I really have to use MDM's data?  Who will care if I don't?

What if the MDM data is not suitable for my application needs?

How long does it take to incorporate my data?

Whose role is it to add data to MDM?

Is it push or pull?

I'm just going to bring this third-party data into my application, not MDM, OK?

Is my need an extension of a subject area or a new one?

Who do I talk to about MDM?

Do I have to contribute my data?

How do I modify the existing MDM workflows?

Does the MDM team carry a separate project plan for my need?

Who builds the plan and manages those tasks?

How do I unit test, do quality assurance testing, etc. with MDM data?

 

Just knowing these questions could trigger the necessary action, but in case it doesn't, I'll keep posting here (and you can as well) some tips to setting up shop with MDM.


Posted January 23, 2011 9:29 PM
Permalink | No Comments |
PREV 1 2 3 4 5

   VISIT MY EXPERT CHANNEL

Search this blog
Categories ›
Archives ›
Recent Entries ›