Many things related to AI and Data are about information technology (IT). Systems, platforms, development, operations, security, all are needed for creating value with AI and Data, and are traditionally in the realm of IT. Yet, AI and Data imply specific technologies requiring particular profiles and skills. It is, therefore, no wonder that many organizations struggle where to put those areas in their organization.
In an earlier publication, we discussed several alternatives that businesses have to “host” their Chief Data Officers. The conclusion was that the CDO is best placed in areas that are transversal to the business and matter to the business, for example, the Chief Operating Officer, the Chief Transformation Officer or the Chief Digital Officer. While this is an important organizational decision, wherever the CDO sits, he or she will always need to collaborate extensively with IT (usually the CIO). But what is the best relation between Data and AI on the one hand, and IT on the other hand?
Data and IT
Given that Big Data as an enterprise phenomenon exists longer than AI, there is more experience with the relation between Data and IT. Therefore, first, we will comment on the alternatives for the relation between Data and IT, and then bring AI into the discussion.
In Figure 2, Data is reporting to IT respecting its strong technological foundations. While this might be good to start data initiatives, since it is impossible to start data without technology, it lacks business as a driver of data. For this reason, most organizations are not using this structure today: they recognize that the value of data needs to be driven by business needs.
Figure 3 illustrates an alternative where the Data and IT departments report into independent parts of the organization. For instance, Data might report into the marketing area, whereas IT sits under the CIO. In such organizations, the relationship is a client-provider relation. This organizational structure usually causes many problems. Data is still a relatively new area and therefore needs many interactions with IT (install new software/libraries, modify permission, install updates, etc, etc.) Client-provider organizations function through a demand-management system with SLAs, and while that works for commodity IT programs, for (still) rapidly evolving technology this does not work since simple things might take weeks to complete. (for this reason, Gartner introduced the Bimodel approach for IT.)
In Figure 4, Data and IT are both reporting to the same “boss”. The benefit of this organizational structure is alignment and coordination by design, and in case there are problems, escalation is simple, fostering quick resolution. Organizations that are not constrained by legacy decisions and structures might opt for this approach.
In Figure 5, Data and IT are both reporting somewhere in the organization, but IT has reserved (ring-fenced) a dedicated group of IT people to focus on Data. To reinforce this focus, a dotted reporting line to Data can be introduced. There are several advantages of this structure:
- The Data area will be better served by IT because, in the normal case, it doesn’t have to compete with other IT priorities.
- It ensures alignment between the technology that Data is using with the strategic choice of IT.
- The Data IT people still are part of the larger IT organization allowing for training, rotating to other interesting IT projects, etc.
The disadvantages relate to the fact that sometimes the standard, approved IT technology might not be suitable for the rapid changing technology in the data space. Moreover, there are challenges with the teams. Do the Data IT people have Data or IT objectives? Or a mix of both? What happens in case the larger IT organization is under pressure. Will it still respect the Data focus, while it doesn’t necessarily see this effort reflected in its wider objectives? People in the Data IT team might also feel they have two bosses: their Data boss determining their daily work priorities, and their “administrative” IT boss who decides their bonus. If IT and Data get along well, there is no issue, but, unfortunately, in practice that is not always the case… One of the key factors in making this structure work is co-location of the Data and Data IT teams. While this doesn’t solve the HR problems, it does create a sense of belonging to one team, which helps smoothening the mentioned challenges.
Figure 6 illustrates the situation where Data and IT still report into different organizational units (as in Figure 5), but now the Data team has its own IT department, possibly with a dotted reporting line to IT. This structure has the same advantages of the previous structure and solves some of the challenges of the structure in Figure 5, notably, for the Data IT team it is now crystal clear who their boss is and who decides on their bonus. The disadvantage is the risk of a disconnect between technology used for Data versus the official IT technology standard. Moreover, it becomes harder for Data IT people to rotate to other interesting IT projects since they are formally not part of the IT organization. The dotted line will smoothen those issues to some extent, but they still need to be managed carefully.
And what about AI?
Data is fuelling many AI applications, and what is true for the relation between Data and IT is also true for the relation between AI and IT. What we currently see in the industry, however, is that some organizations set up completely new AI departments independent from Data departments. But since Data is a prerequisite for AI (at least for the part of AI that is based on Machine Learning), the same challenges we have discussed here will show up, along with the same alternative solutions. We wouldn’t be surprised, though, to see some political battlefields about whether AI should be a separate department or be merged with the Data department or maybe even absorb the Data area completely.