Save time and effort in assessing your teams’ architectures with pattern-based architecture reviews
AWS Architecture BlogSave time and effort in assessing your teams’ architectures with pattern-based architecture reviewsby Rostislav Markov | on20 JUL 2022| inArchitecture|Permalink|ShareEnterprise 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 reviewsPBARs 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.Traditional architecture reviewsPattern-based architecture reviewsConsider system architecture as a highly stable documentation of all functional and system needs and their implementation planRequire detailed architecture documentationReview functional requirements, infrastructure configuration, and process specificationsFocus on technical configuration completenessAre used to sign off on architectural decisions and/or authorize the implementation planAdopt a continuous architecture mindset that focuses on enhancing system composition and quality attributesUse generalized solutions with existing architectural documentationFocus on identifying design inconsistencies and opportunities to improve on required system capabilities and quality attributes via architectural patternsIncrease developer productivity and identify opportunities to shorten the implementation plan through component re-usePBARs 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 asN-tier architecture, are applicable to many applications. After thepilot 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, PBARsemphasize composition through reusable codeTeams 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 dateWe 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 patternsTo 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 teamsWe also shared an initial set of design patterns, including:Containerized Spring Boot services withElastic Load Balancing,Amazon Elastic Container Service, andAmazon AuroraServerless services withAmazon API Gateway,AWS Lambda, andAmazon DynamoDB,with extensions for data streaming and analysis (Figure 2)AWS Elastic Beanstalkdeployments ofAmazon Elastic Compute Cloud (Amazon EC2)-backed web servicesFigure 2. Containerized and serverless design patternsShorten review times by applying lessons learned from early adoptersPBARs 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 reviewBecause 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:SecurityAvailability and operationsDeployment processSpeed and reproducibilityQuality concerns and defectsIn 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.FindingsOur 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 toAWS LambdaandAmazon 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-ongame daysand performance load tests helped teams gain first-hand exposure to PBAR findings in simulated environments.Introducing pattern-based architecture reviews in your organizationIn 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 useAWS 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 workflowPBARs 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 informationUse the following links to learn more about patterns you can use on your next architecture review:AWS Architecture CenterServerless LandRostislav MarkovRostislav Markov is principal architect with AWS Professional Services. As technical leader in Strategic Industries, he works with AWS customers and partners on their cloud transformation programs. Outside of work, he enjoys spending time with his family outdoors and exploring New York City culture.
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 […]
Rostislav Markov
Architecture