What the argument boils down to is this: good solutions architecture should enable success by default. The goal seems clear, but getting there is the tricky bit. Practicing good solution's architecture (according to Ted) involves multiple dimensions including:
- Understanding technical and business requirements
- Understanding constraints, like budget and release dates
- Reassessing the two points above constantly
- Aligning and educating your team with the solution architecture
Architect's are educators. They are technically proficient, and are capable
of backing up ideas or diagrams with code. They work with the business to
understand both the functional and non-functional requirements. They can
help the business get what they want sooner, and don't introduce technical
complexity without good reason.
Architecture is one of those topics in software development that screams with controversy. Ted mentioned today a the biggest reason why is that software development as a science is still in its infancy. Compare us to other disciplines like building architecture, which has been around for thousands of years. We've really only been on the map for the past fifty.
I'm encouraging Ted to publish his slides, because the idea of an Architectural Catalog or Taxonomy is going to be essential for us, as an industry, to grow up. I want to echo the need for software developers to start thinking about architecture beyond just what frameworks we're using, but understanding the business and team constraints as well.
Let's hope we get to a software architecture renaissance soon. Could you be the next Michelangelo of software?
No comments:
Post a Comment