Decode User Requirements to Design Well-Architected Applications

This article was authored by Veliswa Boya & Jason Nicholls and published with permission.

In his book “War and Peace and IT,” Enterprise Strategist at AWS Mark Schwartz says that it’s time for the business-IT wall to come down. Old business models and stereotypes have long pitted “suits” against “nerds." He further goes on to say that it’s time to foster a space of collaboration and a shared mission - a space that puts technologists and business people on the same team.

The question is: how do we ensure the success of this collaboration when the two don’t even speak the same language? Business and technical professionals oftentimes do not understand each other’s terminology. Each discipline can have a different meaning for the same words.

In this reading, we will review how you as a technologist - here specifically referring to you, the architect - can listen and understand your key stakeholders and collaborate with them to understand what is most important. We will discuss how to decode some of the business “speak“ into a language that you can understand, therefore helping you understand what’s required by the business.

We will also review how the AWS Well-Architected Framework can then help with determining the most important architectural considerations for ultimately a well-architected application that meets the business requirements.

Misunderstood business requirements (domain concerns) are costly. What can start as a remark by a business can end up implemented in the software that makes its way into production.

How many of us have built a solution that turned out to not be what the customer wanted, all because we didn’t understand the requirement in the first place? It may be because of tight timelines, but we didn’t spend time on understanding what the requirements really are!

Misunderstood business requirements result in the following:

• Building the wrong product
• Wasting time and money building to a misunderstood specification
• Safety issues
• Delivery delays
• Failure to meet expectations, which results in loss of trust

First, the Core Expectations of an Architect

Earlier we talked about architects listening to key stakeholders and understanding their requirements. What else is expected from an architect? 

We won’t define the role of an architect, as this can be hard to do. We will however focus on 8 core expectations of an architect.

In their book “Fundamentals of Software Architecture: An Engineering Approach," co-authors Mark Richard and Neal Ford recommend that we focus on the following expectations as far as the role of an architect is concerned:

• Understand and navigate politics
• Possess interpersonal skills
• Have business domain experience
• Diverse exposure and experience
• Ensure compliance with decisions
• Keep current with the latest trends
• Continually analyze the architecture
• Make architecture decisions

Architecture Characteristics

Architecture characteristics are concerns that are critical to the success of the architecture, and therefore critical to the success of the system as a whole. During the business requirements definition, the business will specify domain functionality – which is commonly called “functional requirements” - together with the architecture characteristics.

The functional requirements, for the most part, tend to be clear as they define what the application must do >> the business logic. They influence some structural aspects of the architecture and are critical to the success of the application. Architecture characteristics are where the misunderstanding tends to come in.

There are many more Architecture characteristics: there is no fixed list, but there is a standard ISO 25000.

Architectural characteristics are not functional. Architecture characteristics can be explicit (expressed in the requirements doc) or implicit (not expressed) and we will focus on the characteristics below for the rest of the post:

• Auditability
• Scalability
• Availability
• Performance
• Security
• Legality

In fact, there is alignment between architecture characteristics and the pillars of the AWS Well-Architected Framework – but more on this later.

How do we translate domain concerns to architectural characteristics? 

“Architects need to practice being architects, just as developers need a chance to practice being developers.”

Ted Neward, who started Architectural Katas, had the idea that architects need practice just as much as developers need practice — and so the Architectural Katas were started, inspired by the Code Katas!

And what is a kata? The idea comes from martial arts/karate. A kata is an exercise in karate where you repeat a form many, many times, making little improvements each time.

Who knows of the infamous FizzBuzz code kata? There is a GitHub project that has collected a list of some kata exercises that are found on the Internet and the GitHub community.

The idea with both the Code Kata and the Architecture Kata is to create a safe environment for one to practice and fail over and over again, learn, and gain experience.

Architecture katas are not designed to have you come up with perfect architecture, but to train you towards how to come up with solutions — and provide you with a space to fail.

Architectural Katas

Katas are essentially group exercises where you work with peers (in this case, your project team) to arrive at the best architecture possible — you get feedback from each other, iterate, and improve on the initial architecture with each iteration.

The project team meets for a while and discovers requirements that aren’t in the original proposal by asking questions of the “customer,” who is usually the moderator during an architecture kata. It is at this phase that the implicit requirements are uncovered, and for any other questions that are not already covered by the requirements, you may ask the Moderator.

The phases that form part of an architectural kata are:

• Preparation Phase 
• Discussion Phase 
• Peer Review Phase 
• Voting Phase

Prepare

During the Preparation Phase, the project team is assembled, usually by the Moderator who will also be a facilitator of the kata. The Moderator is the customer or anyone who’s best placed to answer questions that the project team will have.

Discuss

During this phase, the project team figures out what they will be building. The team examines the requirements for the kata as given, and works out a rough vision of what the project's architecture will look like.

The team will ask the Moderator any questions you have about the project. It is also worth noting that at this phase, any technology is fair game as customers tend to not really care, most of the time, what kind of technology is used. It is therefore not necessary during this phase, to place too much focus on the technology that will be used to build the application.

Peer Review

During this phase, the project team will present the architecture led by the architect. It is also at this phase that all questions from the rest of the project team (especially the customer) will be answered.

Vote

Lastly, the entire team votes for the architecture that has just been presented, and this vote will determine whether there is another iteration or not.

Identifying Architecture Characteristics

What architectural characteristics can you derive from this — based on these requirements? What can you derive as far as system availability, security, and performance are concerned?

Each part of the requirement might contribute to one or more aspects of the architecture (and any may not). Here the architect will look for factors that influence or impact the design — particularly structural factors.

First, separate the candidate architecture characteristics into explicit and implicit characteristics. One of the first details that should catch the architect’s eye is the number of users — currently thousands, and perhaps one-day, millions! This means that we need to design for scalability in order to be able to handle a large number of concurrent users without serious performance degradation. This will be one of the top architectural characteristics. Notice that the problem statement didn’t ask explicitly for scalability but rather expressed the requirement as an expected number of users.

This is an example of architects decoding domain language (business requirements) into engineering equivalents!

There are many other characteristics here: can you identify elasticity or the ability to handle bursts of customers during promotions and specials?

AWS Well-Architected Framework

Earlier on we talked about how most of the architecture characteristics align with the pillars of the AWS Well-Architected Framework.

Once you’ve iterated to arrive at the architecture characteristics and have designed the architecture, you would then put that through the Well-Architected Framework review to ensure that it is according to the architecture characteristics that you uncovered when you iterated during the Architecture Kata.

We will now dive deep into this and see how and then look into why we are paying close attention to this alignment.

The AWS Well-Architected Framework helps cloud architects build secure, high-performing, resilient, and efficient infrastructure for a variety of applications and workloads. Built around six pillars — operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability — AWS Well-Architected provides a consistent approach for customers and partners to evaluate architectures and implement scalable designs.

The AWS Well-Architected Framework describes key concepts, design principles, and architectural best practices for designing and running workloads in the cloud. By answering a few foundational questions, learn how well your architecture aligns with cloud best practices and gain guidance for making improvements.

The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make while building systems on AWS. By using the Framework, you learn architectural best practices for designing and operating reliable, secure, efficient, and cost-effective systems in the cloud. The Framework provides a way for you to consistently measure your architectures against best practices and identify areas for improvement. We believe that having well-architected systems greatly increases your security, reliability, and the likelihood of business success.

Operational Excellence

The Operational Excellence pillar focuses on running and monitoring systems and continually improving processes and procedures. Key topics include automating changes, responding to events, and defining standards to manage daily operations.

Security

The Security pillar focuses on protecting information and systems. Key topics include confidentiality and integrity of data, managing user permissions, and establishing controls to detect security events.

Reliability

The Reliability pillar focuses on workloads performing their intended functions and how to recover quickly from failure to meet demands. Key topics include distributed system design, recovery planning, and adapting to changing requirements.

Cost Optimization

The Cost Optimization pillar focuses on avoiding unnecessary costs. Key topics include understanding spending over time and controlling fund allocation, selecting resources of the right type and quantity, and scaling to meet business needs without overspending.

Performance Efficiency

The Performance Efficiency pillar focuses on the structured and streamlined allocation of IT and computing resources. Key topics include selecting resource types and sizes optimized for workload requirements, monitoring performance, and maintaining efficiency as business needs evolve.

Sustainability

The Sustainability pillar focuses on minimizing the environmental impacts of running cloud workloads. Key topics include a shared responsibility model for sustainability, understanding impact, and maximizing utilization to minimize required resources and reduce downstream impacts.

In line with the architecture characteristics listed as prioritized earlier in this post, availability, scalability, and security — the architecture design will be evaluated against the following pillars:

• Availability ---> Reliability Pillar
• Security ---> Security Pillar
• Scalability ---> Performance efficiency Pillar

Over and above the architecture characteristics and the AWS Well-Architected Framework corresponding pillars, this architecture includes monitoring, which is provided by Amazon CloudWatch monitoring. This way speaks to another pillar that we are not focusing on here today — the Operational Excellence pillar.

The architecture that the team arrived at is a serverless architecture. Follow the link to learn more about serverless architectures and find out considerations that would have led to the architect opting for this versus non-serverless.

AWS Well-Architected Lenses

AWS Well-Architected Lenses extend the guidance offered by AWS Well-Architected to specific industry and technology domains, such as machine learning (ML), data analytics, serverless, high-performance computing (HPC), IoT, SAP, streaming media, the games industry, hybrid networking, and financial services. To fully evaluate workloads, use applicable lenses together with the AWS Well-Architected Framework and its six pillars.

Today we have 15 Lenses and the ability for you to build custom lenses.

Serverless Applications Lens

In this Lens, we focus on how to design, deploy, and architect your serverless application workloads in the AWS Cloud. For brevity, we have only covered details from the Well-Architected Framework that are specific to serverless workloads. You should still consider best practices and questions that have not been included in this document when designing your architecture.

It is recommended that you read the AWS Well-Architected Framework whitepaper.

For serverless workloads, AWS provides multiple core components (serverless and non-serverless) that allow you to design robust architectures for your serverless applications. Here we will present an overview of the services that will evaluate focusing on the services that we have in our architecture. There are eight areas that you should consider when building a serverless workload:

• Compute layer
• Data layer
• Messaging and streaming layer
• User management and identity layer
• Edge layer
• Systems monitoring and deployment
• Deployment approaches
• Lambda version control

Now let’s deep dive into the Compute, User Management and Identity, and Edge Layer and discuss how they meet the architecture characteristics we identified and the AWS Well-Architected Framework Pillars that we also identified.

Compute Layer

The compute layer of your workload manages requests from external systems, controlling access and verifying that requests are appropriately authorized. Your business logic will be deployed and started by the runtime environment that it contains.

With the compute layer, we focus on three AWS Services, of which two of them make part of the architecture that we are working with here.

1. AWS Lambda — AWS Lambda is a serverless, event-driven compute service that lets you run code for virtually any type of application or backend service without provisioning or managing servers. You can trigger Lambda from over 200 AWS services and software-as-a-service (SaaS) applications and only pay for what you use. 
2. Amazon API Gateway — Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. APIs act as the "front door" for applications to access data, business logic, or functionality from your backend services. Using API Gateway, you can create RESTful APIs and WebSocket APIs that enable real-time two-way communication applications. API Gateway supports containerized and serverless workloads, as well as web applications.

(It is worth noting that although we are only focusing on Reliability, Performance Efficiency, and Security as the Well-Architected Framework pillars due to the architectural characteristics that we are prioritizing – it is still worth considering the other pillars when designing the architecture. 

As an example, for Sustainability, one must always ensure to optimize areas of code that consume the most time or resources by using a service called Amazon CodeGuru to review code.) 

User Management and Identity Layer

The user management and identity layer of your workload provides identity, authentication, and authorization for both external and internal customers of your workload’s interfaces.

Edge Layer

The edge layer of your workload manages the presentation layer and connectivity to external customers. It provides an efficient delivery method to external customers residing in distinct geographical locations.

Amazon CloudFront provides a CDN that securely delivers web application content and data with low latency and high transfer speeds.

In conclusion, to get started with Architecting on AWS, there are reference architectures to help you do just this.

Take a look at our AWS Architecture Center for guidance on the AWS Well-Architected Framework, how to establish your cloud foundation on AWS, and some helpful resources on getting started with architecting on AWS.

Looking at our opening quote at the beginning of this post, do we see a future where the business-IT wall comes down?