How to be a Good Software Architect

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

Self-Contained Systems – Microservices for Dummies

Harran beehive houses, Wikimedia Commons
Harran beehive houses, Wikimedia Commons

I love the smell of the new year in the morning. As in the tweet above, there is something hopeful in starting a new blog by first updating the copyright notice at the bottom.

Nevertheless, what is currently occupying my mind is not as much how 2016 started, but how 2015 ended. As luck would have it, within weeks I had a chance to present about our production experience with micro services to two enterprises –  a mutual fund and a bank. Both were curious about them and simultanously unsure as to how they would apply in their unique situation.

In such discussions, the topic of Netflix inevitably comes up, and I am not sure this is a good thing. Sure, I enjoyed watching The Social Network like the most of us, but I am not sure it taught me much about how to become Mark Zuckerberg. Certain experiences, approaches and stories are so intensely singular that their utility as a ‘how to’ manual is quite poor.

In the case of Netflix, I have noticed two characteristics that are not very useful in most scenarios where micro services are considered:

  1. Very few outfits need to scale up to a third of all Internet traffic
  2. Being the micro service pioneers, Netflix engineers wrote a lot of custom code that is impractical in most situations

Maybe we don’t need 1000 microservices?

The consequence of the fact that you don’t need to prepare to handle a third of all Internet is that the overhead equation skews towards having fewer large micro services, rather than many small ones. In fact, it is surprising what transpires when discussions go a bit deeper into the ‘why’ direction.

As you probably know, I am on the record claiming that micro services are more about future-proofing, solving organizational problems of large teams and DevOps than any particular technology. It has become apparent to us as we talk to companies that the problem of two speed IT is more acute and pressing than replicating Netflix’s improbable feat. In the two-speed systems, companies can preserve investment and control through exposing the current system of record through APIs, while building up a cloud-based micro service system that consumes those APIs and serves Web and mobile experiences at the required speed and agility. You don’t need thousands of micro services for this.

In fact, more proof that the pragmatic pendulum has swung towards more reasonable architectures  can be found in the coining of a new phrase – Self Contained Systems (SCS). It is a neat workaround for the cognitive issues that may come from the term ‘micro service’. The term ‘system’ implies something larger, so even the illustrations of SCSs imply no more than a dozen or so. All the good properties of micro services are preserved (polyglot persistence, ability of teams to develop and deploy them independently, stack independence), but there is no expectation to deploy them in the hundreds and thousands. Sure, a self-contained system can in turn consist of several micro services, but at that point it becomes implementation detail.

It is probably best for companies dipping their toes into the micro service world to think about self-contained systems instead, lest they are taken down the Netflix path which will most likely be wrong for them.

I make my own underwear

The point of custom code from above reminded me of a story from the days when I was still climbing the audiophile ladder and cared about hi fi companies and stories about them. In this particular story from 2011, a parent company IAG that owns illustrious British names such as Quad, Mission and Wharfedale, describes its process like so:

One of the immediately notable things about IAG’s operation is the extent of what they make themselves: from new parts, to the tools to make those parts, through to all their own speaker drivers: the vast bulk of what goes into IAG products is made right there in the Shenzhen factory. They even manufacture their own wire.

What Hi Fi: Behind the scenes at IAG

The advice ‘start by making your own wire’ would make sense for very few companies, and the same applies to most enterprises trying to replicate Netflix’s approach. This comes into sharp focus when you start discussing concepts such as service discovery. Consider the following diagram:

service-discovery

The URL of the micro service system is composed based on spaces (dev, QA, prod) and regions. It can be easily constructed or scripted. The routing proxy partitions the path namespace, and each path acts as API and is driving a load balancer which in turn handles any number of micro service instances.

I am showing you this because we are running this successfully in production right now. If you want to, say, hit the development version of the micro service system running in US1 data centre, you would have something like https://foo-dev.us1.acme.com. A script with a couple of substituted variables is all you need to hit the system you want. As for the load balancer, it comes for free in the IBM’s Cloud Foundry-based PaaS (Bluemix).

If you have a Netflix-type system, you need service discovery just so that you can connect all your micro services, all flailing around at the unguessable IPs and port numbers. And since you need to build everything yourself, a simple thing such as load balancing that comes out of the box in all PaaSes and a number of IaaSes is something you need to provide.

Netflix story is unique for many reasons, and having to build everything yourself is one of those characteristics not necessary in 2016. Cloud today is all about what you can outsource to a PaaS or IaaS vs what is uniquely your value add. Building load balancers is doable but a rarely justified practice today.

For Dummies?

Yes, I know, forgive me for the click bait – SEO and all that. But by now you are well versed with the tongue-in-cheekness of the ‘For Dummies’ franchise. As people finding value in them are hardly dummies, so are people wisely choosing Self-Contained Systems instead of going down the path of the thousand micro services. Running a half a dozen to a dozen independently deployed, agile self-contained systems hooked up to your legacy systems may be the best choice for you right now. You can always add more, but don’t feel pressured to do so.

© Dejan Glozic, 2016