Category Archives: Architecture

What Do Architects Do? – Part 1

Having been Chief Architect for Best Buy and currently Chief Architect for Target, I get this question frequently.  The question occasionally comes at your neighborhood party but generally it’s from people in Engineering or Marketing.  At the neighborhood party you attempt to answer this question at risk of becoming known as the “boring tech guy.”

What do architects do?

People ask this question because they truly don’t understand.  They are really asking “Are architects necessary?”  They ask this question because they have rarely seen value from the architects they’ve seen in the past.  This is the sad reality of much of the architecture world, enterprise architecture in particular.  My opinion on why architecture has devolved to a place where many companies are eliminating the practice altogether is simple.  Most architects in the upper echelons of companies were never software engineers.

Why this is important and is a point I harp on continuously, is that if you haven’t spent your 10 years writing code and building and running systems with higher and higher business complexity, you cannot do the first thing architects should do.

Answer #1:  Architects create the environment for engineering culture to thrive.

To create an engineering-centric culture, you have to have been an engineer.  You have to have a few large scale Agile/DevOps systems under your belt.  You have to understand what drives and motivates engineers that want to work on six person teams tackling the toughest problems facing enterprises.  You need to feel it in your gut when one person on the team is a hack and can’t pull their weight and your management won’t address the problem.  You must have found the rock and through sheer force of will, pushed it up the hill, leading in such a way that the rest of the team helps push it along with you.   If you haven’t done these things over the course of years, you haven’t been a software engineer.

Architects that understand how engineers want to work, spend all of their time and energy creating an environment where hard problems are solved, new solutions are found, and everyone sleeps well at night.  Architects make decisions based on whether engineer’s will understand them and choose them regardless of what else is available.

Architects also create the constraints that allow engineers to solve their problems quickly.  With the near infinite array of tools, frameworks and packages available, to remain economically competitive, enterprises need to limit the scope of technology in some way.  Make no mistake, architects select and limit technologies, but only those that involve large expenditures.  If a technology selection will cost a company in excess of $1M for licenses, subscriptions or maintenance over a five year lifespan, architects should be involved.

Architects essentially act as the aggregated will of the engineers.  Architects are there to make engineer’s lives easier.  Architects in effect are servants of both engineers, and the enterprise and walk the fine line that brings the maximum value to both.

 

Peak Architecture

I believe peak architect occurred somewhere around 2013, that was the year with the most people employed with architect titles ever. Since 2013, we are now entering the post-big-architect era, where architect roles are quickly shrinking in the tech world. This is a good thing.

The number of roles with architect titles in industry was getting ridiculous. I can riff 20 titles in less than a minute if I try: Data, Technical, Web, Digital, Application, Cloud, Security, Infrastructure, Network, Business, User Experience, Information, Middleware, Enterprise, Solution, Sales, Product, Project, Principal and my personal favorite, Sharepoint. The question is, what did all those architects do?

My contention is that they completely messed up most companies by proclaiming they knew how to select and manage technology at large companies, and forced vast numbers of engineers to conform to a highly limited set of technologies in the name of fiscal conservatism. Then retreated to their own worlds to rest and consider the next great set of technologies they would enshrine five years from now.

What is the optimum number of architects for a company?

The answer to this, like all math problems, is 0, 1 or some hard to derive number. Zero and one are actually quite good answers. Zero is complete engineering anarchy, you’ve decided to let the engineers do whatever they want. If they’re good engineers, they might actually make an amazing system by developing external APIs which hide all the technology choices from the outside world.

One is also a great answer, you’re basically saying someone needs to think about the company as a whole, and one insanely smart person can get a whole company pointed in the right direction, or they can spend a lot of time thinking and watching engineers do whatever they want. One architect can spawn ideas, if they’re in touch with the engineers, that just may be enough to get people pointed in the right direction.

A better number is some ratio to the number of engineers. But what ratio to pick? Too low and you have architects running over each other to tell engineering teams what to do. Something like the commissioned sales model, “that team was mine, I talked to them first.” Too few and you’re not much better than 0 or 1. My personal favorite ratio right now is 1:100, one architect for every 100 engineers. That seems to be enough to get some rational standardization (if you don’t like standardization, deal with it, every company beyond startup mode has some set of standards), while allowing engineers to fight the power and pick new technologies when necessary. Since technology is progressing faster and faster, it’s essential to keep new technologies flowing into an organization, and old ones leaving (sometimes 6 months is old!). Relying on a few individuals to follow these trends and pick the right tools for everyone is impossible. But sourcing newness from those engineers willing to push a new idea over a few intentional roadblocks will keep your organization current enough to remain relevant.

Peak architecture has passed, time to jump on the bandwagon and become engineers again!

Tech Cities 2016 – The Agile Architecture Game

Coming up in February 2016 I’ll be facilitating the Agile Architecture game with my former colleague and game inventor Kevin Matheny.  We’ve used the Agile Architecture game within BestBuy.com to help project managers, business analysts, product managers, engineers, and others learn about the tradeoffs involved with long term software architecture choices.  It’s a fast way to learn about the hard choices that architects make every day.

One of the comments from a person at Best Buy that played the game was “It felt like work.”   This person was an architect so we felt like we got the game right.

Tech Cities 2016 is a conference sponsored by the Carlson School of Business to foster the vision of Minneapolis being the tech center of the North.

It should be a fun conference!