Who's Who in the AI Zoo: Understanding AI Roles
AI Delivery Series: Understanding AI roles in the context of systems engineering helps better engage resources and understand expectations
This post is part of a series that will enumerate how systems engineering approaches, married with agile and lean techniques, enable AI delivery so it can meet or exceed strategic organizational needs.
Do Roles Matter?
Many agile efforts staff their projects with specializing generalists - engineers that have deep expertise in one area, but serviceable expertise in many others. On projects with tried-and-true approaches, full stack developers fit this definition and can often fill any project role with acceptable fluency. For instance, a typical full stack developer can build user interfaces and microservices, configure databases, as well as create DevOps capabilities ably - even if their primary skill only covers one of these areas.
Having a team of specializing generalists does not preclude projects from leveraging specialized skills from time to time. A project, for example, may engage a User Experience (UX) expert to help with usability or a Kubernetes expert to help them adopt an infrastructure as a code practices.
When we can leverage specializing generalists, it often makes sense to do so. However, it’s equally important to know when an effort can benefit from leveraging a specialist. But what happens when we mis-label one of these resources? This challenge, referred to as role confusion, occurs frequently when there is a misunderstanding by employers and/or employee about the nature of a role. Role confusion can lead to positive outcomes with a resource growing into an opportunity. Other times, it creates project/employee stress, misaligned salary-to-skill ratio challenges, and underwhelming results.
Role Confusion is Especially Challenging on AI Projects
Given its relatively nascent nature, AI projects suffer from role confusion more acutely than traditional projects. This is due to the lack of clarity between various AI roles, misaligned understanding of the skills needed to play each of these roles, and limited run time for the industry to settle on common expectations. Polling AI project teams on role definitions will produce wide ranging results within each team - and that problem multiplies when tested across different AI project teams.
With demand for AI resources spiking, role confusion is exacerbated by hiring managers, recruiters, and interviewers. The result is projects often treating anyone that knows Python like a Data Scientist, Machine Learning Engineer (MLE), and/or MLOps specialist.
AI Roles Map Closely to Traditional Roles
Fortunately, getting a working understanding of how AI roles can be applied is relatively straightforward for those with prior software delivery experience. The following mapping helps lay the groundwork for how AI roles can notionally slot into standard systems engineering responsibilities. It also highlights some key opportunities where AI roles are missing coverage against typical systems engineering roles. Some resources can reasonably stretch as effective specializing generalists across all these roles; however, these superstars are outside the industry norm. The better we understand role expectations, the better we can find the right resources for focused and generalized roles.
The following diagram maps similar high-level roles between AI and traditional software projects. These are not perfect mappings but can help conceptualize responsibilities and how these roles can more optimally into a systems engineering driven delivery approach.
It is worth noting the AI roles discussed below are just one perspective. The goal is less to achieve an exact role mapping and more about how to slot AI responsibilities into traditional roles to enable high quality delivery.
Data Scientist as Architect
Data Scientists are typically skilled in the major muscle movements of Machine Learning - statistics, model selection, and experimentation. They often are responsible for surveying data for appropriateness, finding applicable models, and setting up the design and/or prototype ML approach for a project. This role has substantial conceptual systems engineering overlap with Architects, who fit patterns and technologies to meet system requirements via a candidate architecture. Both establish high level patterns and often support the initial implementation in a hands-on fashion.
Machine Leaning Engineer (MLE) & Data Engineer as Developer
MLEs are often leveraged on projects to iterate on / realize approaches laid out by the team’s Data Scientist(s). This can range from Data Scientist-like experimentation to hardening of prototypes and much more. MLEs often have a broad set of responsibilities and are engaged for both prototyping and final product delivery activities.
Data Engineers are responsible for providing the data needed to fuel data science. While not directly data science, activities like data ingest, shaping, and profiling data probably represents a majority or at least over half of a typical AI delivery effort. Data Engineers often are responsible for building pipelines to make data available based on Data Scientist needs as well as hardening last-mile Data Preparation activities needed to fit data into the input parameters required by specific ML models (a.k.a., machine learning features).
Software developers typically work closely with an Architect to implement their vision in both a collaborative and directed fashion, taking an architecture or design, and flushing it out into delivered source code.
All three roles work on the elaboration and construction of plans typically laid out by a Data Scientist/Architect. At the same time, they are normally less involved in and responsible for creating the plan than the Data Scientist/Architect.
MLOps Engineer as DevOps Engineer
In perhaps the most direct mapping, an MLOps and DevOps engineer have a substantial amount of overlap. The key being that MLOps engineers apply DevOps practices to the specific machine learning lifecycles.
While some consider MLOps more runtime-driven than standard DevOps, there is perhaps less differentiation between the roles in practice. Compared to DevOps on projects that leverage Blue-Green deployment practices, DevOps also directly deals with runtime data collection and conditional logic to trigger redeployment in a similar fashion to MLOps.
How Do AI Projects Handle Business Analysts?
One potential gap in how AI projects are executed is the lack mapping to a traditional Business Analyst (BA) role. Typically, this role helps define requirements as well as perform testing. In AI projects, however, Data Scientists typically determine the art of the possible in terms of what the available data can support. There is a chicken and the egg challenge with this approach which will be the subject of our next blog post - To Start with Data or Requirements, That is the Question.
Slow is Smooth, Smooth is Fast
Now that we have a sense of how AI roles roughly map into traditional systems engineering terminology, how does it help execute a project?
First, we can now start to leverage systems engineering patterns to determine when we need different roles available during a typical project execution. Data Scientist involvement, for instance, is critical in the early stages of an AI project’s execution but might be less labor intensive as the project moves into a construction focus. Similarly, some MLOps representation early is useful, but expanding this support is critical as the project executes. How disciplines, and thus roles, tend to engage during a project’s lifecycle can be visualized in the RUP Hump Chart that was included in our prior post.
Perhaps more importantly, we can start to better understand the handoffs between roles. As the Navy Seals note with their “slow is smooth, smooth is fast” mantra, high quality results come from doing your job well and in coordinated fashion with your team. This approach is also referred to as “go slow to go fast”. The more efficiently an AI team works together with aligned tasking and a common understanding at the seams of responsibilities, the better they can achieve breakthrough results.
Working to help AI efforts adopt the tactics of software teams (e.g., strong design, object orientation, testing) is core opportunity to achieving this vision; these tactics slow down initial progress but are the core enabler for high velocity projects meeting their strategic goals. Understanding how AI roles play into achieving these tactics is critical to unlocking breakthrough delivery.
Up Next
With a more solid understanding of why roles matter and how to mind-map AI roles with traditional software roles, we are ready to get into the core of how systems engineering can improve AI system delivery.
We’ll start at the traditional beginning of projects - requirements definition. However, as we’ll discuss in To Start with Data or Requirements, That is the Question, requirements are not always point zero in AI delivery - and sometimes this makes sense. We’ll also hit the need for lean delivery best practices to balance getting just enough data available to identify and validate requirements.
Blog Series Links:
Who's Who in the AI Zoo: Understanding AI Roles (this post)
Incepting Artificial Intelligence (AI) Efforts with an AI Systems Engineering Mindset