Tag: Architect

As a seasoned veteran of software design and implementation, every architect is armed with an array of weapons they‘ve used with repeated success. For one reason or another, these technologies have found favor and bubbled to the top of our list of preferred solutions. Most likely they‘ve earned their rightful place in your arsenal by defeating fierce competition. Despite this, a barrage of new technologies constantly threatens their position. We are often compelled to lay down our weapons of choice for these new alternatives but don‘t be too quick to dismiss your trusty armaments. To cast them aside for alternatives that haven‘t been proven through similar trials is a risky proposition.

This doesn‘t mean that once established on our list of favorites a technology is granted infinite tenure and it certainly doesn‘t mean that you can bury your head in the sand and ignore advancements in software development. For each technology the time will come when it needs to be replaced. Technology moves quickly and superior solutions are on the way. As architects we need to stay abreast of industry trends, we just don‘t need to be the first to embrace fledgling technology. There‘s usually no huge advantage to being the first to adopt new technology but there can be several drawbacks.

To justify the risk involved with selecting new technology its benefits should be a quantum leap forward. Many new technologies claim such advancement but few deliver it. It‘s easy to look at new technology and see technical advantages but those benefits are often difficult to sell to stakeholders. Before you decide to blaze a trail with new technology, ask yourself how the business will benefit from this decision. If the best outcome from a business perspective is that no one will notice, rethink your decision.

Another important thing to acknowledge is cost associated to the shortcomings of new technology. These costs can be high and are difficult to calculate. When you‘re working with familiar technology you‘re aware of its idiosyncrasies. It‘s naïve to think that a new technology won‘t come with its own collection of pitfalls. Adding problems that you haven‘t solved before will destroy your estimates. You‘re far more aware of the costs involved when implementing solutions using familiar technology.

One last thing to consider is future relevance. It would be nice if we could simply identify and select superior technologies but things aren‘t quite that simple. Great technologies don‘t always win. Trying to predict the winners early is a gamble that doesn‘t yield a large payoff. Wait for the hype to die down and see if the technology settles into a space of usefulness. You‘ll find many just go away. Don‘t jeopardize your project for a technology that doesn‘t have a future.

Selecting the technologies we use to attack problems with is a large part of the software architect‘s job. Choose your weapons carefully and relinquish them reluctantly. Let your past success help to ensure future success and evolve your technology stack cautiously.

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.