Categories
Software Architect

Don’t Be a Problem Solver

With some exceptions, architects used to be developers. Developers get rewarded for solving programming problems, which are more local in scope than architectural problems. Many programming problems are small, tricky, algorithmic problems. Such problems are frequently presented in programming interviews, books, and university courses as if the problems exist in a vacuum. The trickiness is alluring and seductive. Over time, we begin to accept such problems out of hand. We do not ask if this problem is meaningful, or interesting, or useful, or ethical. We are not rewarded for considering the relation of this problem to a larger landscape. We are trained to focus only on our solution, which is aggravated by the fact that solving hard problems is hard. We leap into action in programming interviews, which often begin by presenting us with some number of jelly beans we are meant to sort according to an arbitrary set of constraints. We learn not to question the constraints; they are a pedagogical tool, intended to lead us to discover what the teacher or interviewer or mentor already knows.

Architects and developers learn to enter problem-solving mode immediately. But sometimes the best solution is no solution. Many software problems need not be solved at all. They only appear as problems because we look only at the symptoms.

Consider managed memory. Developers on managed platforms have not solved memory problems, nor could many of them do so if required; part of their solution means that they mostly just don‘t have that problem.

Consider complex builds that require lots of interconnected scripts requiring the enforcement of many standards and conventions. You could solve that problem, and it would feel great to get it all to work, putting your best scripting skills and best practices to work. Our colleagues will be impressed. No one is impressed by us not solving a problem. But if we can step back, and figure out that we aren‘t solving a build problem but rather an automation and portability problem, this might lead you to a tool that abstracts it away.

Because architects tend to immediately enter problem-solving mode, we forget, or rather have never learned how, to interrogate the problem itself. We must learn, like a telephoto lens, to zoom in and zoom out, in order to ensure the question is really framed properly, and that we‘re not merely accepting what we‘re given. We must not be passive receptacles for requirements, cheerfully ready at our post, handing out our smartest solutions in the manner of a Pez dispenser.

Instead of immediately working to solve the problem as presented, see if you can change the problem. Ask yourself, what would the architecture look like if I just didn’t have this problem? This can lead ultimately to more elegant and sustainable solutions. The business problem still does need to be solved, but not, perhaps, as immediately suggested.

We have to break our addiction to “problems”. We love to get them, seeing ourselves on a European bridge, as if we are secret agents who‘ve just been handed a self-destructing brown envelope containing our mission. Before considering your answer to a problem, think what the world would look like if you just didn‘t have this problem.

'Coz sharing is caring
Categories
Software Architect

Take responsibility for your decisions

Software architects have to take responsibility for their decisions as they have much more influential power in software projects than most people in organizations. Studies of software projects show over two-thirds of them either are outright failures or deliver unsuccessfully (deadline slip, budget overruns, or low customer satisfaction). Many of the root causes point to improper decisions software architects made, or failures of follow-through on the right architectural decisions.

How can you become a responsible software architect who makes effective architectural decisions?

First, you have to be fully cognizant of your decision process, whether it is agile or ceremonial. You should NOT claim that an architectural decision has been made until the following two conditions are met:

  • A decision has been put in writing because architectural decisions are rarely trivial. They must be substantiated and traceable.
  • A decision has been communicated to the people who execute it, and the people who will be affected directly or indirectly. Communication is all about creating shared understanding.

Second, review your architectural decisions periodically. Examining the results of your decisions against expectations. Identify architectural decisions that remain valid and those that do not.

Third, enforce your architectural decisions. Many software projects get software architects involved only in the design phase, then they move to other projects or the consultation contract ends. How can they ensure that their deliberate architectural decisions have been implemented correctly? Their decisions will be at best good intentions unless they follow-through with them.

Finally, delegate some decision making to others who are experts in a problem domain. Many architects wrongly assume they have to make every architectural decision. Therefore, they position themselves as a know-it-all expert. In reality, there‘s no such thing as a universal technical genius. Architects have areas in which they are quite proficient, areas in which they are knowledgeable, and areas in which they are simply incompetent. Adept architects delegate decisions about domain problems in which they are not proficient.

'Coz sharing is caring