Analysts and Architects

Sesame Street has been broadcast in about 150 countries, so many people recognise the characters and memes, though much content was localised for regional cultural interests and nuances. Discover the history, but that's not a focus here.

One of the themes I recall—after the muppet characters—is one of these things is not like the others and the accompanying jingle. Sing it if you know it. I've had a lot of conversations about business architecture and the role of a Business Architect—additional context at the end of this piece—, and I thought I'd use this Sesame Street prop.

Architects

Regarding the top row, we should notice the common Architecture term. This is about envisioning an approach and creating a sketch of how to achieve the approach. In business, this is about surveying the entire domain. The sketch tools might be high-level roadmaps and end-to-end process diagrams that cut across functional areas and clarify operating models. Approaching the enterprise holistically, a business architect looks across business processes for opportunities to unlock and realise value. The roadmap illustrates priorities and sequencing.

In my experience, most organisations confuse strategic roadmaps with project plans and Gantt charts. It's best to think of roadmaps as sketches on the back of a napkin. You'll have time to create plans later.

As an economist, Arthur Laffer's Laffer curve is a prime example. [source] I won't dwell on the irreparable harm this facile sketch unleashed on the unsuspecting world and especially in the United States, but if you want to talk economics, fiscal policy, and charlatanism, hit me up.

My point here is not the veracity of the claim—that would undermine my point. It's about the appropriate level of detail of a strategic roadmap. Designers might consider the parallel of a lo-fi wireframe sketch—hopefully articulated on a whiteboard or scrawled on paper and written in pencil. This is the level of fidelity we are seeking. Details will follow. Trust the process.

The architects in the top right box situate like the chart below. [source] Notice that as the eye travels left to right, we zoom in, diving deeper into the weeds; as we scan from top to bottom, we shift from a strategic vantage to a technical perspective. We've switched from telescopes to microscopes.

Effectively, a Business Architect operates at the same height and orientation as the Enterprise Architect, except that none of these roles is circular. Business is anything but Platonic. They need telescopes, not microscopes. There should be a Z-axis to depict business versus technical focus and business processes versus technical system processes. Viewing from left to right, the depicted architects retreat from business to technology, but the business architect is in front of all of them.

Analysts

Regarding the left column and focusing on the lower box, we see all stripes of analysts. In all cases, these roles operate downstream of the architects. They operate in smaller domains—sometimes laser-focused.

Following the telescope-microscope metaphor, these roles more typically need binoculars and perhaps a magnifying glass—somewhere in the middle. And they may probably make use of a torch.

Flavours of analysts abound because it depends on what is being analysed. It may make sense to combine roles, especially in an immature organisation that can't justify specialising. Just keep in mind that this will almost invariably lead to conflict and efficiency losses.

As the intent of this article is to differentiate the larger quadrants, I won't dwell on the differences within the boxes, save to say that the relationship between a business and analyst and a technical analyst is similar to that of a Business Architect and an Enterprise or Solution Architect but on a different scale. In my experience, a Business Analyst has been a person performing a mix of functional and process analysis, perhaps dabbling in systems analysis. And whilst a Business Analyst might have a broader purview, a functional analyst might be more narrowly focused on a particular function. A System Analyst is likewise focused on a particular system. As with a Technical Architect, the Technical Analyst is deeply entrenched in the weeds.

Project Manager

The Project Manager is the odd one out. This role neither analyses nor architects. The goal is to keep the trains running and on time—and on budget and in good repair. Whilst it is too common that Business Analysts get tasked with Project Manager roles, it is decidedly an anti-pattern, it creates a conflict of interests and doesn't even involve the same skillsets or competencies.

Pulling It Together

It is somewhat common for some of the roles within a box to bleed over. Perhaps a Technical Architect is maturing into a Solution Architect role, or perhaps a Solution Architect is growing into an Enterprise Architect role. Or perhaps they need to support downward because of staffing or capability holes. This bleed should only extend to an adjacent role—Enterprise Architect to Solution Architect, but never to Technical Architect.

And there should only rarely be bleed from one box to another except in the least mature of companies. The exception might be upward as perhaps a Technical Analyst is growing into that of a Technical Architect. Ditto for a Business Analysis to Architect.

Whose Line Is It Anyway?

Why am I writing this, and why does it matter?

I have interviewed many companies and spoken with recruiters, human resource talent personnel, hiring managers, and more. It's come to my attention that there is a great need for role clarity in these areas. As I am a Business Architect, my conversations obviously revolve more around this topic, so allow me to centre my rationale around this role. Also allow me the liberty to start with DataRobot, where I left off.

At DataRobot, I was a Business Architect in-title but zero per cent of my time was allocated to this. The focus was perhaps a 50-50 (give or take, perhaps 40-60 or 60-40) split between some flavour of business analysis and project management.

I spoke with a newly-hired manager about this fact and told her straight away that I was a Business Architect but was tasked with Project Management and Business Analyst roles. I told her that the Business Analysis roles were OK in a pinch, so long as we didn't lose track of the fact that we had no strategy or architecture in place against which to operate, so that should be a higher priority. Her response, "Our Business Architects did project management at my last company" was all I needed to know about the maturity of her last company and by extension her immaturity in these matters. It was also a strong signal that she not only had no idea what a Business Architect does, but she had no interest in learning.

But why is this a problem? you might be asking yourself. Besides the obvious employee engagement and skillset mismatch, the company was seriously overpaying. Moreover, they were having difficulty filling positions. Why? Because they were shopping for bicycles at a florist shop. Might they find a bicycle? Perhaps, but the odds would have been greatly in their favour to have been looking in a bicycle shop.

And I am not comparing myself to a CEO, but imagine placing ads with descriptions matching that of a janitor. Would you be surprised not to be able to find candidates? In some ways, it's easy to blame the hiring manager who misuses common terms, but it is also incumbent on talent and organisation staff and recruiters to educate themselves and to educate their hiring managers.

When a hiring manager asks to fill a req for some title X, ask what roles they need to fulfil. If they tell you they need an astronaut—or a Business Architect. Let's stay on point—and they convey that this person needs to know how to walk in oversized shoes, apply make-up, and juggle, they need to be corrected and told that they are probably looking for a clown rather than the given title. "This is what we called them at my last company", is no excuse. From the perspective of budget, clowns are probably cheaper than astronauts or Business Architects.

Oh, and if a company insists on having resources take on the added role of Project Manager, it's still a bad idea, but at least keep it below the fold and involve analysts, not architects. Did I mention that this is highly not recommended? You've been warned.

In interviews, I am very clear on the role specifics. When—and almost invariably—the interviewer says we need this person to do X, Y, and Z, I'll clarify whether that's an adjacent activity or a far stretch. If it's adjacent, we might discuss why it might make sense contextually. If it's a stretch, then I'll inform than that it might have been nice that the last person could juggle, but that is not conventionally part of the role, and they may experience difficulty if they try to artificially expand the role.

In the end, if you need a project manager, hire a Project Manager. If you need a Process Analyst, by all means, hire one. But if you need one of these roles, please don't advertise that you are looking for a Business Architect. This Business Architect wants to solve you the time, effort, and budget.

Consider this to be a public service announcement. This segment was brought to you by the letter A and the number 42.