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 needs to be user-friendly otherwise it will fail. In fact, the scope that you must consider will largely drive who you need to communicate with.

Another example may be a data analysis environment. In this case, involving the data scientists who will be using the platform is crucial as they will have insights into the tools they use and how they are configured.

You also need to consider supporting teams, from security and monitoring to finance and technical support.

The security and monitoring teams will have very specific requirements in regards to the type of metrics they will need access to and how they will access them. Finance teams may need involvement to understand both any budget constraints and how the day-to-day operations will be paid for.

The technical support teams may similarly have existing toolsets and alerting mechanisms that must be interfaced with.

Often, we simply look for the most obvious stakeholders, but as we can see, there are far more people involved than we might at first consider. Once we have a list of people to speak to about the proposed solution, we need to ensure we can ascertain their requirements in an accurate way, which is often more difficult than it sounds.