With the growing trends of BYOD (bring your own device), SaaS (software as a service), and cloud services in general, I felt the blog post below from Thomas Redman, Ph.D., in the Harvard Business Review Blog Network was topical.
Just as IT services in general are becoming less centralized within organizations, so too will the policies that affect how applications are used and data is managed and stored.
While loosening the grip often runs counter to what IT executives have long embraced, resisting decentralization is akin to fighting the tide: good luck with that.
Feedback welcome; we’re all in this together.
Emphasis in red added by me.
Brian Wood, VP Marketing
Manage Data with Organizational Structure
Organizations need to get responsibility for data out of IT, as I argued in my last post. Most commenters agreed. Quite naturally, a few wondered where to put that responsibility. I did hint at a federated approach, though I provided no details whatsoever. Here I provide a few. In particular, I find people management provides a good model for getting started.
The feature of people management that strikes me most is how the work is split up and gets everyone involved. Human Resources groups have many line responsibilities of their own, such as succession planning, setting pay scales, and selecting the benefits package. They also work with other departments to help hire and train the human capabilities they need. That said, most people management is actually done in the course of day-in, day-out work, by managers and employees. HR may very well define the semiannual performance review process, provide the needed forms, and make sure it is carried out. But performance assessment is completed by employees and managers.
This last point strikes at the heart of the federated model. Corporate HR sets policy; department HR may modify it in accordance with specific needs; and departments, managers, and employees carry out these policies. Most have a certain degree of latitude in how they do so.
What does the division of work suggest for data? As with people management, most of the work to create, store, manipulate, use, and deliver data to customers is conducted by people within processes and departments, and they must be fully engaged. Practically everyone is both a data creator and customer. This is where the real work of managing data and putting it to work lies. And it is where much responsibility for data must lie.
Corporate and departmental data groups (DGs) should set and administer policy that help individuals, processes, and departments understand and meet these responsibilities to high standards. For example, a data quality policy must dictate that data creators create data in accordance with the needs of those who use the data and that data customers clarify those needs.
In addition to its policy-setting role, the corporate DG has at least two critical functions all its own. Some data are of special importance because they are uniquely the company’s own, providing potential for sustained competitive advantage. The corporate DG has a special role in identifying, protecting, and enriching these data.
The corporate DG must also own the end-to-end metadata processes. It is easy to dismiss metadata as so much technical arcana, but some metadata, including data definitions, data models, some standards, provenance, and usage restrictions, can be extremely important. Done well, metadata makes it easier to for everyone else to understand, trust, and share data.
Departmental DGs help their assigned department acquire and/or create the variety and depth of data they need. They may work directly with external suppliers, measure quality levels against policy dictates, lead improvement projects, and help qualify data-enabling technologies.
In some companies, high-powered data scientists, architects, and others report into such departmental DGs. This is most appropriate when analytic work should be “close to, but not in the line.” In other companies (and as I’ve advised), those seeking to make industry-changing discoveries should organize their data scientists away from the line, in their equivalent of a “laboratory.”
Clearly, there is a lot of work to be done. Based on quality management in manufacturing, the efforts of leading data companies, what worked at the great Bell Laboratories, and the utility of the HR model, my current best guess is that about 2% of a leading company’s employee base will report into a corporate DG, departmental DGs, and the data lab. While data scientists attract the most attention, people in a variety of specialties, including quality, modeling, architecture, data management technologies, and some we’ve yet to label, will be needed.
Taken together, these points represent a sea change in thinking, particularly for those whose most senior data person is a technical architect, buried deep in the bowels of IT. This will not do. Just as the head of HR is among the top few people in a company, data requires very senior leadership. Fueled in part by the advances of big data, a full-scale data revolution is brewing. People and organizations are beginning to more fully appreciate that all data, not just big data, are assets of enormous potential. Accelerating that understanding, building the needed organizational capabilities discussed here, and focusing the effort is an important job and motivates the call for a true C-level Chief Data Officer.
I think many will find the 2% figure, indeed, this entire post, shocking. And after they reflect, I hope they realize just how urgently these subjects demand attention. In times of great change, fortune favors the bold. Carpe diem!