Imagine for a moment that you’re an out of work police officer searching for a new gig. What do you do? After calling all of your police mates, you hit the job boards and search for police officer openings. Dozens of results are returned, and you start reading job descriptions. At least 2 years of experience required. Duties include patrolling the shopping centre as well as the car park. Unfazed, you scroll to the next one. Ensures order in the corridors between classes and checks student hall passes. What! You’d be frustrated. Clearly, these are positions for Paul Blart Mall Cop and hall pass monitor, so why were they listed under Police Officer.
In this segment, I provide a glossary of job titles to clarify what they are, which is to say, ‘what is the scope of the role’, and what are they not. Unfortunately, the Police Officer scenario is not as far-fetched as you might have imagined.
My interest here is to differentiate various analyst and architect roles. We’ll begin with the role of a Business Analyst. I am speaking in a software context, so not a financial analyst. A Business Analyst should have a strong sense of cost-benefits, options and trade-offs, the BA is focused on delivering solutions specific to a software application or applications.
Although there are different flavours of BA’s,
they share common aspects
Although there are different flavours of BA’s, they share common aspects, even if the specifics of the roles target different elements of the solution. Where Architect roles are strategic, Analyst roles are tactical and focused on an application, a system, or a part of the system rather than the system as a whole. BAs elicit and document requirements through direct enquiry with customers, users, product owners, and in some cases other BAs. If the application relies on other systems, whether receiving inputs and sending outputs, this needs to be accounted for. A BA creates acceptance criteria to signal the developer when a feature has been satisfactorily implemented. The BA may also provide direction around speed and performance requirements.
Let’s discuss various BA flavours.
A Functional Analyst is a BA with a particular focus, unsurprisingly, on the feature functionality of an application. From a business perspective, what does it do? What task needs to be accomplished? How might it be improved or made more efficient?
A Process Analyst is a BA with a particular focus on business processes. Typically, this role will be scoped into a system and tasked with increasing the efficiency or decreasing the complexity of the system. This might result in a need for new feature functionality, but usually the process itself can be tweaked. At a higher level, a Process Analyst might rationalise systems to reduce redundancy and perhaps consolidate disparate systems.
A Technical Analyst is a BA who focuses, obviously, on technical specifics on a level much deeper than a traditional functional analyst might. Typically, a Technical Analyst translates functional specifications into technical specifications.
In many companies, these roles are rolled into a single Business Analyst title, but this lack of role specificity can yield some inferior results because you are now asking for a person to have three competencies that are unlikely to present themselves at the same level.
A Business Systems Analyst is usually a BA assigned to a particular enterprise system, be it Salesforce, NetSuite, or some other such system.
Let’s change to another title: Project Manager.
But wait. If you are asking yourself, what does a Project Manager have to do with a Business Analysis, you’re paying attention. I include it here because I’ve seen so many job descriptions combining these roles. This is a sign of an immature organisation asking for failure. And if they don’t fail outright, this combination will ensure delivery happens at a snail’s pace.
If you are combining [BA and PM] roles, my advice is to stop.
It creates a distraction, friction, and a conflict of interest.
Where the role of a BA is to explore solutions and make recommendations, the role of a PM is to take an inventory of recommended solutions and ensure they are delivered on time, on budget, and of expected quality. If you are combining these roles, my advice is to stop. It creates a distraction, friction, and a conflict of interest.
One last bit of advice for PMs. If a PM is managing more than 2 projects, they are not actually managing these projects. It would be foolish to believe this could happen.
Let’s take a look at various architectural roles.
Not at the top, but perhaps the most obvious is the Enterprise Architect.
The Enterprise Architect is a strategic technology position with a purview of the enterprise holistically. This person needs to understand the business, but the main concerns are system interoperability, overall performance, and extensibility. The role does not implement solutions.
The Business Architect activates business strategy
The Business Architect activates business strategy in deference to the enterprise and its myriad internal functions. This role is responsible for creating a governable paradigm and rules of engagement. A Business Architect is not responsible for envisioning or developing system or application solutions. At the highest level and from the perspective of the business rather than the technology, it maps functional processes and value streams.
I’d be remiss not to note here that many organisations misapply the Business Architect title to senior Business Analysts. This is most likely a combination of ignorance and title inflation, not dissimilar to the inflation in titling software developers as Software Engineers, but that will need to be discussed by someone else.
Solution Architects are the next level down, contributing to the vision of the solution. Solution Architects may work with Business Analysts at the start of a new initiative, but once the direction has been established, the Business Analyst should continue without the need for further input, instead partnering with a Technical Architect or Technical Analyst.
Technical Architects are a level deeper still. They are likely to be Solutions Architects in waiting, but they have a tighter focus. In an organisation with Technical Architects and Technical Analysts, the Architect would have the higher vantage point whilst the Analyst would be closer to the solution and provide more detail to it.
In the end, I can’t quite grasp why an organisation can’t get this right. Not only are there countless published pages of what these roles do, there are official organisations that define and accredit people into these roles. There’s literally no excuse I can think of. Can you?
How does your organisation handle these roles? Are they in line or somewhere off the reservation? Does your organisation use title inflation to compensate for lower compensation levels? Or is there some other reason they use non-standard titles? Let me know in the comments.