One line of working code is worth 500 of specification
The task of a software architect is to design software. The specifications are important because they provide the pattern for building. Taking the time to think through the architecture is important, both on a macro level for interactions between components and on a micro level of behavior within a component. A systematic, detailed presentation and review of the problem space and the solution reveals errors and opportunities for improvement, sometimes in a startlingly dramatic way. Design is a beautiful thing.
Unfortunately it's far too easy to get wrapped up in the process of design, enthralled by architecture in abstract. The fact is that specifications alone have no value. The ultimate goal of a software project is a production system. A software architect must always keep an eye on this goal, and remember that design is merely a means to an end, not an end in itself. An architect for a skyscraper who ignored the laws of physics to make the building more beautiful would soon regret it. Losing sight of the goal of working code spells serious trouble for any project.
Value the team members who work on implementing your vision. Listen to them. When they have problems with the design, there's a good chance they're right and the design is wrong, or at least unclear.
If you're also a developer on the project, value the time you spend writing code, and don't believe anyone who tells you it's a distraction from your work as architect. Your vision of both macro and micro levels will be greatly enhanced by the time you spend in the belly of the beast bringing it to life.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Software Architect Should Know home page