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!

Open Source North Rides Again

We had another fun and exciting rendition of Open Source North in June earlier this year (2016). It’s a conference that eventually will be recognized as the premier technology event of the year in the Twin Cities. Well, that’s my prediction at least.

I had a great time and got to give my presentation/group discussion on the state of Architecture in the Midwest and how the practice needs to be redefined. Architecture means nothing these days, Enterprise Architect in it’s traditional form is dying, and Engineers are taking over the space once occupied by Architects. Why have an architect if you can have an engineer do the same job and deliver the working software as well?

Hope to see you again next year!

Tech Cities 2016 – Quick Fun at the Carlson School

Tech Cities 2016 turned out to be a quick half-day conference, high on fun and low on pretense. I mistakenly thought we had an hour to play the Agile Architecture game, which was already a short time for explaining the rules and playing once through, but it turned out we only had 45 minutes.
techcities-1 Generally we like to have 90 minutes and 2 hours works best. Kevin Matheny and I cranked through our short presentation on Agile Architecture and the rules of the game and jumped right into playing it with ~40 of our new friends.

We always played the game with software people in the past, so there were a few more questions about how to play than we’ve seen in previous games. But with a lot of individualized attention from ourselves and our three additional proctors, everyone was able to get through the game without being fired! Some even earned some gold pirate coins for completing their objectives!

If you have an interest in learning what life is like for an Agile Architect, let me know. Kevin is putting together these workshops going forward and I’ll be helping him out when I have the time.

Using the Altimeter on iPhone 6S with Swift

I was playing around with the new xcode 7.2 which allows you to beta test applications on your own phone without an Apple developer account.  Add to that the barometer available on the iPhone 6s and I just wanted to see how hard it was to write an app that can show you your altitude.

This seems like it would be pretty straightforward but it turns out there’s practically zero documentation on how to use the altimeter, and for a Swift newbie, this turned out to be quite a problem.

All I wanted to do was create an app with one button to start the altimeter, and a label which constantly updated with the relative altitude.  It seemed like something that might take an hour or two max.  However, with the incomplete solutions available and cryptic problems with refreshing the display while in a closure, it became much harder than I ever anticipated.

Which is why I’m publishing the code, however amateur, because it does actually work.

@IBOutlet weak var altitudeLabel: UILabel!

lazy var altimeter = CMAltimeter()
lazy var queue = NSOperationQueue()

@IBAction func trackButton(sender: UIButton) {

 if CMAltimeter.isRelativeAltitudeAvailable() {

        withHandler: {( data: CMAltitudeData?, 
                       error: NSError?) in

    // Needed to refresh the screen 
    // from inside the closure
    dispatch_async(dispatch_get_main_queue(), {
        self.altitudeLabel.text = 
           String("%.2f feet",
           ((3.28 * 
  } else {
    self.altitudeLabel.text = 
       "No barometer available"

It did finally work and looks like this:


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!

Open Source North, A Great Start for a Tech Conference in MN

The OpenSourceNorth conference put on this weekend by Solution Design Group was a rocking success.  Local design, local speakers and just a little local beer made for a good time.

IMG_2174Best Buy had a recruiting booth at the conference and hopefully you had a chance to stop by and chat either with a recruiter or an engineer.  If not check out the BestBuy.com jobs located here.

osn_pic2I had a chance to give a new presentation on how and why engineers should be engineering managers, at least a few of them.  If we ever want more great places for engineers to live and work, someone needs to create them.  Only individuals that understand how software engineering really works can create those places.  Here’s a picture from the conference.

If you couldn’t make it this year, put it on your calendar for next year.

Revolutionary’s Revenge

Sometimes I think I studied the wrong field in college, I should have been a political scientist or a historian. Having studied in those fields it may have helped me understand that the worst thing that can happen to a revolutionary is to win the war and end up governing.

A true revolutionary is not doing what they do because they are seeking power, they are championing an idea, a culture or a different way of life. They believe it; to the point where they’ll risk their lives in a real war, or their professional career if they work in a corporation. We’ll stick to corporate revolutionaries for now, it’s a little bit safer.

The thing to remember is that most revolutions fail, which is great because the corporate revolutionary can move on to the next place with their ideals intact and their pride unblemished. They haven’t had to face real decisions that would affect how they view themselves and their core beliefs.

But what if the unthinkable happens and the revolution succeeds? Now you’ve got a bunch of idealistic, stubborn, socially awkward and politically unsavvy people running your organization. No one wants that, you’ll be replaced by “real managers” the second you make a big mistake.

First, believe that a powerful force is waiting on the sidelines to determine whether the result of the revolution is a new paradigm that improves the old, or a purveyor of ideals that must be snuffed out quickly lest they infect the entire organization. As the new governing body, you need to exude ineptitude while clandestinely shoring up political position and making some new friends of old enemies. Once you’ve established a culture and moved systems beyond the point of no return, you can show your true hand, your competency, and institute the revolutionary ideals that were the driver of all the change.

This is where reality sets in. Running a revolution and governing a semi-stable organization are two distinct beasts. In revolutionary times, it’s us against them, there’s always a big enemy out there to drive camaraderie and take the brunt of negative emotions as they crop up. However, once the enemy is gone, the emotions turn inwards and now you are left arbitrating disagreements between former allies and making decision you know are bad, but are necessary to prevent chaos.

The skills of the revolution are not the skills of maintaining and building incrementally on top of established practices. If you cannot make the shift to sustaining governance, everything you fought for will eventually collapse and regress to the mean. Temperance, consensus, collaboration, compromise are all words that would cause the revolution to fail, but are necessary to sustain the new system over time. Operating in the same environment for multiple years is massively more difficult than moving to new gig every year. It is also massively more rewarding to see a system build, grow and become the new normal. After five years it is firmly in place and no longer can be replaced, that is, until the next revolutionary comes along…