SUBSCRIBE NOW!

Vol. 37 No. 7 — October 2020

The initial cause of these failures is that IT staffers and senior IT executives tend to operate by default on the implicit assumption that business stakeholders understand data as an infrastructure asset. Many business executives actually believe that they understand it as well. Many, in fact, do comprehend it conceptually in a business vacuum, in which there are no real-world competing priorities or commitments to data architecture that will require multiple budget cycles to fulfill. This perceived mutual understanding virtually always leads to IT having to communicate with the business—as if data were a product that the business is eagerly awaiting delivery of and that IT has to tackle.

I had the great fortune, last December, of moderating a session on master data management (MDM) and data governance challenges at a forum of about 60 CIOs in the Western U.S. Despite their industries, they were quite unified in expressing their difficulties in justifying these and other data management disciplines and technologies to their counterparts in their respective businesses. It occurred to me to ask them, “If your IT architects decided at some point that point-to-point system integrations had become prohibitively inefficient as your IT ecosystem has grown, and you agreed with them that an enterprise service bus (ESB) [communication system] was now an appropriate infrastructure investment, would you then attempt to explain that to your business stakeholders?” Of course, the response was a resounding “No.” I proposed that data management (in the way that IT means it) is actually similar in relation to business comprehension to something like an ESB.

The exception was that in the case of data, IT and the business implicitly believe that they have a common understanding of both the costs and benefits of managing it. In actuality, this common understanding either does not exist or is sufficiently tenuous that any business disruption, no matter how small, will be enough to derail any planned or in-flight datacentric initiatives.

DATA AS AN INFRASTRUCTURE ASSET

The argument can be made that the business would and should know enough to demand that an ESB be implemented, but that the world is full of businesspeople at all levels who blame poor data quality for inefficient business processes, inaccurate analytics, and the inability to innovate. I would respond that in both cases, the complaints usually originate from the suboptimal business results that manifest. In the case of the ESB requirement, there are likely complaints of IT delivery of system integrations taking too long, being too expensive, and lacking initial quality from the business’ perspective. In the case of data, the complaints usually start with broken processes or analytics that apparently cannot be improved and/or the inability to create new processes and analytics in the service of initiatives such as digital transformation.

The symptoms of these scenarios are usually not obvious to the innocent bystander, but when asking varying levels of business stakeholders why they felt that they needed to embark on a data management journey, there were several amorphous themes, in order of increasing frequency and insidiousness: dirty data, poor decision making, a lack of cohesion, and needing a 360-degree view of the customer. I would also include “building a datacentric culture” in this list when it is stated broadly and without real business context, as it often is today.

The converse of this scenario, which I eventually learned to live by as an industry analyst and advisor—and now as an MDM strategist at a software vendor—is that the only way to solidly and sustainably justify data management to the business over time is to treat data as an infrastructure asset. Similar to an ESB as an example, limiting the communication to business stakeholders to the outcomes in the data management journey will result in their operational and analytical benefit.

Include only as much technology information as the business needs to buy into, and eventually adopt the changes that will directly affect it—which may be none in some organizations. This will lead to a real-world, datacentric culture, wherein a common understanding of the critical role that data plays in an organization’s processes and analytics really exists and provides business value to every initiative—up to and including digital transformation of the business.

The collective mental shift that needs to take place in most organizations in order to see data solely through the lens of desired business outcomes and value is not easy. I have worked with dozens of business and IT teams that academically understand everything that’s been described here, but that still struggle mightily to put these behaviors into practice. For example, assuming that the business can identify what it would actually like to achieve, IT then builds a proposal to profile and analyze the data in every system that IT believes may apply, rather than starting by building data models around just those entities and attributes that are necessary to deliver the identified outcomes and then mapping those models only to the applicable sources, entities, and attributes. The latter approach—which I’ve often described as “going from the front to the back”—has multiple advantages. Not only does it constrain the scope of any analysis to just the business issues at hand, but it also keeps construction costs to a minimum and delivers visible results over a shorter time period. Further, it keeps the business stakeholders engaged, because they see that the pain points as well as opportunities for innovation are being directly addressed from a functional standpoint as they are invited to demonstrations and training sessions for new and improved capabilities.

TIPS FOR FLIPPING THE SCRIPT

I have developed several techniques over the years to help business and IT teams focus on data as an infrastructure asset rather than as an end product. Multiple organizations have found the following tips to be helpful:

• Avoid the word “data”—Try to list and describe the operational and/or analytical outcomes you want or expect from your data management initiative without saying the word. It is often difficult or even impossible for teams that are not in the right place to do this at first. Instead, position it in terms of a real business outcome: “We want to increase our customer onboarding rate by a factor of three, using the same or fewer resources, while reducing our onboarding error rate by 80%.”
• Subtly generate buy-in—Start from the assumption that the way your organization currently operates is the optimal way for the foreseeable future. This is not to mean that things cannot be improved, but that any direct, indirect, or opportunity costs associated with making even the smallest improvement related to the associated data would be less than the benefits achieved. Usually when this is proposed, everyone involved will list all of the reasons this assumption is not only untrue, but patently ridiculous. If you can subject the reasons given to the rule in the previous bullet point, you will likely be on your way.

If these two techniques fail to produce the desired result, the deficiency in the current approach can often be overcome by IT asking the business this: “Imagine that we obtained agreement on all of the data definitions, cleaned up all of the data accordingly, and built that 360-degree view, all over this weekend. What would you do starting Monday morning?” Usually, the answers either reveal much about the desired business state, or the silence is deafening. In either case, it is a great step forward.