3 Reasons why business people make lousy solution architects and software designers

The daily life of a project manager, it seems, is to broker discussions about what features we can or can’t add to the system before launch. In part, this is an aspect of having a single large deployment. But let’s not get sidetracked on that debate.

The Endless Debate

The zone of the debate is almost entirely on system capabilities. We hear statements like: “we need this new field”, or “this report,” or “this screen should read from the vendor master table”, and so on.

We try hard to get the business representatives to describe the required behaviour or process change. But, we always end up in a feature discussion. We start discussing business enablement. The debate trips over into the solution space in any case and never gets out.

It’s like there’s an event horizon that defines the boundary between business outcomes and technology attributes. Once we get too close, we get sucked into that black hole, never to emerge without some radical change.

Now I’m not saying that there never can be any discussion of the technical aspects of a solution. I’m not saying that we have to sit inside some artificial bubble of specialisation.

In any dynamic debate, the focus will evolve and change direction.

What’s Your Role?

Interaction-based evolution of solution concepts is one of the foundations of any successful project. Each project team member has two critical components of their participation in the project:

  • a primary specialisation — our “domains of competence” based on personal experience, training and capabilities.
  • a primary job role within the team

This second point is critical. Do you notice how often coaches talk about this in team sports? They stress the importance of every player “knowing what job they have to do”. At the same time, there is infinite flexibility to adapt to each game situation if needed. Attackers can kick a ball off the line to save a goal or make a try-saving tackle. Defenders can score if that’s the way the game turns out.

Three Reasons to Play your Position

But there are at least three strong reasons we should consider our job role as the default position in any interaction:

  1. Divide and conquer: projects are messy environments conceptually. We need all the available cognitive resources to work on all aspects of the problem and solution space. A business representative’s job role is to understand and articulate the problem space. If the business uses its brainpower on technical issues, who is working on the problem space?
  2. Capability: solution architecture and software design are deep technical specialties. They take most people a long time to get right. The agile mantra of “the best designs emerge from interaction” may be true in theory. But it homogenises all technical decisions into an endless series of iterations with equal impact. Not all technical choices are similar. Making the wrong one can significantly impact system performance.
  3. Expose the thinking around problem/solution mapping: the core job of a project is to map the problem space into the solution space. Thus, we emerge with a system optimally tuned to solve specific project constraints, e.g. time, money, or people. If business people over-invest their time in technical design/feature description, it’s a problem. Perhaps, they are not explicitly considering the problem space in those technical inputs. Or they are hiding that mapping in their heads. It’s probably a combination of both.

For me, #3 is the most significant detrimental impact in software development or IT solution integration. There are many reasons why this is bad. But let’s look at one in more detail: Peter Naur’s Theory Building model.

A Theory of Software Development

In Naur’s Theory Building View of Programming (1985), he proposed that software development was primarily the process of building “theories” (aka “mental models”) of the problem space and how those are resolved by software code.

“… the proper, primary aim of programming is, not to produce programs, but to have the programmers build theories of the manner in which the problems at hand are solved by program execution.”

So the actual deliverable of a software dev is the models, not the code.

Whether expressed in Naur’s formulation or not, this development concept is the primary driver for the Agile principle of interaction between business people and developers.

“Business people and developers must work together daily throughout the project.” https://agilemanifesto.org/principles.html

So, if business people don’t bring that mapping process into the dialogue with the developers, they don’t have access to all the information they need to build their “theories”.

Naur went much further with his analysis and the implications of not having the models available. One issue is the drop in quality if the devs couldn’t develop rich enough models. Another issue is when the models walk out the door inside the dev’s heads.

The Bottom Line

Business people, as a default, should be focused on identifying the problem space. Their job is to inject this information into the dialogue between devs and business people. In this way, good architectures emerge.

The dialogue can go where it may, as all good discussions do.

But every player needs to start with a strong concept of their job: and do their f#$king jobs!

— —

If you like what you’ve read, be sure to clap or ♥ it below — as a writer, it means the world.

Stay in touch by subscribing to my weekly newsletter here.

I want to change the way you think about and do project management. http://www.adamonprojects.com