«    »

Architects as Scouts

Software architects have many responsibilities and expectations placed upon them which can be confusing to handle. For a while now I have been condensing these demands into a small set of metaphorical roles. I have found this helpful in staying true to my broader objectives as I move between tasks or problems.

The role that I want to share today is the architect as a scout in the military sense. A definition from Google is "a person sent out ahead of a main force so as to gather information about the enemy's position, strength, or movements." I like the military metaphor because software development is a team activity - the architect as scout is serving the rest of the team with the objective of helping keep the team moving ahead at a steady pace. This means being aware of what lies ahead, mapping the path forward, avoiding or eliminating obstacles, and being an initial target for hostile fire.

Awareness of what lies ahead

Architects need to be aware of what lies ahead in terms of both technical and business changes. The more accurate their picture of the future, the better their designs and decisions can be.

Awareness of the technical domain includes staying current on new libraries, frameworks, and platforms (e.g. mobile), learning about new software development practices (e.g. DevOps), and knowing what new infrastructure might become available to the team (e.g. middleware upgrades, cloud).

Awareness of the business domain includes having an idea of what major new functionality the business is thinking of introducing (e.g. need for multidimensional data analysis), and also having an idea of what business events or changes might significantly impact the system (e.g. significant variations in business usage of the system from how it was originally modeled, resulting in a significant change in the load and/or data volumes).

As an example, I recently recommended planning to do some refactoring to eliminate some duplicate code in the generation logic for two reports. Since there was a lot of this repeated code and it was clearly identified and isolated making it an easy, low risk refactoring, I though this was an obvious decision. Unfortunately, after making the recommendation, I learned that the business was expecting to eliminate one of the two reports in the near future. This completely changed the value proposition of the refactoring, actually making it potentially harmful in that it might increase the work required to rip out the one report entirely down the road. As a result, I reversed my recommendation.

Mapping the path forward

Architects determine how to use new technologies and how to solution new requirements to map out a clear path forward for the rest of the team. By tackling the risky or unknown items early, architects help the team maintain consistent progress.

Architects can use spikes, experiments, and pilots to try out and validate new technologies, solutions, and practices. Sometimes architects cannot do more than a basic evaluation in complete isolation. One approach I have used is to then do a pilot with a single team while closely monitoring and providing guidance, and then evaluate the suitability for rolling the change out more broadly within the organization. In such a case the entire team doing the pilot becomes a scouting force for the entire organization, led by the architect.

Solutioning of major new requirements can involve build-versus-buy decisions, determining major new components or infrastructure required, and architectural-level design. The common objective is to clarify what the team will need to do and allow for advance planning for activities needing more lead time (e.g. provisioning of new infrastructure, installing new software, training on new technologies).

For agile teams mapping the path forward typically means working an iteration earlier, ahead of the majority of the team, to ensure that business requirements are ready for the team to work on in the coming iteration and to ensure that there are minimal surprises with any new technologies or solutions. Architects can also be a source of technical requirements that are part of the product backlog. These activities help ensure that the team maintains a consistent, predictable velocity in delivering business value. Some agile teams might not have someone named explicitly in the role of architect, but all teams at least occasionally need someone operating as a scout to chart the waters ahead.

Dealing with obstacles

Architects need to identify and then avoid or eliminate obstacles that will potentially prevent successful delivery of the software or impede the team's progress.

Sometimes these obstacles are tricky technical issues that the team is having trouble resolving. As an example, one time I became involved in solving a performance problem with a batch process that took ever-increasing amounts of time to process individual records as the batch process ran. The problem was hard to find because it was not due to any particular piece of application code, but to how Hibernate (the underlying object-relational mapping library) was being used. To fix the problem I had to adjust the overall design of the batch process to reduce caching within Hibernate (follow the link to read more about the technical details).

Obstacles sometimes arise when the business raises requirements that are overly complex or extremely challenging to implement, especially in terms of meeting non-functional requirements such as performance or scalability. Architects sometimes need to push back on these requirements, or at least raise the alarm regarding the higher risk to ensure that sufficient time and resources are allocated to dealing with it.

Obstacles are not just with the software being developed or its requirements - they can also arise with respect to the project or external stakeholder expectations. For example, if management imposes an unrealistic delivery schedule on the team then architects are responsible for raising the alarm and helping determine ways to mitigate the risk.

Target for hostile fire

Architects serve as lightning rods for the team to initially bear the brunt of external problems or threats, especially those technical in nature. In this role architects act as a buffer to avoid having the team distracted or demotivated by these types of issues.

While the term 'hostile fire' is a metaphor, sometimes there are people in the organization who really are hostile. This may be due to political fallout from unpopular decisions, or stakeholder unhappiness with the software (e.g. due to poor performance or crippling defects). When the issues are technical the architect is the first contact - hearing the complaints and taking responsibility for what the team has produced. This is seldom pleasant, but is one of the responsibilities that comes with the role.

Sometimes the hostile fire really is a metaphor for tools or technologies that are too bleeding-edge or otherwise do not work as advertised. The architect then must confront the pain points and determine whether it is manageable or whether the tool must be scrapped and an alternative selected. Hostility may arise as a result of these issues or the resulting decisions, either from the team itself if they discovered these issues using a product proposed by the architect, or from parties within the organization outside of the team that are promoting or mandating the use of the problematic tool.

One example of this is years ago when new version control software was being introduced to replace CVS. I had not been involved with the initial pilot, but had heard disturbing things about the tool despite the decision to move ahead with its adoption. So I volunteered my team to be one of the first adopters and basically did my own evaluation. Shortly after transitioning to the new tool, I discovered a major design flaw that made it unusable. Efforts to work with the vendor to get the problem rectified failed, so I presented the situation to management and the decision to abandon the tool was made.

In conclusion, if you are an architect or functioning as a scout for your team ensure you are aware of what lies ahead, map out the path forward, deal with obstacles, and be the first contact for hostile fire.

If you find this article helpful, please make a donation.

Leave a Reply

(Not displayed)

«    »