Tag: software architecture

How to be a Good Software Architect

~ Dejan Glozic ~ Leave a comment
Wikimedia Commons
Wikimedia Commons

Ah, architecture – the broccoli of software industry. You know it is good for you, but you would much rather feed it to the dog under the table and move on to the ice cream. Ever since Joel Spolsky coined the phrase architecture astronauts, the role of architect has simultaneously been questioned by developers and line of business.

Developers suspect and occasionally despise software architects because they don’t like to be told what to do (they are wrong) and because architecture bestowed on them from the Ivory Tower is often confusing and verges on unimplementable (they are right).

Meanwhile, business suspects architecture because they don’t see how it solves its problems. Until you can ship iArchitecture 6s to the customers, business owners lack the direct link between architecture and bottom line. “I see what you are saying, Dejan, but in the last project a team of enthusiastic developers built a product on time without any architecture and it was just fine”. The fact that this product was an unmanageable steaming pile that nobody wants to maintain now didn’t help them draw the connection.

So what are we to do? Clearly, architecture is good for software the way vegetables are good for us. On the other hand, architecture created without any connection to the imperfect reality is useless. Selling architecture to executives is a fool’s errand. Is there a way out of this conundrum?

Of course there is, and is practiced as we speak in hundreds of companies. You just need to sneak the architecture in. Moms around the world know they cannot sell the broccoli to children by winning a rational argument involving the importance of nutrition. Instead, they either negotiate (first broccoli, then ice cream) or just sneak the veggies in. I don’t recommend you negotiate with business – like car salesmen, they are much more skilled in it than you are. Instead, just sneak the architecture in as part of normal development.

In order to be successful, you need to win over the two groups looking at you as if you are about to steal their lunch money.

The pragmatic architect

In order to win the developers over, you need to earn their trust. The easiest way to earn their trust is to become one of them. Architect of some kind is typically a role on the technical career path, on the way to Principal Engineer or Distinguished Engineer or Fellow. Notice the word “engineer” in the title. You have selected this path because you want to lead by example, to inspire, to make people follow you because they want to, not because of the org chart.

In order for developers to follow you enthusiastically, you need to get your hands dirty. Never stop coding! Coding is your anchor, your stabilizing force that prevents your architecture from morphing into unimplementable gibberish. The role of architecture is to give the code structure, a skeleton that prevents it from turning into an unmanageable goo. The role of practical architecture is to prevent the overgrowth of the said skeleton, before it turns a juggernaut into a WW I tank, with all of its speed and maneuverability.

It you are senior enough, it will be hard to code day in and day out. If you have the time for that, why are they paying you architect salary anyway? Spending too much time in the trenches may indicate that you are under pressure because people under pressure tend to slide back into a role they know best, and for you that is likely one of the coder. No, your role is more complex – you need to travel up and down the layers of abstraction constantly. You need to ascend to see the big picture that can be lost in the details, then descend to the details where the devil is, to make sure you kept all your pragmatic marbles.

What I like to do is go about two months ahead of the team. I anticipate the technical problems we are going to face, look for the possible solutions, write a prototype and blog about it (on this blog, in fact). By the time the team hits the problem in development, I have enough hands-on experience with it to speak about the problem without the imposter syndrome, a prototype, and a blog with code snippets (Blog as a Service). Works great, pays back tenfold.

Architecture in motion

On to the business. I already explained that architecture is not something you can directly sell to the business owners. People who love technology often derive pleasure just working with it. You learn a new language or a new framework and you are ecstatic. Executives look at you as you explain it and their eyes glaze over. But explain that the framework will cut operating costs in half due to the lower resource demands, or that it will cut time to market, and the room is yours.

Things are not very different in other walks of life. Actual architects may have a problem explaining the fact that load-bearing walls ensure building’s structural integrity. I bet they will have no problem explaining a pile of concrete, loss of revenue and a torrent of criminal negligence lawsuits. Architecture has to drive business impact, otherwise it is an intellectual exercise you should do on your own time (another Flux library, anyone?).

The problem with software is that it is hard to paint such a clear picture while it is being built. So don’t. Practice architecture in motion – infuse it into code while it is being built, don’t make it a separate phase. Blog about it, make diagrams for the teams so that everybody has a clear idea what you are building, write docs, define solid APIs, explain how everything fits together. Just don’t call it out as its own thing, because line of business does not care and cannot separate it from overall development cost.

Just say “we build good software”, and when the solidly architected product or service hums in production and does not implode from its own weight, say “because we are a great team”. Architecture is implied.

Lead it, own it

In order for all this to work, you cannot sit on the side occasionally bestowing architectural nuggets on the teams working on the project. Developers will politely listen to you but most of the leadership will come from the actual tech leads in the mud with the solders. Meanwhile, business will occasionally ask for your opinion but they will go to the tech leads for status. Don’t be the architect on the sidelines, be the technical leader using architecture as your secret weapon.

Then when you are in charge of the delivery, you can sneak the architecture in small doses into every feature, like parts of the wall Andy Dufresne sneaked into the yard in The Shawshank Redemption. The warden will never know.

© Dejan Glozic, 2016