Join Alan Simon for an in-depth discussion in this video Maturity models, part of Big Data Foundations: Building Architecture and Teams.
- Maturity models can be a very important tool for you as you track your progress with Enterprise data management. They allow you to honestly answer questions along the lines of How well are we really doing with your enterprise data efforts? While it's true that you can track progress along your road map and the work plans for individual projects, they only tell part of the story. Those documents tell you what has been built and deployed at various stages. However, just because capabilities and components are available doesn't mean that they are being used to their fullest potential, or maybe even used at all.
You also won't be able to tell from road maps and project plans if your new capabilities have been accepted by business users and IT staff members. This is where maturity models can help. Maturity models present you with a small number of stages, typically somewhere between three and five, and then describe in detail what an organization at any given level looks like and how it acts, and then what has to occur to be able to move to the next level. In this simple example, we see a three stage model, and a company that's at level one can only move forward to level two by achieving whatever the model specifies.
If this seems like a work-intensive task to create a model for your organization, here's good news. There's plenty of enterprise data maturity models that are readily available from a variety of sources, and most are easily accessible via the internet. So review the ones that are out there and choose one that seems closest to what your particular enterprise data management initiative is trying to accomplish on behalf of your organization. You don't need to adopt it exactly as is, either. You can tailor the model that you choose as you need to include important facets for your enterprise that may not have been included in the one you selected.
As you do your searching, here are some guidelines to help you select a good maturity model as your baseline. A good maturity model fully describes what your organization should look like at that level. In this example, we see an organization that's at level three of this particular model, and has all of its master data management subjects in place with data stewards assigned. All of the subjects are being used for new projects. All of the data interchange code is now tool-based and is fully documented, standalone data marts are less than fifteen percent of the total reporting and analytical use across the enterpise, and so on.
But beyond what a given level shows, you also need direction for how to move from one level to the next. In this example, if your organization is at level two and your intentions are, as they should be, to progress to level three, you'll need to complete your master data management buildout. You'll also need to complete the buildout of your big data sandbox for experimental analytics. New processes to improve standalone data marts will have been put in place so they don't just keep popping up all over the enterprise. The data architecture training program will have been implemented, and so on.
As with every other artifact from your enterprise data efforts, going back to your score cards and continuing through your risk-management plans, you'll need to consult your completed maturity model frequently rather than create it once and then just forget about it. You also want to communicate progress to members of the enterprise data team as well as the organization as a whole. Doing so will help further demonstrate that your program is achieving what it set out to accomplish.
Join Alan Simon as he shows how to build a top-notch enterprise data team, evaluate your data architecture, solicit feedback from business users and IT staff, and create a plan to manage your data going forward. He helps you build a portfolio of projects that align with business needs, and migrate your current data into a more modern big data environment.
- Surveying the enterprise data landscape
- Building a data architecture team
- Selling the team
- Finding out what's working—and what's not—with scorecards
- Analyzing and reporting feedback results
- Modernizing your data architecture
- Refining and selling your data portfolio
- Evolving your data team