The Center of Excellence DataOps — Part 2
There is no one size fits all for business organizational models. Ask anyone which one is best and most often they will give you a different answer. One IT manager might argue that its cheaper and easier to be decentralized; meanwhile, another IT manager could argue that centralization offers more security and simpler deployments. No one model is better than the other in all areas, each one has its pros and cons.
This is part 2 of my Center of Excellence DataOps series, please read Part 1 here.
Organizational Models
The main two models we will look at are the centralized and decentralized.
In the centralized model, there is a main hub that all of the connections point to. When business is centralized, there is one individual that is responsible for approving the majority of decisions. In data analytic terms, there is a single data source that multiple dashboards use.
In the decentralized model, the connections can still be connected, but it is more limited — there is no main hub. The business is divided into smaller segments, or departments, and decisions are delegated. Decentralized organizations rely on teams and domain experts to make decisions. Again to use analytic terms, each dashboard would have its own independent data source.
Main Drivers
It is important to understand the typical reasons that drive creating, or to changing, organizational models.
The main drivers for centralization are usually compliance and standardization. Compliance can be an issue in regard to following corporate policies or internal and external regulations; Standardization is a problem when workforce change (growth or decrease) has outpaced the documentation of data definitions, programs, or processes. The desire to centralize walks in lockstep with the desire to have standard process and development guidelines.
For decentralization the drivers are generally domain expertise and speed. Domain expertise can be reduced or lost entirely in some centralized environments; Speed can become an issue when impacted by bureaucracy (ex. forms or multiple approval levels). The desire to decentralize is coupled with the desire to have on-demand development by local experts.
Pros and Cons
There are 5 key areas to evaluate when considering organizational models.
Personal vs Impersonal
High level centralization leads to an impersonal mindset: you are assigned the project, slice and dice the data, deliver the dashboard — then move on to the next project. In decentralized business models, there is a personal, or emotional, investment and analytics can be incorporated from the very beginning of the project. When analytics are embedded in the business unit/department, the project results are usually directly connected into KPIs used to determine bonus potential. This alignment of business unit ownership and project results can create a new problem: bias.
Analytic Bias
In decentralized models, the business units, or departments, are the project owners and the results of a project are often tied back into the KPIs used to determine bonuses for the year. This alignment has the potential to introduce bias into the project to make the data look better than it actually is. In analytics it is easy to cherry pick data to turn results to your favor. The analytic bias can be detrimental to a project in the short term and devastating to the entire business in the long term. It is important to follow the data with an open mind and not toward the desired outcomes. Being impersonal can help overcome analytic bias by adding more objectivity.
Process and Agility
A pain point in centralization models can often be the added bureaucracy — securing the necessary approvals to get projects started or to make any kind of change. Projects need to be triaged, added into the pipeline and have resources allocated. All of this red tape (or “blue tape” if you worked for IBM in the past) can reduce analysts creativity and slow growth. In decentralized models, projects may start and finish faster, but there is a high chance for a duplication of work and it may not follow regulatory polices or corporate standards and guidelines.
Redundancy and Productivity
Due to the lack of inter-department communications, decentralized analytic teams frequently duplicate projects and individuals learn new techniques without sharing to the broader audience. Centralized models dramatically reduces redundancy with the single stream of projects being shared into and out from the hub. There is more opportunity for knowledge sharing amongst a central team and offers more flexibility due to the wide skill range. The combination of knowledge and flexibility improves the utilization of resources which in turn allows the team to respond to more requests efficiently. The decentralized model also has the risk of no-backup analyst; what happens when the expert analyst leaves the company? A technical and knowledge gap develops and productivity will drop to 0. In today’s market it could be months (or even never in some cases) before someone with the same skills, or close to same, joins the team.
Small vs Big Picture
Analysts working within a particular department become domain experts at the risk of losing sight of the big picture. When working within a silo, it is hard to understand how projects fit into the greater business. Having a narrow scope, or looking at the small picture, can lead to focused results, but it can also be dangerous to the quality and overall relevance of the insights generated. Working in a silo can be detrimental to career growth prospects and job satisfaction — analysts can become stuck on a single track or become bored looking at the same information day-in and day-out.
A Center of Excellence
A high level of centralization might result in a never ending project that needs lifetime support from the analyst. Alternatively, a high level of decentralization might result in the same projects occurring at the same time in different departments. A more centralized approach to data analytics makes the most sense from the analyst perspective, but what is the right level?
A Center of Excellence is a great option as combines the best parts of centralization (objectivity, standardization, and redundancy protections) and the best parts of decentralization (domain experts and rapid solution deployment). CoE streamlines standards without completely eliminating the decentralized teams.
No one wants to completely overhaul the organizational structure large scale enterprises — that would be a HR nightmare. The creation of a new Center of Excellence works best on a small scale; a group of specialists that look for small wins across the wider organization by showing the departments what great looks like; developing the standards and best practices for business units to use. Likely there are already individuals within the company actively trying to find a better way, or a new way, of doing things.
The goal is to bring many view points together to foster growth and creativity, while also standardizing processes. A Center of Excellence DataOps team means that no one person needs to have the entire answer, each person will have a part of the solution.
Say it louder for the people in the back:
Data Science is a team sport.
I am always curious to know what other companies are doing with their data science and analytics teams.
- How does your company foster growth and creativity?
- Does the Analytics group operate as a team or as a collection of specialists?
