Chapter 18: Engaging with Real-World Customers

In the last chapter, we completed the logging and monitoring topic, and the part of the book that covers the AZ-304 exam requirements.

In this chapter, we'll look beyond specific design considerations and look at more general working practices in cloud architecture. What we cover in this and the next chapter will not be included in the AZ-304 exam, instead, we'll look at how we work with customers to understand their requirements and provide some example questions to help capture them.

We will also look at some tips on how to record and keep track of our responses as well as how we should respond to feedback as we work through projects.

We will be covering the following areas:

• Working with customers
• Exploring common goals
• Mapping requirements
• Getting feedback

Working with customers

All solutions start with a set of requirements, usually business leads. After all, every solution is built to address a need, and this is often in response to either a new process, to address an inefficient process, or to provide some form of service.

A solution architect is often involved, if not leading, the requirements gathering process, and without a full understanding of the underlying business needs, we cannot complete a successful project.

There are several ways we can gather the information we need, but simply sitting down and interviewing stakeholders is probably the most direct.

Who are my stakeholders?

A stakeholder is a member of the business who has a vested interest in the solution being built. Usually, we start with the person or team who requested, or is at least sponsoring, the new service. However, if your remit extends to an application interface, we should also reach out to who will eventually become the end users, after all, the solution...

Exploring common goals

Microsoft Azure advises following what is known as the Well-Architected Framework, which covers the five key pillars that need to be considered when designing solutions.

Following these areas is a great way to ensure that your design has captured the main points and provide a starting point for your requirements gathering. As a refresher, the five pillars are the following:

• Costs
• Operations
• Performance
• Reliability
• Security

The questions you ask can and should be grouped into each of these areas, and we will look at some example questions for each area along with why they are important. We shall start with costs.

Understanding costs

We need to know how much a solution will cost to build, as well as how much it will cost to run. New solutions are often built as part of a project, and that project will have a defined number of resources in terms of people and technology. Once completed, a solution will have running costs, especially in...

Mapping requirements

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...

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...

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...

Further reading

• Azure Well-Architected Framework – https://docs.microsoft.com/en-us/azure/architecture/framework/
• Azure Well-Architected Review – https://docs.microsoft.com/en-us/assessments/?mode=pre-assessment&id=azure-architecture-reviewS