In my function as a software architect and through my activities on SCN, I meet many different people, and sometimes they ask for advice on how they could become software architects themselves.
I could write or talk for hours about many different aspects of the question, but I’ll try to be brief. I did it again – so here are the four crucial ingredients to being a good software architect.
1. Experience
Software design is not a science, and despite many claims to the contrary, it isn’t even much of an engineering discipline yet. There are no deterministic rules or procedures for making good software, or making software well. It is still very much a craft, and some exceptional craftsmen might even reach a level of mastery that deserves the label “art”.
There are books and classes on software architecture, but those don’t teach anybody how to be good software architects. More precisely, they go only so far in making students produce software architectures that work, and they will make only few students better judges of good or bad software architectures. However, they do have great merits in that they can help establish a shared vocabulary and make it easier to discuss software architectures with others.
Good software architects usually distill their architecture skills out of their experience as developers. As a developer gains experience, they become better and better at making higher-level design decisions, and expand the scope of their work accordingly. With each new level, the granularity of their scope changes and they govern collections of software artifacts at a higher order of magnitude:
- The first level (Developer) might be the ability to make good decisions about the design of a small functional unit, such as a single class, report, or function group.
- Second level (Senior Developer): designing larger functional units, such as an entire package consisting of several (independently reusable) classes, structures, reports, tables, and so on.
- Third level (Application Architect): designing an entire application, making decisions on which frameworks to use, how to implement persistence, extensibility, configurability, and so on.
- Fourth level (Enterprise Architect): designing and governing multiple applications, making decisions on application landscape design, and governing the interplay of forces between several applications and larger software components.
- Fifth level (Application and/or Technology Strategist): Laying out the strategies and rules for the evolution of entire application landscapes and technology platforms.
It usually takes a few years to go through this growth process. That being said, age or years of experience aren’t necessarily reliable predictors of how far someone can have progressed.
People start at different ages: I started developing software for money at age 12 and built my first libraries of reuse components at age 11. Others start when they finish university – in Germany, this could be around the age of 25, 26.
People learn at different paces: The most gifted developer I have worked with needed about two years to learn what I had learned in six years. Similarly, after one year I felt more advanced than my senior colleagues who had ten years of SAP experience.
So there’s no point in saying that someone has to be at least 16, or 26, or 30, or 40 to reach maturity as a software architect. Each of these ages is the right age for someone. On the other hand, even though some start early and some are very fast, there are no shortcuts: It does take a significant amount of hands-on development experience to become very good at making high-level design decisions. The higher the level, the more experience is required.
2. Creativity
Making software is about making things up. We produce inventions. Good problem solving in software development combines a highly analytical (the Ancient Greek root of the word means “to break something down into its constituents”, “to decompose”) approach with a synthetic (from Ancient Greek “to put together”, “to compose”) approach.
Being creative, imaginative, inventive is something that cannot be taught to an unimaginative person. Software architects who don’t have at least a bit of an imaginative streak are rarely able to develop good judgment even in simple matters. If I were to hire a software architect today, I would probe for signs of imagination and vision in the candidate’s background:
- fantasy role-playing games (RPG), writing fiction, engaging in story-telling
- engineering, building, making technical inventions, developing their own computer programs
- developing social, philosophical, or political visions, engaging in community-building
3. The Architecture Instinct
I came across the notion of “architecture instinct” in this article about architectural anti-patterns, which I highly recommend: http://sourcemaking.com/antipatterns/the-grand-old-duke-of-york
To quote from the article:
“Programming skill does not equate to skill in defining abstractions. There appear to be two distinct groups involved in software development: abstractionists and their counterparts (whom we call implementationists) Abstractionists are comfortable discussing software design concepts without delving into implementation details.
As stated, they possess the architecture instinct, the ability to define and explain good software abstractions. Implementationists, on the other hand, often require source code examples before they can grasp abstract concepts; they are not particularly adept at defining new abstractions that can be readily understood by other developers.”
4. Street Credibility
This is the reason I’m writing this blog post. This aspect is easily overlooked, or at least underestimated. If you take the first three ingredients – experience, creativity, architecture instinct – and put them together, what you have is basically the recipe for unpopular opinions. An architect equipped with these three things will
- take the long-term perspective among people who only look until the next deadline,
- anticipate changing or additional requirements nobody else sees,
- warn from designs that look like the quick and easy solution to everybody else,
- ask developers to jump through a number of hoops that may seem counter-intuitive and unnecessary to them,
- tell experienced developers that what they’re doing works right now but it’s still wrong,
- try to convince senior managers to spend more time and money than seems necessary and sufficient at the moment.
In other words, they will appear like a complete and utter fool right out of the loony bin, or perhaps coming straight from the ivory tower where the kind of software architects nobody listens to are educated.
What makes the situation even harder for the architect is that their role doesn’t usually give them any formal authority that would allow them to push their opinion through and force the other people on the project to follow their judgment. Neither do they own the budget, nor are they in charge of the execution – so all a software architect can really demand is to be heard, and that their recommendations are given due consideration.
That being said, how can software architects escape their likely fate as a whining annoyance, and become highly effective, respected advisors whose recommendations the projects actually follow – even when it hurts? The answer is simple: They have to be very convincing. Being very convincing, in turn, requires a number of components.
Communicate well
Of course it’s helpful if you’re a Jedi in command of the famous Jedi mind tricks (“These are not the tables you are looking for.”), skilled in covert and conversational hypnosis, and generally a rhetorically skilled speaker. Being empathetic, understanding where person you are talking to is coming from, and being able to speak their language is part of this component which I would sum up under “communication skills”.
Fig. 1: "These aren't the tables you are looking for."
Be right
It may sound silly, but you’ll only be respected by smart people if you turn out to be right at least reasonably frequently. This involves making claims and predictions that are concrete enough to be tested. You have to know what you’re talking about, and talk about what you know. (It’s also okay to go out on a limb and present opinions in an area where you don’t have solid knowledge – but then you should be honest and make the appropriate disclaimers.)
Earn your credibility
Yes, you can make an excellent impression in one meeting, but: To gain the standing and credibility that makes others rely comfortably on you in important matters takes many years. A senior enterprise architect is in a position where C-level executives and board members must sometimes bet their careers on the correctness of their judgment, and where errors can cause millions of dollars or Euros to be misspent. Getting there takes an excellent track record that is best earned over a few years, in several different positions, with extensive experience in a wide-ranging array of topics and technologies.
Part of your credibility is the respect you enjoy in various communities. If you’re a respected member of the SCN community with a track record of great contributions, perhaps even a top contributor in one or two fields, this might be beneficial to your credibility. Similarly, if you’re a respected member of the developers community at your employer and colleagues tend to seek your advice, this might persuade others to listen to you more carefully.
In summary, to build the standing you need in order to push through unpopular positions, or to bet their careers on you, you need to convince a wide base of people in your field that your word now is of actual value to them, because it was in the past.
It all boils down to: You need to provide good value to many people over years.
Summary
In order to be a good software architect, you need to provide good value to many people over years. Then they will follow your advice even if it hurts, or bet their careers on the correctness of your advice.
26 Comments
