Building an enterprise data program can be a struggle. You want to offer data services to application projects that need the data you plan to deliver, but budgets and schedules are set, with data collection already within scope of the application projects. The idea of suggesting significant changes to projects in motion is not a pleasant prospect. What can you do? Should you just deliver “important” data – disconnected from any specific application projects – in the hopes that the data will be used in the future? Should you stand by while multiple teams redundantly collect, refine, and integrate data yet again from the same sources that have already been tapped dozens of times? Maybe it’s best to just find your own separate business value for a few important reports instead of supporting application projects within the most important business initiatives of the company. (It isn’t.)
If you want to get started with an enterprise approach quickly and correctly, I’m afraid there’s no choice but to have some of these difficult conversations in the short run. But after that initial unpleasantness, you can establish systemic processes, linked to the organizational machinery, so that data planning takes place right alongside business and application planning, with effective implementation naturally following. No more running next to a moving train hoping to jump on safely.
Every organization has functions in place that offer linkage opportunities for enterprise data planning and implementation. Connecting to these functions allows rationalized data deployment to become an intrinsic component of the organization’s operation.
When examining these functions, you need to evaluate two things. First, how mature is the function? If an architecture review board, for example, does nothing more than rubber stamp every project that comes along, you’ll need to address that before asking it to ensure that enterprise data is used appropriately. That’s the second thing – to look for the specific opportunity to enable enterprise data within the function.
Here are some functions that exist in one form or another in every large organization, all of which should be leveraged to enable enterprise data planning and implementation.
Strategic planning. Strategic planning is the process that plans business improvements – both organizational and technical – as far into the future as possible, typically three to five years, but sometimes as much as ten years or more. Since strategic planning produces the most important business initiatives of the company by definition, participating in this process to provide advice regarding the use of data and to plan data deployment in support of the initiatives is the best way to create true business alignment from the beginning. That’s the right way to create a data strategy. For example, if the marketing department is planning a customer journey initiative, it’s easy to see that it will have substantial data needs. Planning for the data alongside the initiative supports the business vision for marketing and positions the data (sales, customer, product, etc.) as an enterprise resource likely to be needed by other initiatives, such as supply chain optimization or field sales enablement.
Project funding. Most organizations have an annual (or sometimes more frequent) process to fund projects for the coming year. This is both a translation of the strategic plan into near-term projects and an opportunity to justify new or one-off projects. This funneling of projects allows you to review the projects on the list and propose corresponding data and data management projects to support them. You should work with IT business liaisons representing various business functions so that the scope of application projects they propose does not include deployment of enterprise data at the outset. The project management office (PMO) should have a mechanism to track formal dependencies between projects, which should be used to link your data projects to the application projects sponsored by the business functions. (If you are planning data projects without any linkage to one or more application projects, this is an opportunity to correct that serious deficiency.)
Enterprise architecture. Enterprise architecture functions look for common needs across projects and offer capabilities to serve them. Although formal “textbook” enterprise architecture methodologies always include reference to shared data, in many organizations the actual function is limited to promoting technical standards. Since your goal is to share data across projects and applications, the enterprise architecture function should include concern for data just as it is concerned for technology. Any governing mechanisms, such as an architecture review board with its various checkpoints, should include ensuring that shared data resources are leveraged appropriately by application projects and that those resources will be available at the right time and in the right condition by your data projects.
Solution development life cycle (SDLC). Whether agile, waterfall, or something in between, IT projects typically have a standard set of recommended activities, roles, artifacts, standards, and other guidance. Data deployment projects – in service to application projects – should follow the standard SDLC with some variations. This special version should reference the guidance that applies to all projects while also including activities specific to enterprise data deployment, such as data quality profiling to examine data quality issues in support of in-scope applications, logical data modeling and information requirements to meet the needs of the supported applications and to extend and refine the existing models, the role of the data steward in data management activities, and so on. In this way, data management practices are effectively institutionalized and, by applying the practices to data deployment projects that have themselves been positioned in support of important application projects, the value of the practices is clear because they directly support funded business initiatives.
Other functions, some of which may be unique to the organization, should be examined for linkage opportunities in this same way.
Once built, this machinery makes planning and deployment of enterprise data much easier. While I can’t promise a stress-free enterprise data program, I can guarantee that linking to organizational functions in this way significantly reduces disruption and political struggles and gives you the greatest possible chance of aligning to the business the right way while building coherent data resources at the same time.