The Role of the Software Architect

An architect's role is to provide technical vision, coordinate direction across teams/components, and counterbalance short term thinking.

— Karl Isenberg (@KarlKFI) July 7, 2017

What's in a Name?

Collaboration improves when the roles of individual team members are clearly defined and well understood.

— Tammy Erickson April 05, 2012

I recently switched roles, from distributed systems engineer to distributed systems architect. I've been doing professional software development for about ten years. I remember telling my boss five years ago that my five year plan was to be a software architect. Guess that worked out! (Now what!?)

Looking back, it's obvious that I'm much better equipped for the position than I was five years ago. But the role itself also seems to have changed over time, as the tech world has evolved to integrate agile tendencies. So as I approached the new position, I found myself needing to repeatedly answer the same questions. Here are some of my notes.

What is a "Software Architect"?

An architect is an engineer who empowers other engineers as a force multiplier.

An architect focuses on the big picture of the system as a holistic product, rather than owning individual components.

An architect drives consensus between tech leads and product managers, rather than making or dictating critical decisions.

An architect promotes flexibility by identifying potential interface points and presenting engineers with options to reduce the cost of change, balancing short-term tactics and long-term strategy.

An architect is a specialist with strengths in diagramming, documenting, communicating, information architecture, and system design.

What is a "Distributed Systems Architect"?

The title itself doesn't seem to have a commonly accepted definition. So let's build one from similar titles.

A systems architect defines the architecture of computerized systems to fulfill specified requirements. Such definitions include the design and specification of components, component interactions, interfaces, technologies, resources, and dependencies.

— Wikipedia - Systems architect

A distributed system is a model in which components located on networked computers communicate and coordinate their actions by passing messages to achieve a common goal. Significant characteristics of distributed systems include: concurrency of components, lack of a global clock, and independent failure of components.

— Wikipedia - Distributed computing

Therefore, a distributed systems architect is a systems architect who defines the architecture of distributed systems, with special focus on communication and coordination between components.

Increasing Complexity

Whether you call yourself a software architect, a systems architect, or a distributed systems architect, the computing landscape continues to evolve with or without you. A few things specifically have changed in the last decade or two that make these roles harder than they used to be.

1) The demand for high availability and intolerance of down time has caused components that used to be simple to be replaced by distributed systems. Likewise, previously distributed systems became systems of systems. With multi-layer systems it's no longer appropriate to rely on legacy architectural design patterns, like a single API layer or a single communication bus.

2) The demand for agility and larger development teams has mutated service-oriented architecture into microservice architecture. This mode of development pushes even more glue code out of the individual components and into the platform or infrastructure layers, increasing their complexity. Deploying and managing a sufficiently large system of microservices increasingly requires a container or application platform above and beyond the scope of modern infrastructure platforms.

3) The demand for hyperscale (the ability to quickly scale up and down without re-architecting) often calls for the architect to design a dynamic system that considers dramatic change over time normal to system operation. The ability to survive a flash crowd of users (aka the slashdot effect) caused by social media is increasingly required by even the most mundane of business domains. Preparation for this and similar phenomenon happens largely at the system level.

4) The demand for open source software creates proprietary systems that aren't completely controlled by their developers. Unlike proprietary components, where one company is in charge of development, open source components can be both easier to change (with a fork or local modification) and harder to persist change (merging changes upstream often requires politics, persuasion, and modification). Partial control of the architecture of a system is nothing new, but partial control over individual components (specifically their APIs and communication patterns) increases demand for intermediary translation, proxy, and caching services. These ancillary components are often tightly coupled with one component to allow loose coupling with another, but tight coupling in a microservice environment often requires new deployment and management patterns, like sidecars and pods.

Musings

Not all software engineers will or should aspire to be software architects. Architecture is a specialization of the engineering track for people who enjoy abstract thinking, are good at and enjoy documentation and diagramming, have the ability to be political and drive consensus, and have demonstrated a solid grasp on prior art and the competitive landscape.

An architect may or may not also be an engineering manager or tech lead, depending on how much focus on architecture is required or desired. Since being hands off of code tends to erode peer confidence and personal skill set, it is desirable that an architect continue to be partly involved in programming efforts, either through tool, component, or ecosystem development.

The bigger an architecture team gets, the more they tend to lose touch with the every day life of the engineers they're supposed to be supporting. However, the more engineers an architect has to support, the less time they will have to stay hands on with code. So a balance must be struck such that architects retain respect and skill yet also spend enough time on architecture to actually provide the benefit of a higher level perspective. It's a fine balance.

Ontological Evolution

The idea of a distinct architect role has in recent past become somewhat contentious among software engineering agile practitioners. The more senior a thought worker, the less they want to be told what to do. But at the same time, modern development patterns are pushing complexity out of individual components with well defined teams into the between space. Plus each component may have a life of its own: independent release cycles, independent versioning, multiple interface/protocol paradigms, independent motivations, and external contributors. Someone has to align these components and the teams that develop them, to unify them into a single cohesive system. So just as engineering practice has evolved, so must architecture practice evolve from controlling and managing technical vision to leading the direction of its evolution. And since collaboration is easier with clearly defined roles, hopefully this new definition can help point the way.


(Revised on 2017-07-13 to expound on the increasing complexity of systems and the increasing demand for architectural design.)

How To: Develop Good Managers

"people don’t quit companies—they quit managers" - Chris Loux

In my anecdotal experience, the above is often true.

Technically, I want the freedom to determine the best solution to a problem, even the freedom to figure out what the problem actually is. But career-wise, I want a manager who cares about my development and helps me identify and achieve my goals. If those aren't happening? I'm probably going to have a wandering eye, looking for better opportunities.

It's long been a quest of mine to figure out what a great manager looks like. I don't know if I want to be a manager yet, but I have pretty strong feelings about how I want people who manage me to behave.

While on that quest, I recently (re-)discovered a 2013 report by HBR on how Google researched and analyzed management to make Google a place top notch engineers want to work. I think the key takeaways are their top 8 behaviors of good managers:

A good manager:
1. Is a good coach
2. Empowers the team and does not micromanage
3. Expresses interest in and concern for team members’ success and personal well-being
4. Is productive and results-oriented
5. Is a good communicator—listens and shares information
6. Helps with career development
7. Has a clear vision and strategy for the team
8. Has key technical skills that help him or her advise the team

The other key takeaway is that in order to make sure managers knew what they needed to improve on they instituted a regular "Upward Feedback Survey" that would allow reports to provide numeric feedback about their managers in those 8 key areas. That feedback was then aggregated and reported back to each manager, so that they could improve.

Plus, this feedback loop was outside of the normal performance reviews. It was confidential and allowed managers to improve themselves. It's a development tool, not a performance metric.

Then on top of that Google provided optional management training courses, for managers to improve in the areas their feedback suggested.

It's really that simple.

1. Create a feedback loop
2. Analyze and report the metrics
3. Allow people to improve on personal areas of weakness without threat to their job

People want to improve. If they don't, you hired the wrong people.

TDD Is a Tool, Not a Religion

Catching Up

The internet is abuzz since DHH's blog post: TDD is Dead.
There have been many responses, including many by Bob Martin.

Breaking News

The latest new entry to the saga is a video conversation on YouTube where DHH, Martin Fowler and Kent Beck discuss the virtues and pains of test driven development. Definitely worth watching.

Subjective Summary

1. TDD scratches an itch. It's one way to make you feel good about your work, confident that it works as intended, every step of the way. 
2. TDD does not work well for all problems, like when the output is unknown or unquantifiable.
3. Self-testing code (programmatic & repeatable) is highly desirable, but TDD is not the only way to get there.
4. Heavy use of reflective mocking can tightly couple tests to implementations, counteracting one of the primary reasons to have tests: to enable refactoring. (Bob Martin has some thoughts on when and how to mock.)
5. Programming has many trade offs (testability, maintainability, usability, speed, etc.), and it is important to keep them all in perspective, re-prioritizing as needed, without becoming myopic.

Corollary

Just because writing unit tests and making them pass is easier and provides faster feedback than end-to-end tests doesn't mean unit testing is more important. It's critical that good unit design doesn't come at the cost of good system design.

I'll leave you with my favorite list of Object Oriented Design Principles. As with most sets of goals, it's impossible to satisfy them all all the time, but it's important to keep them all in mind, and know when to apply them.

You have a 'Go' for graduation.

Finally, another chapter of my life comes to a close. After five years at UCI I'm finally graduating (provided I pass my last math class). No one will know what the 'I' in ICS means in my degree, but at least I will know that it meant 5 years instead of 3.

Now I (try to) enter the work force, mostly mental exertion I'm betting. Everyone say's I've been limitting my job search too much, and that's probably true. I applied to Apple and Google and Blizzard. I would love to work at any one of them. I also applied at the two computer agencies at UCI, which would be both familiar and convenient.

The few phone interviews with Apple didn't go quite as planned. One didn't call me back and the other I blanked out on the 2nd technical interview and sounded like a unix nub.
Google never called.
Blizzard finally got back to me less than a month before graduation (many months after applying) for a web app dev position. I'd love to take that one, still waiting for a call back after the phone interview.
I went through the whole interview process at UCI, but it's been almost 2 weeks and I haven't heard back.

So I'm still looking, hoping for a 'real' career. Web apps or user interface design would be right up my ally. Lease is up June 30th. I'll be continuing work at Administrative Computing Services at UCI until then (working on the staff web portal, SNAP).

So between now and the 30th I need to have confirmation of a job and find a new apartment or else I'll be moving back home for a while. As much as I love my parents, it kind of feels like failure to have to go home after they put so much into my education.

Apple's just releasing a myriad of web apps and a ton of new iPhone upgrades, and the rest of the world is web app crazy. I didn't think I'd have trouble finding a place to do that. I'm really hoping to avoid startups. The failure rate is just too high. I need some consistent cash flow and some real experience before I would want to throw my fate in with a new company. I'd really like to be somewhere recognizable. For some reason I feel it's important to be able to tell people what I do, where, without getting blank stares.

My dreams for the future:
- Job
- My own apartment (my own room for the first time ever!)
- iPhone3G
- Nissan 350z (or 2009 370z)
- Niki