AWS Architecture Blog
Save time and effort in assessing your teams’ architectures with pattern-based architecture reviews
Enterprise architecture frameworks use architecture reviews as a key governance mechanism to review and approve architecture designs, identify quality enhancements, and align architectural decisions with enterprise-wide standards. Architecture reviews are very thorough, but it typically takes a lot of time and teamwork to prepare for them, which means developers can’t always move as quickly as they’d like.
If your team needs a flexible, faster option to review their architecture, consider adopting pattern-based architecture reviews (PBARs). PBARs may not find every issue that a traditional architecture review will. However, in situations where you need to accommodate tight deadlines or budgets, changing project requirements, or multiple releases, they offer a simpler, quicker, more focused way to address issues and ensure your architecture aligns with business needs.
Pattern-based architecture reviews vs. traditional architecture reviews
PBARs use generic architecture patterns (in other words, generalized, reusable solutions to common design problems) to review non-functional system properties and align architectural patterns to business outcomes.
|
|
||
|
|
PBARs are broadly applicable to any cloud initiative, ranging from migration use cases to complex large-scale development initiatives. Here are just a few examples of ways to use them:
- With cloud migrations, PBARs help manage various infrastructure and integration patterns, including like-for-like moves and full refactoring options.
- A few infrastructure patterns, such as N-tier architecture, are applicable to many applications. After the pilot phase, these cloud infrastructure patterns serve as reusable blueprints for follow-on migrations, which reduces the amount of repetitive work and ensures compliance with security controls.
- With new development use cases, PBARs emphasize composition through reusable code
- Teams with novel uses are encouraged to verify the new pattern through early prototyping as opposed to heavy documentation and requirements analysis.
Use case: Applying PBARs across multiple teams to meet stringent go-live date
We introduced PBARs to a global industrial company’s large cloud development initiative where developers had no prior AWS experience and their go-live date was in six months. The initiative spanned over 50 development teams along 10 functional domains and 11 geographical locations from Americas to Asia. Each team was responsible for developing between one and six customer-facing aggregated services exposed via APIs (asset management, tenant billing, customer onboarding, or event analytics).
Socialize initial design patterns
To get the team to use PBARs, we advocated to adopt particular managed/serverless services to reduce management overhead, as shown in Figure 1.
Figure 1. Proposed AWS services for use by development teams
We also shared an initial set of design patterns, including:
- Containerized Spring Boot services with Elastic Load Balancing, Amazon Elastic Container Service, and Amazon Aurora
- Serverless services with Amazon API Gateway, AWS Lambda, and Amazon DynamoDB, with extensions for data streaming and analysis (Figure 2)
- AWS Elastic Beanstalk deployments of Amazon Elastic Compute Cloud (Amazon EC2)-backed web services
Figure 2. Containerized and serverless design patterns
Shorten review times by applying lessons learned from early adopters
PBARs were run by domain architects, team architects, lead engineers, and product owners. We also invited teams with similar use cases and system requirements for joint reviews.
They brought knowledge and experience that allowed the process to conclude within two weeks for all teams with minimal preparation—significantly faster than traditional reviews.
Complete reviews quicker and increase participation and understanding by focusing the review
Because PBARs move quickly, we had to be specific about the areas we chose to focus on improving or evaluating. We worked towards identifying inconsistencies between system requirements and pattern selection, any special needs, and opportunities to improve on non-functional requirements, including:
- Security
- Availability and operations
- Deployment process
- Speed and reproducibility
- Quality concerns and defects
In narrowing the PBAR’s scope, we were also able to complete the architecture reviews more quickly and increase participants’ understanding of the architecture and critical project needs.
Findings
Our technical findings showed single points of failure, service scalability limits, or opportunities to automate test/deployment/recovery processes.
The PBARs emphasized pattern reuse and, therefore, standardization in the early development phase. This required follow-on tailoring to individual use cases, such as distinguishing data ingest profiles by data type and throughput or moving from containerized deployments for data analytics jobs to AWS Lambda and Amazon Athena.
PBARs also provided actionable feedback on what to address prior to the go-live date.
- By emphasizing non-functional aspects, our PBARs helped create a case for zero-defect culture where fixing bugs had priority over new features.
- Early-adopter teams of architectural patterns served as internal champions, providing informal support to others on how to address review findings.
- Follow-on game days and performance load tests helped teams gain first-hand exposure to PBAR findings in simulated environments.
Introducing pattern-based architecture reviews in your organization
In large enterprises, PBARs serve as a demand intake mechanism for their cloud center of excellence (CoE). They facilitate adoption of established pattern solutions and contribute new use cases to the enterprise-wide roadmap of cloud architectural patterns.
Three organizational disciplines contribute to PBARs:
- Application teams envision system capabilities and outcomes and own decision-making on application design and operations.
- The enterprise architecture team oversee the adoption of architectural best practices and work closely with application teams and the cloud CoE to review architectural patterns.
- The cloud CoE approves and publishes pattern solutions and tracks their adoption in the cloud service catalog. At AWS, we use AWS Service Catalog portfolios to publish pattern solutions to developers.
Figure 3 describes the high-level process tasks and responsibilities:
- Application teams solicit PBAR with enterprise architects who help identify and customize suitable design patterns for particular use cases.
- If the use case requires novel pattern, architects work with the application team on early prototyping and approval of the novel system architecture. They also work with the cloud CoE team to generalize and publish novel pattern solutions in the service catalog of the cloud CoE.
To better align with agile development cycles, we recommend establishing internal commitments on the time to schedule and conduct PBARs as well as auto-approval options for teams re-using existing pattern solutions, in order to allow developers to move as quickly as possible.
Figure 3. PBAR workflow
PBARs provide lightweight architectural governance across enterprises. They help focus your teams on non-functional system properties and align architectural patterns to business outcomes.
As shown in our use case, PBARs enable teams to build faster and help change the perception of enterprise-wide architecture reviews as a corporate guardrail. For teams with novel use cases, PBARs encourage pattern validation through early prototyping and therefore provide modern alternative for agile cloud projects.
If you are looking to scale your cloud architecture governance effectively, consider adopting PBARs.
Related information
Use the following links to learn more about patterns you can use on your next architecture review: