Software Architecture for Product Managers

One area I have seen many Product Managers struggle in is understanding modern software architecture decisions. While most PM’s quickly learn the patterns that emerge from user needs, mapping those patterns to engineering best practices is a discussion Product Managers should learn to contribute to.

As always, start with why

You could potentially skip the rest of this post if you can ask the right questions of engineers when it comes to architecture decisions. Having a frank discussion about why your are making the decisions you are making is the key contribution a Product Manager should make to architecture decisions. Here’s the thing. It also turns out many engineers won’t be able to answer this question, and identifying what questions to ask when, requires years of experience. Often times seemingly small decisions have surprisingly long life cycles and learning to sense these tipping points is tricky.

In truth you will need to learn to live with some uncertainty as to why key decision are made, or have been made. The truth is languages, frameworks, and tooling are still rapidly changing — it’s common to use a new technology because of industry momentum and not have a firm foundation as to why it is a good fit, even if it is. As such it can be very hard to identify the origin of the “why” for most architecture decisions on software projects. Facebook created a virtual machine for interpreting PHP for example. There is certainly no good user driven reason this should have ever happened.

Research the why

Facebook’s extreme example of investing engineering resources to optimize a known weak architecture choice is both a testament to the impact of seemingly small decisions and also the intense pressure that market forces can create. Researching why a decision is made is also a valuable form of Product research that you need to perform as a PM because it surfaces the design constraints of your organization.

Like any form of research, inquiring about architecture decisions requires considering thoughtfully the view point of those that made the decisions, i.e. empathy. This is especially important because those that made these decisions are likely critical team members often in leadership roles. Depending on the structure of your organization you may need to track down lots of engineers working on your product, or you may need to deal with extracting a large amount of knowledge from a single individual. Both can be challenging.

You know that saying, the captain goes down with thier ship — it also applies to engineers and architecture decisions.

Either way, you’ll be encountering defensive posturing and skepticism about your inquiries. You know that saying, the captain goes down with his ship — it also applies to engineers and architecture decisions. Remember, engineers are people who have committed huge amounts of time and energy to the product and they suffer from tremendous attachment bias. They forget that most architecture decisions are undone in less than 24 months. Also, you want them to strive to build something timeless, that’s part of what makes your contributors missionaries not mercenaries.

Naming things is hard

There is a long standing joke in Computer Science that there are two hard problems in Computer Science — cache invalidation, naming things, and off by 1 errors. The point is salient. Naming things is hard, and important. A few things that I have learned about naming things.

1. Call it what it is. Pick a name that describes the function the component or tool performs.
2. Make it distinct. Names like “the api” are too generic even if they describe their function.
3. Make it easy to say, and type.
4. Changing names is expensive (but sometimes neccessary).

Naming should be collaborative. When faced with a naming decision I like to create slack polls with naming ideas that fit these criteria.

Learning buzzwords and spotting patterns

Since software architecture involves assigning names to abstract concepts, there is an enormous amount of jargon in the field. Additionally many approaches to problems are recycled as software and hardware performance trends change. This means most of the terminology you know currently will be dead language in just a few years.

To counteract this it is better to focus on patterns, rather than the specific words behind them. For example, a few years ago there emerged a common technique of website smartly considering the screen size they are displaying on and adopting certain design patterns and breakpoints to accommodate them. This eventually became known as “responsive” design but it had many name iterations along the way. Even if you didn’t know what this technique was called you could identify this trend simply by being a user that has more than one screen size and from there it is easy to breakdown the core elements of the approach.

Monolith vs Microservices

One current debate you are almost certain to encounter in tech circles these days is that of Monoliths vs Microservices. Even the framing of the discussion misses the point a bit. Most teams should evolve their software in a way that breaks off services as it makes sense to do so. This just in time approach is another core tenant of empowered teams and is typically what I have seen work best. That said it’s helpful to compare and contrast the advantages and disadvantages of each.

Also, a quick disclaimer I work for Pivotal, on Cloud Foundry which is an open source Platform as a Service (PAAS) which undoubtedly adds bias to this assessment.

Monolithic architectures are great for small products because they minimize the operational footprint of your software when your getting started. Small teams can generally manage responsibilities using version control, and keep operational needs to a minimum by only running a few instantiations of the software (one for production, one for testing typically — most teams call these environments). Additionally monolithic architectures tend to force teams to adopt language and style standards more rapidly because every one is contributing to the same repo.

That said as your Product grows so does your team and often you start to see the downsides of monolithic architecture surface. The operational burden increases as your organization wants to run more instantiations of the software simultaneously. Additionally teams start to feel burdened by the limits of version control software without clear separations of concern within the code. The results of all this operational overhead is that software ships to users considerably less frequently than it did when there was a smaller team and code base. As such growing teams often choose a microservice architecture to achieve rapid iterations at scale.

Done appropriately a microservice architectures creates clear separations of concern and allows teams to function more autonomously interacting only through defined contracts, known as API’s. Ideally these contracts are enforced by a set of automated test and teams are given more control to run their own test environments and deploy to production regaining operational efficiencies for the organization.

That said there is a gap that exists to achieve all the benefits of microservices. As mentioned you’ll need to invest in test automation to take full advantage of the benefits of microservices. Additionally to avoid high infrastructure costs and operational toil you’ll want to take advantage of some kind of platform to run your applications on. The reality is that it is still somewhat early days for tooling for both of these which means there are lots of choices and marketing happening in both these product spaces.

As mentioned, I am biased here, and I recommend using Cloud Foundry and Concourse. Both are available as Free Open Source Software, or licensed distributions and support are available through Pivotal. Of course there are many other choices and some Organizations opt to build parts of their platform in-house. My advice; do look at other platform as a service options but don’t role your own. This is never a good idea when there are mature and free options available.

Organizational bias

One of the most important contributions you can make as a Product Manager is to be aware of and assess organizational bias in technical decisions. The reason this is so crucial is that organizational decisions directly impact your software architecture and vice versa. This is known as Conway’s Law. Simply put you ship your org chart, so one way to get a sense of your company’s approach to software architecture is to look at how teams are organized and defined.

It’s also helpful to look at how other teams and architectures have evolved outside of your company. Unlike a single feature experiment, most architecture decisions take many months or even years to full play out. This is part of the reason experience is so valued for Product Managers.

PM’s role in architecture decisions

Ultimately architecture decisions should be made by the engineers building the product. Generally speaking when others make these decisions and force them onto teams it rarely goes well. That said PM’s should be helping engineers to weigh and make decisions by providing them objectivity and clear milestones. Often there is no right choice in an architecture but making no selection can have cascading affects on a teams ability to deliver. Hopefully by learning to ask why, spot patterns, and understand the bias of your organization you can help your team make the right decision for your users.