Why Should Project Managers Know Data Management?

It is not surprising that most data management professionals at some point in time in their career have either played the role of an IT project manager or have worked as one in an official capacity.

In IT most technical changes including data related changes are implemented through a project in one form or another.  Now if we accept the notation that change is a constant reality in today’s businesses, then that means most technical changes in an organization may be implemented through a project.

Most if not all IT projects have some data impact or are impacted by data.  That is, whether they are rolling out a new software solution, hardware solution, reporting, integration, migration, and others, there are elements of data tasks involved.  These projects often require a delicate balance between complex tasks in data management domain.  For example, a software implementation project would need data architecture, migration, integration, quality, and governance.  This translate to many tasks and many resources as well as dependencies.

A project manager must manage all these tasks and understand their impact on resourcing, budget, timeline, solution, and much more!  Most IT projects can easily fail to meet these demands when one of these moving parts is out of order.

Project managers who understand these data management principles can clearly understand what is required in each phase and what to look out for.  They can manage expectation and impact with project sponsors and stakeholders to ensure a successful and smooth project delivery.

It is because of this that we recently developed a very specific data management training for IT project managers to train them in the fundamentals of data management as well as specific types of projects that they will be dealing with.  They can now use the same tools and techniques we use in data management to ensure a successful delivery of data solutions in their IT projects.

Last week we delivered the first of these training sessions in Indianapolis and it was attended by a number of seasoned project managers who found it to be extremely valuable (according to their survey and interactive feedback).  We are offering another one in Newport Beach, CA in September.  The goal is to have at least one per month in different cities.

If you are interested in learning more about these classes, you can go to our training page.


Till next time!

Majd Izadian

Copyright 2013, Zendeux Business Data Solutions

Data Project Management OC2

Big Data, New Hype, or New Reality?

IT industry is not immune to the “New Shining Object Syndrome” that impacts other industries as well as consumers.  Every once in a while we get a new technology or idea that grabs the attention of IT professionals and CIOs alike.

There have been many examples of these new ideas, some of which have endured the test of time and some that have not.  There was once a huge excitement around Object Oriented Programming (OOP), SOA (Service Oriented Architecture), BI (Business Intelligence), ASP (Application Service Provider), Master Data Management (MDM), and now Big Data!  Some of these ideas like OOP have been observed into the way we write our software where we no longer call it that.  ASP (not the same as Active Server Pages) has evolved into SAAS (Software As a Service) and hardly anyone remembers about ASP anymore.

Big Data however, has created a huge buzz lately and the excitement is very contagious and seems to have gotten the attention of the media much more than the previous trends.  The reason may be that unlike those other technical breakthroughs in the IT industry, this one has a strong business and even consumer impact.  Though many do not clearly understand what Big Data means, they have by now a vague notion that it somehow involves or impacts them.

News such as the NSA’s (National Security Agency) tapping into the metadata of domestic and intentional phone communications to Google, Amazon, and other companies profiling consumer’s every click on the web has awaken fear and excitement in normal consumers.  For this reason alone, it is no longer easy to ignore Big Data as a mere hype or “new shining object”, but perhaps a new reality which we are all forced to be reckoned with.

Big data itself and its potential is more analogous to the internet at its early days where only few understood its immediate potential and perhaps none could forecast its future potentials.  Like the internet, the early days of Big Data is only accessible to few and far in between, and like the internet, unless it is readily available to the common man, it will not fulfill its full potential and depth.

Therefore, if I were a betting man, I would bet on the Big Data.  But one should be weary of the hype, as like the internet, Big Data could find many .COM victims who may be blinded by the “new shining object” without knowing its risks and potentials of what makes it shine!

Copyright, 2013, Majd Izadian, CEO Zendeux Business Data Solutions

Big Data, Hype or Reality?

To MDM or not to MDM, Part 2

As I discussed in Part 1 portion of this blog, MDM is not a tool, but rather is a discipline that can be implemented in an organization through a program. And MDM Program could leverage a solution (referred to it as an MDM Platform) to help manage master data. So what is an MDM Platform made of? Before I answer that, I would like to point out again that an MDM Program is not single dimensional but rather has 4 dimensions as I listed in Part 1:

  • Framework
  • Architecture
  • Process
  • Governance

Therefore, any solution for MDM should be made of components that correspond to these dimensions. Also since these dimensions are related, the components need to be designed in an integrated fashion.

An MDM platform then has the following components:

  • Data Governance – Includes data stewardship, change management, policies, standards, communication, and workflow functionality
  • Data Quality – Data profiling, validation, search before create, integration ability with 3rdparty validation services
  • Standard CRUD Services – Provides data services based on standard CRUD processes with encapsulation of business rules and DQ validation and Data Governance
  • Master Data IntegrationLayer – Common data integration layer for ETL and access by downstream systems manageable by governance rules for data usage
  • Single Master Data Source – A single data repository for master data attributes as the source for creation and access
  • Single Master Data Architecture – A common data architecture for every master data object in alignment with business processes that ensures uniqueness and scalability.

Now, when we look at the list of MDM Platform components above, we can see that each can have a great deal of functionalities that can enable the management of master data. Each component’s functionality can be implemented in a variety of ways using different technologies and techniques. For example, Data Quality has much functionality associated to it and there are a lot of vendors that use different technologies and approaches to provide different solutions. That is true for data integration and all other components as well.

Before we get into the tools options, I think we need to address the different solution implementation. It is important to note at this point though that an effective MDM Program (and thus an MDM Platform) should have all these components in an integrated fashion to address most or all of an MDM Program’s need. There are tools that offer all the components in an integrated fashion. There are also vendors that offer only specific components in the above list. So what are your options? In general there are three approaches to MDM Platform implementation:

OPTION A: Full Vendor MDM Tool Implementation
IMPACT: Replacement of all existing MDM Solutions and Repositories, replacing all existing data integration for Master Data. More holistic, but very expensive and may not be scalable for future technology as components are tightly coupled

OPTION B: Full in House MDM Tool Build
IMPACT: Incremental deployment, replacing only some of the existing data integration for Master Data. Less expensive in short run but expensive in long term and will not scale as well we the components that are offered by industry core competency

OPTION C: Integrated Best of Breed MDM Platform
IMPACT: Leverages existing usable components and repositories. Uses best of breed for each component but integrate tightly through SOA. Less impact on IT and business, can be implemented incrementally, scalable as components can be replaced for future technology without impacting the solution

Having come from a business solution architecture background, it has been proven to me that an integrated solution of components is always better than tightly coupled solutions or functionalities. The architecture of integrated architecture is more flexible and scalable. It is flexible in a sense that it would allow you to pick the best current or future functionality and technology to support it without breaking the whole solution. It is scalable because it allows you to scale your solution to more functionalities and integration to other components, applications, or systems without impacting the integrity of the solution as a whole. But clearly this choice is requires careful architectural analysis as well. Sometimes the existing Architecture has already integrated the master data with ERP’s transactional functionality so tightly that it would be very costly to introduce new or external components to the mix. Also, there are ERP systems whose data models are not normalized (or even normal J) enough to allow easy integration of other best of breed components. Sorry, can’t name names!

So in conclusion, yes, I would say you must MDM, but MDM it right! Understand what MDM is and what it means to your organization. Then try to educate your executives or peers to understand that MDM should be an integral part of the company’s operation and culture. And make sure that you don’t make the mistake of thinking that MDM covers all your data management needs. Master data is important, but it is not all the data that you need to manage in your company.

Finally, in reality, master data management can be done without any fancy tools, but the tools will just makes things easier and more scalable. I am a firm believer that Information Management has existed way before technology has. If you can wrap your mind around that concept, then technology becomes your friend and you would think clearly when choosing the right vendor or tool for your data management needs.

But perhaps that is the subject for another blog! 🙂

(Original publish and Copyright date 2011 © Majd Izadian)

To MDM or Not to MDM, Part 1

I once told an executive of a very large company who asked me about MDM tools that, “Most MDM tools are scams!” Ok, I may have made some people unhappy with that statement, but what I mean as I explained further to him was that, MDM is not a tool, it is a program based on disciplines. It is true that many vendors may like to introduce MDM as a tool, nicely packaged in box, that once installed can solve all of your master data problems. Actually my beef is with that group of vendors, because in my view saying MDM is a tool oversimplifies it. The problem comes when some poor soul in some data management organization is trying very hard (and for all the right reasons) to sell their executives the idea of MDM. At that point their executives are then bombarded by calls from sales guys from MDM “tool” vendors that tell them they have their magic pill ready to swallow. These solutions normally mean an entire degutting of what they already have – whether it is necessary or not- and replacing it with a fancy MDM tool. The executive who asked me that question was actually in the same dilemma. He has been approached by large vendors that have been pushing hard to implement an MDM tool as a solution to their MDM problems.

It is very important to know the difference between several concepts when it comes to MDM solutions. Let’s start by introducing you to them. Master Data – represents information about objects (things) that exist independent of transactions and can play different roles in a number of processes within or between organizations. (I left systems out intentionally) Master Data Management- includes all processes, standards, methodologies, policies, roles, and tools that are used to ensure master data quality, consistency, uniqueness, and performance for all impacted stakeholders including but not limited to business transactions, reporting, and integration. A Master Data Management Platform*- is a solution that facilitates Master Data Management implementation by providing integrated and orchestrated functionalities, capabilities, and technologies for master data architecture, quality, governance, integration, services, and System of Record. (*Platform does not imply a tool, it implies a solution.) A Master Data Management Tool- is a solution provided by a vendor which combines several components of a Master Data Management Platform and usually is designed for specific master data objects (Oracle PIM, SAP MDM, Siperian MDM, and many more). Therefore, there is a clear distinction between MDM as a program, MDM as a platform, and MDM as a tool. What most companies need first is a program and not a tool. An MDM program will address more fundamental questions in the business and IT landscape of a company than just what is, where master data should reside, or how it should be entered. It also becomes deeply rooted into an overall Information and Solution Architecture of a company as well as processes and culture. So, what is in the scope of an MDM Program? In general, I break the MDM scope into four parts: 1. Framework 2. Architecture 3. Process 4. Governance Each of these is divided into their own sub items that further describe how an MDM program should be established which is a little beyond this blog. But the idea is that a program to manage master data in a company is multi-dimensional where each dimension deserves thoughtful planning, execution, and an ongoing operation. In my next blog, I will begin to describe the components of an MDM platform and solution. As you can guess by now, platform solution definition comes before choosing a tool! 🙂

-(originally publish and copyright date 2011, Majd Izadian)