"After three years of hard work, we have signed off on the system design."--A real conversation between a client and a software consultant in the late 90's after spending a small fortune on management consulting fees.
(gestures towards a wall of black 3 ring binders)
"We are so excited; now, how long will it take to build it? 6, 8 months?"
This waterfall type of thinking was rampant in the late 90's and early 2000's before agile started taking hold in software development in the mid to late 2000s.
Waterfall model By Peter Kemp / Paul Smith - Adapted from Paul Smith's work
Many businesses adopted "waterfall" because, as a process, it was easy to understand. In the .com boom of the late 90's traditional business felt pressure to get online or risk being left behind by young upstarts. Traditional "brick and mortar" companies would hire one of the big 3 consulting organizations, and find themselves on the hook for years of expensive consulting work to produce "requirements, documentation, and UML diagrams". And just like the construction industry, developers were just like the "carpenters, laborers and other grunts" with the thankless job of taking these designs and making them a reality.
Building software the "waterfall" way was simple, you check off the first two boxes of "Requirements" and "Design", and then "Implementation" was simply the translation from the design documents to code, more akin to "data entry" than "engineering", and the "Maintenance" would be some fixed price process that'd be roughly equivalent to one of the earlier phases.
The outcome of many large products using waterfall was failure and the industry learned and adapted to a more agile approach.
Post Waterfall "Architecture"
With the industry heading away from "waterfall" in the direction of being more agile, one concept / title survived and became more sophisticated, that of the "Software Architect". Wikipedia defines the Software Architect position as "necessary" because:
"OOP allowed ever-larger and more complex applications to be built, which in turn required increased high-level application and system oversight."
The Software Architect title itself has many variants (Solution Architect, Enterprise Architect, Application Architect, Chief Architect). What a person in one of these roles "does" (as described by Wikipedia):
"Software architecture is about making fundamental structural choices which are costly to change once implemented. " --WikipediaIn short the "architect" is different from the "coder", in that the "architect" is empowered to make the "big decisions that effect the project".
Although I've spent most of my career with the title "Architect" I've always felt a bit uncomfortable with the title, it has a definite air of superiority to it... And then after visiting other "architects" in the profession, or helping others obtain "architecture" certifications, it occurs to me why the title of "Architect" as a role on a software project is a bit of an albatross.
The reality is that most software projects desperately need is (in order):
And unfortunately the role of "architecture" is more akin to a "liason" and generally involves only these two of the (6) aspects.
My personal definition of the role that an architect fills on software projects is more in line with the definition of a "practitioner". What differentiates someone who is an "architect" from a "great coder" is:
"A software architect is responsible for communicating the design and direction of a software project to the team and anticipates, identifies and solves roadblocks while developing software." --Eric DeFazioThe reason I had to come up with my own definition verses Wikipedia one is to handle the realities of software development today. :
- Architecture is not "just" making decisions it is also living with the decisions (architects need to have Skin in the Game)
- The architect should be empowered to change the process (to shift priorities, reorganize the team if need be based)
- Architects need design and communicate the vision and direction within the development team in whatever means necessary (design documents, mentoring sessions)
- The core job of the architect should developer, else they are disconnected from the actual feedback loop of development (they might focus on nice to have ethereal solutions that might happen down the road completely overlook the fact that it takes 5 minutes to recompile the app for each developer, killing programmer productivity)