Finding Harmony in Development Pt 4: The Architect
Ah, and we’ve made it to another segment of this little series. Today we’ll focus on the architect, what he is, what he does and why he matters.
In some situations the architect may be replaced by a generic manager, but I will state straight out that if your manager is not/was not a developer in their career, you’re better off letting your developers fill the role ad-hoc. The architect has to be able to see all the angles, but without a strong technical background it is nearly impossible to understand the development position.
The architect ultimately makes decisions and argues the case of the development process to any interested business units. It is a particularly demanding job requiring a mix of political acumen and people skills.Prioritization – Step 1
The Architect works out a plan of attack with The Analyst. Generally this is where a high degree of technical knowledge comes in handy, as The Architect will be able to provide ballpark estimates of the comparative difficulty of features up for prioritization.
Remember, nothing is written in stone in terms of time at this stage, but it is useful information to have for prioritization.
As always prioritization is based on business needs first and foremost.
All the rules still apply from The Analyst’s prioritization steps.
Specification – Step 3
The Architect will play any number of important roles during the specification process. As stated in The Analyst the story planning procedure involves all the major players, and may include everyone if the situation calls for it.
The Architect’s responsibilities in the planning meeting will include settling disagreements, facilitating discussion and ultimately making the call if multiple technologies are on the table.
First and foremost the architect is there to make sure all sides are communicating clearly, and to ensure that the vision comes together in the end.
Agile teams are generally fairly self-organizing, and with a bit of leadership a good architect can point his team in the right direction and get everyone working on the same page.
The Architect must above all adhere to the principals and methodologies of process. The buck stops with the architect when it comes time to defend process requirements to the business at large.
Step 3 – Iterations and Review
Much like step 2, The Architect makes certain that the process is handled respectfully by all sides, and that everyone remains on the same page throughout the process.
As features are added The Architect may also be called on to push back when a feature can not reasonably be accomplished and will require an extension to the deadline, or a postponement to a future set of improvements.
If the corporate culture does not allow push back where it is appropriate within the process then the process itself will not function correctly. While a lot of people will talk about a compromised agile the realities that agile is designed to deal with are not able to be compromised. Time does not suddenly stop so you can add more features and there are only two ways to add features that exceed any padding you might have in your schedule.
#1 Demand overtime from your developers. This can be used on occasion, but costs you developer good will and inevitably costs software quality.
#2 Accept significant decreases in software quality by the removal of processes such as test automation that are absolutely essential to doing software well.
Neither of these should be considered acceptable except under the rarest, most dire of circumstances (meaning that delays will cause severe legal or financial difficulties potentially leading in company dissolution).
Post-release – Step 4
After the software is released The Architect will continue a cycle of prioritization and story management with The Analyst per a normal maintenance cycle.
While the role of The Architect is not as hands on as some of the others it does require a singular viewpoint. The Architect must be able to accept the input of every single individual involved in the process and sort those opinions into useful, informed decisions.
The Architect also stands the considerable risk of taking heat due to deadlines missed, features cut and the like.
That being said, The Architect is key to making sure that the process works. Without someone spending the time, energy and effort to keep a software development team on track it is easy for disagreements over topics like “Is this a bug or feature” and “Can this be added by deadline” to turn into squabbles. The Architect manages the needs of the project while keeping the process first and foremost in his or her thoughts.