- You still have to focus on low-level components after decades of Computer Science.
- I feel like I create the same software constructs over and over again with no leverage. No higher-level abstractions.
- Producing up front architectural models and documentation is tedious and hard to get right.
After reading the article, it dawned on me that it would be nice if the industry placed more emphasis and value on software architecture practiced in the "guide" style. The guide style of architecture is good for the development team because if they are less skilled, the architect can help them improve their skills, understand the system, and make better decisions. It's good for the architect because if he/she helps the other members of the development team make better decisions, the architect will be able to make a big impact through leverage.
I like that. I've always valued leverage. When folks used to ask me about why I liked to manage people, I would say something like "Because I like to facilitate a group of people coming together to solve a problem." To me, that's one of the best things about being a part of or leading a team. Working together and solving the problem.
But, the industry doesn't seem to value the guide style of architecture. Clients want up-front technical documentation and the comfort that someone "in the know" is leading the software development effort and making good decisions. You certainly can't blame them for that. If I were a client, I'd sure as heck want it.
It leaves me feeling like I need to be both. I want to be the guide style architect, but I need to be the up-front, decision making architect too. It seems to me if you are around for the entire project, you can start off the up-front guy and transition yourself into the guide guy. So, you suck it up and take on the tedium up-front so you can have the fun on the other side. Maybe that's the outlook that will save my sanity.