George Schlossnagle is a pretty smart guy, though he’s too self-deprecating to really want me to say so. But there’s no question that he’s been a major force in the way SparkPost—in fact, the entire industry of high-performance email delivery—has developed over the years. He co-founded Message Systems in the late 1990s to develop a remarkably scalable email infrastructure that has grown and evolved to serve as a key element of SparkPost’s stack today. Not only is the Momentum MTA core to the SparkPost service, but it’s also essential to the in-house infrastructure at the largest mailers like social networks, ISPs, financial services, and publishers. Momentum and SparkPost together carry more than 25% of the world’s non-spam email. So, yeah, George knows something about architecting software and services that scale really well.

What does it mean to design and architect software services at scale in the cloud? I recently asked George to share some of his perspective about the role of a software architect and how it compares to other aspects of coding and building software. Here’s what he said.

How do you define your mission as a cloud software architect? What are you trying to accomplish? What motivates you in this role?

In the simplest view, I look at my job as ensuring we design and build software to not only service the requirements we have today, but that puts us into a good place to execute on the requirements that might come tomorrow. The forward-looking part of the role is probably the most difficult—ensuring that the technology and design choices we make are not only good for the problem they’re aimed at but that they interoperate with all the other portions of the architecture and are likely to remain good choices as the architecture evolves.

What motivates me is a desire to build functional software that allows us to adapt to changes in the market and changes in how our users want to use it. I’ve been building parts of this software stack for almost 20 years, and being able to gracefully evolve to handle new requirements is the key to long-term success. Many (most?) individual technology choices end up getting reevaluated every 3–5 years, and it’s setting yourself up to manage those inevitable transitions whilst still providing a stable and reliable service that’s the exciting (and necessary) challenge.

You also happen to be a co-founder of our company, so you might have a particular understanding of how technology and business goals go together. How do you see the relationship between technical goals and business goals?

I think they’re intrinsically linked. The business being successful is what allows us to continue to innovate, and innovation is what allows the business to be successful. I can’t imagine how we could be successful as a business if our technology goals didn’t directly support our business goals.

“Ahead of its time” and “vaporware” are two great monikers for failures driven by those goals being out of sync.

Does having a software architect’s mindset affect how you approach non-technical challenges, whether in the business or elsewhere?

To the extent that an architect’s job is to look at the big picture and plan for that, yes.

Have you always been a technologist in your career? Did you begin work as a programmer?

I studied to be a mathematician and began my professional career as a systems administrator. That led me into web and database performance work, and I became heavily involved in the PHP internals community, helping build an open source compiler cache for the language. From there I helped found a scalability-focused consulting company, OmniTI, which ultimately led to where I am today.

That path gave me a real appreciation for how software runs in the real world, the impact of design choices on operability and reliability and the importance of getting actionable telemetry out of your products.

What’s difference between being a programmer and a software architect? (Or, for that matter, an engineering manager and an architect?)

Being an architect is about setting a technical strategy while a programmer is fundamentally a tactical role. As an architect, you need to ensure that all of your choices and designs come together in a cohesive way that will grow over time and adapt to future challenges. A good programmer has their focus on making the individual parts as solid as possible. While there’s often some overlap, these are independent roles and both challenging in their own right.

Engineering management is distinct from both of them. Management is the art of achieving through others; of getting a group of people to all align their activities towards a common goal. It’s faddish to diminish the contribution of managers, but a good manager can really drive the productivity of teams and it is a tremendously difficult skill. People are always the hardest part of any business—navigating personalities, egos, strengths, and weaknesses.

Looking back, what’s the moment in your career you realized this was the right role for you?

Throughout my career I’ve always been interested in how things come together to form a cohesive whole. Seeing how all of the technologies fit together to solve our business issues has always been really exciting to me.

What are you working on right now?

We are moving to the next generation of our cloud architecture now, and that’s an effort that’s spanned most of the development group here. I’ve also been active in driving a lot of our compliance technology (trying to keep malicious and unwanted users from exploiting our platform).

What’s your most important tool?

My most important asset is a phenomenal team of great people who have a great understanding of all the technologies we have. Being able to leverage that group to make informed decisions is awesome.

You’ve designed on-premises and cloud technology products. What’s been the most startling difference between architecting for the cloud instead of a more traditional, packaged software product?

I don’t know that there’s anything particularly startling. The biggest non-startling difference between architecting for the cloud is that it flips many of the traditional challenges of release software on its head. In an on-premises world, you have to be extremely conservative about quality control, because when you release a version into the wild it becomes its own entity and you cannot force your customers to upgrade. When you control the entire deployment cycle yourself, you can iterate much faster because you can instantly (and globally) roll back from any issues. This allows for a feature velocity that is tremendously larger than on-premises software.

What’s a misunderstanding about software architecture you wish you could dispel?

I think the (false) notion of hierarchy is a common misunderstanding. Recognizing that the best architect may not be the best programmer (I’m certainly not), or that great programmers may not be great architects. They’re different skill sets and reinforce rather than eclipse each other.

What should I have asked you that I didn’t?

You were pretty thorough. 🙂

I hope you enjoyed this window into how one of the principal architects of SparkPost sees his profession. The thoughtfulness with which George describes his point of view as a software architect and builder doesn’t surprise me at all—in my experience, it’s a hallmark of how George approaches most aspects of work and communication.

—Brent
@brentsleeper