It may seem obvious, but we need to ensure requirements are recorded and referred to during the projects life cycle. Especially with agile projects, requirements can change through the project, and any such decisions need to be logged and updated along with the reasons why they were changed.
There are specialist tools available to help do this, however, a simple spreadsheet or document and a central, easily accessible location is sometimes all that is needed. Other options could include Microsoft Teams, Microsoft SharePoint, or Azure DevOps. The point is that we don’t need expensive, specialized, architecture toolsets; we just need a log.
For each requirement, we should log who it came from, any reasoning behind decisions, and what technology choices have been made. The following is an example of something I often use:
Other information you may wish to capture includes risks, assumptions, and dependencies. However, the key point is that we should log the requirements and reasoning behind them so that we continually refer to them as our design progresses. We can also refer to our original decisions for future iterations or if we encounter issues later.
As we progress through a project, we will no doubt be questioned and challenged on our designs, or even need to alter them in response to changing business needs. How we respond to this feedback can help ensure a project is successful.
Getting feedback
Agile projects are run with continual feedback built in. At the end of each period of work, known as a sprint, the customer is given a chance to see what has been built and feed back on what works and what doesn’t. The project team also has an opportunity to receive feedback as part of a lesson-learned activity, whereby all the people working on the project can discuss what worked and what didn’t and adjust accordingly for the next sprint.
Feedback is incredibly important to the success of a solution as the end goal is to create a solution that addresses the original business need and is usable. History is full of projects that failed simply because the resultant system was too difficult to use.
It can be challenging to accept feedback, but our role as architects is to help steer the business, and this is a two-way process of listening and adjusting.
For longer-running projects, business needs can change through the project. This is an inevitable consequence when solutions are large and complex, however, if our solution is flexible enough from the outset, we should be able to respond appropriately.
Cloud technologies are built with this type of flexibility in mind.
There are often many ways to achieve an outcome, for example, when a solution calls for a database, we can use Azure SQL Database, Azure SQL Managed Instance, or SQL running on a VM. We may start with Azure SQL Database, but as we start to build and test, Azure SQL Managed Instance may start to become more appropriate. Our solution designs must therefore be able to adapt in response to these challenges and changing requirements.
Another aspect of agile projects is that releases are iterative, each release building on the previous one, adding more functionality as we go. Again, as new features are added, we may need to adjust the components we use, either by adding additional services or changing existing ones.
We therefore need to be able to respond to feedback in a positive manner – any request to change or adapt is an opportunity to make our solution even better. By continually building on what we have learned throughout a project, and even across projects, we can bring value to the business as needed.
Summary
In this chapter, we have started to look beyond the AZ-304 exam requirements, moving away from technological choices, to look more at our working practices.
The success or failure of any project often comes down to how we engage with our customers. The closer we work with and understand their requirements, the better equipped we are to build our solutions.
We have looked at who we need to work with, who our stakeholders are, and highlighted one of the biggest challenges of capturing requirements: being able to correctly understand what is being asked for.
We have seen some common examples of questions we need to ask for each of the five main pillars of architecture: costs, operations, performance, reliability, and security. We have also seen some ideas on how we can record our decisions and why this is important.
Finally, we looked at the importance of responding positively to feedback and challenges, and why, ultimately, this helps us design better solutions.
In the final chapter, we continue beyond the exam theme, looking at some of the specific problems we may face as architects, and how we can address them.
Leave a Reply