In yet another new blog series, I want to break down what it means to be a software architect and what "architecture" means in the context of software. Sometimes when I give my elevator pitch on software architecture to people in person at conferences I get questions like "shouldn't the developers do that?" or "isn't that the project manager's job?" Ironically, every time the expected role is somewhat different, and that's our first clue.
Software architecture is the practice of documenting business demands in terms of technological implementation.
That's my initial attempt at a definition, but perhaps this will change slightly as we work through this series together. Over the years there are many different activities that have been front-and-center in my role as a software architect. A few of them include:
- Breaking down complex tasks into smaller, simpler tasks
- Documenting interactions between complex systems
- Selecting specific technology vendors or tech stacks
- Deciding when to take on technical debt, pay down technical debt, or even rewrite a system
- Writing extremely hard code (algorithmically speaking)
- Providing technical review of solution design or even complex pull requests
- Choosing algorithms, platforms, or approaches that will meet the scale and capability demands of the real-world system
Some thing that are very much out-of-scope for this role (and may need to be actively avoided) include:
- Making sure every application can handle Google-scale
- Choosing the very latest bleeding-edge technology
- Building your own platform/module/widget
- Supporting technical progress at the expense of business value
At the end of the day, an architect provides broad technical expertise across the full spectrum of a project or initiative, but also takes business demands and realities into careful consideration. The goal is always to produce a solid technical solution on a stable foundation, but not to generate unnecessary technical debt or business expense. We're called upon to be pragmatic purveyors of technical competence, but not to presume clarvoyance. In my experience, every time someone has attempted to predict future demands on a complex technical system they have been mistaken. Instead, build reliable systems that are as simple as possible (but no simpler) in an attempt to maximize future flexibility so that just-in-time decisions can be made once real-world knowledge exists to inform decision making.
In a perfect world, our applications would always be optimized for perfect performance at exactly the number of users attempting to use the system at any given moment in time. Any additional capacity would be wasteful, but any reduced capacity would generate opportunity cost.
But capacity is just one factor. Some of the various things under consideration when making architectural decisions include:
- Budget
- Number of users
- Skill level or experience of users
- Skill level or experience of development team
- Business value
- Expected useful/valuable lifespan of solution
And of course much more. Over the course of this blog series I'm going to be breaking down various aspects of architetural decisions and showcase the various competing need under consideration and break down how I would make the decision today (and perhaps explain what might make me change my opinion or why my opinion has recently changed).
Please understand that nothing is perfect and I'm no exception. I do find that my approach to software archicture is somewhat unique, and often met with skepticism from those who have not yet worked with me, but at the end of the day I produce consistent value for my clients. When even "bad" decisions can be celebrated, you've accomplished something good and the approach is one worthy of exploration.
So please join me on this adventure of software architecture over the next few months. Please leave comments or reach out to me on Twitter at @mrdowden to let me know your thoughts or to ask me questions for future articles.