Continuous Architecture : Embracing Multiple Viewpoints for Sustainable Solutions Kim Kao, DDDesign Taiwan Community Co-founder Senior Solutions Architect | Developer Specialist SA @AWS Taiwan 2021-10-16 

Agenda • Rapidly changing era against architectures • Why continuous architecture • Quality attributes of archiecture • Case sharing • Take away 1 

“Rapidly change” is beating the Corp ... 

How to survive in The disrupting innovation world 

App architectures & patterns have evolved over the years 

Start End Requirements • Goal alignment journey • Knowing different perspective from different Business • Multiple function stakeholders engaged • Ubiquitous Language led to the same understanding 

No content

Current Challenges with software architecture • Focus on technology details rather than business context. • Perception of architects are not delivering solutions or adding value. • Inability of architectural practices to address the increase in speed of IT deliver and to adapt to modern delivery practices such as DevOps. • Some architect’s discomfort with or lack of appropriate skills for migrating their IT environment to cloud-based platform. 7 

Focus on technology details rather than business context 8 Why the IPs are not enough to run my workloads in Kubernetes? Why the traffic just came across different subnets, and costs a lot ? https://aws.amazon.com/tw/blogs/containers/eks-vpc-routable-ip-address-conservation/ 

Comfort zone IT architects get used to reoslve tech issues. Simple, effective ... Business stakeholders just can’t invole in the digital world 

Perception of Architects as not adding value 

Aechitecture Elevator Deep Dive into software structure Based on business context to come out solutions, “Sometimes lack of detail” Consider to support decision making data insights Security is the top principle Target on overall goal and business object to achieve Enterprise Architect Solutions Architect Data Architect Security Architect Software Architect 

Different Perspective working model Goal Finally, enterprise architect’s artifacts couldn’t adopt well. Security Architect Software Architect Solutions Architect Data Architect TOGAF 

Architectural practices may be too slow Not related to real projects. Hands not dirty ! Shot & Run Cloud is not their option ! Old School insist .. 

No content

Extreme programming and software architecture First agile methodology – Kent beck 1996, XP Show, don’t tell ! ... ... (over year and years) 

Where we are : architecture, agility, and continous delivery 

Architects realized they need to help agile team Agile team realized they need architect’s help to achieve multiple stakeholders’ need Scalability Reliability Security So, architects started adjust themselves to closer to agile team in adjusting their methodologies. Even need to learn cloud centric era new skills to build architecture. Whirling collaboration model 

Continuous Architecture Enterprise Architect Agile Developer Software Architect Let’s build up a 5 years plan Let’s do some tech stack decision Let’s get started coding Executive : Let’s build up an awesome building !? 

• Architect products; evolve from projects to products • Focus on qulity attributes, not on functional requirements • Delay design decisions until they are absolutely necessary • Architect for change – leverage the power of small • Architect for build, test, deploy, and operate • Model the organization of your teams after the design of the system you are working on Continuous architecture 

Continuous architecture contains • context of the system • Key functional requirements that will impact the architecture • Quality attributes that drive the architecture • Making trade-off from the cycle 

Difference between CA and traditional architecture approaches 1. End to end delivery 2. Not only in software architecture itself, but ask to have entire coverage 3. Way to avoid big-architecture-up-front syndrome 

Architectural decisions • Most of the time, architecture diagram is not readable or maintainable • Only authors realized the entire content • Key assests in the decisions should be recorded, try to use https://adr.github.io • 3 key points should be covered in adr • 1) clearly articulate all constraints related to a decision • 2) focus on quality attributes, not on functional requirements, its important to explicity address quality attribute requirements • 3) trade-off between the different opions and impact on quality attributes should be considered 

Way to increase survival rate for architeting in agile Microservice API API API EVENT Microservice Microservice API Legacy app API Microservice Microservice Microservice Modern App Legacy app API Microservice Microservice API Product platform Legacy app ARCHITECTURE EVOLUTION Decoupled product services Enabling rapid composition for innovation Developer & app dev services Building bobble system Integrate with legacy Builder-friendly platform Accelerating time from idea to production code Data platform Data & analytics UBIQUITOUS ACCESS TO DATA Self-service data strategy Making intelligence assets easily consumable Global infrastructure Core: Compute, storage, CDN, database, networking Security & compliance Management tools INFRASTRUCTURE AUTOMATION Make artifacts testable in time Freeing up developers to focus on business value Living Document FOR VALUE People, process, and Design Aligned to discrete business outcomes and value Operating model Product | Delivery | Finance | Training | Change 

Quality attributes of archiecture 

Pillars of AWS Well-Architected Cost Optimization Reliability Security Operational Excellence Performance Efficiency 

Managing failure “Everything fails, all the time.” – Werner Vogels, Amazon CTO “We needed to build systems that embrace failure as a natural occurrence.” Shared responsibility model AWS: Reliability of the Cloud Customer: Reliability in the Cloud 

Reliability, Scalability issue ... Don’t design for unknown 

In the past, transactions are measurable But for now, unpredictable You can’t measure incoming traffic due to too many integration points 

Building the quality attributes utility tree • Stimulus – Measure the revenue grows from achitecture changing • Response – should be stable in expected responding time • Measurement – SLA, costs, DR, RTO/RPO • Environment – Could support rapidly change , scalability and DR requirements? 

Making and governing architectural decisions Provide Guidelines Visibilities 

Goal Alignment Facilitating Problem Domain Resources alignment 

Architecture viewpoints Concurrency viewpoint Deployment viewpoint & Operational viewpoint Information Viewpoint Development viewpoint Functional viewpoint Context Viewpoint • Function elements • Responsibilities • interactions • Function elements • Responsibilities • interactions • information flow between subsystems • Dependencies • Environment • Runtime Process • monitoring • Reacting mechanism • Runbook/ Playbook • Live Document • Glossary & Ubiquitous Language • Tier/Layer design guideline • Architecture & Tech Stack Before refactoring : https://github.com/humank/microservices 

Put feedback loop in your architecture 

Common Themes in today’s software architecture practice • Principles as architecture guidelines • Architecture activities become a team responsibility • Becoming a discipline or skill rather than a role • Ability to design • Leadership • Stakeholder focus • Ability to conceptualize and address systemwide concerns • Life cycle involvement • Ability to balance concerns 

There is no finish line when it comes to reliability and availability 35 As an architect you design for the present, with an awareness of the past for a future which is essentially unknown ~ by Norman Foster 

No content

Business IT Business leads to technology innovation Technology supports business growth Learnt from my first architect experience 

New products Scenario : Business grows with external clients Growth Feedback Customer experience Improvements Usage • Modular existing products • Cross channel selling • Parallel develop teams overseas • Launch new branding platform in 1 year • <2 seconds responding time in each client • Stable release & GA cycle (2w/1 release) • Team members grow up from 20+ to 100 

1 Know the legacy Monolith to microservices Keep Hands dirty Step in sb’s shoes to know the tough 2 Automate your bureaucracy Introduce Unit Test/BDD/DDD/CI/CD 3 Build it in, don’t bolt it on Involve in the operation, design the co-work model 4 

Knowing the legacy Embrace multiple viewpoints Variety Stakeholder Goal & Vision Architecture diagrams 

Maximize speed to value • Value – maximize agility benefits in least amount of time • Speed – highly automated, mature, and fit-for-purpose tools • Achievable measurable business benefits in short term Minimize business and technical risks • Evolutionary transitions – No rip-and-replace – No big bang • Decomposition into workloads, then packages, then services • Proven patterns and tools – Proven scalable infrastructure • Hands-on pragmatic approach – Go build Evolution tenets 

Evolution journey 1 Macroservices 30 Microservices API enablement Service extraction 1 Monolith Short-term migration Mid-term optimization Tightly-coupled programs 

Data store evolution for agile services 1 Macroservices 30 Microservices Shared database One database per service Shared data store 1 Monolith Short-term migration Mid-term optimization 

Programs’ extraction • Programs’ grouping • Build up BA experts • Transactional consistency • Domain-driven design • Unit test to protect functionality Data extraction • Database split with schema separation • Split patterns – Beware of consistency • Adopt 2 Phase commit at early stage • Eventual consistence with queue service • Sagas, TCC vs. distributed transactions Extracting microservices 

Microservices? If using a shared database, it’s not a microservice … yet Macroservice Microservice Key characteristics Larger monolithic service Larger business domain Central shared database Independent deployable service Modeled around a business capability Own its own data Pros Transactional integrity & ACID Simpler code reuse Simpler deployment Simpler testing Simpler operations Organization autonomy Technology independence Polyglot architecture Scalability options Smaller blast radius Cons Teams’ coordination More coupling Slower release cycles Monolingual Distributed transactions, Saga, TCC Possible eventual consistency Operational complexity People skills gap 

Moving monolithic applications to microservices by gradually creating events and APIs for various components of the legacy application The strangler pattern https://martinfowler.com/bliki/StranglerFigApplication.html 

Bounded contexts are used to simplify complex models and teams; multiple bounded contexts results in smaller, easier-to-manage components Domain-driven design Opportunity Pipeline Salesperson Product Customer Territory Sales context Ticket Defect Product version Product Customer Support context 

Positive feedback 1. Start from coming-out with ubiquious language, using wiki and sticky notes anywhere 2. Break-out DB Link is amazing, way to controll access pattern 3. Keep hands-dirty POC earned trust, get familiared with business constraints 4. With test coverage, functionalities quality is good, lower down the re-produce bug rate 5. Sit-in with programers for pair, learn from each other 6. Keep growing transparent decision making documents 7. Architecture review is useful 

1. Agile development with CI / CD 2. Integrated development environment 3. Knowledge-based development - DDD 4. Service-enabled and modular applications 5. Elasticity with horizontal scalability 6. On-demand, immutable, disposable servers 7. Choice of compute, data store, and language 8. Broad data store access 9. Pervasive automation 10. Managed and fully managed services 11. Architects Elevator 12. Innovation platform 12 attributes for continuous architecture Architecture principles Domain-Driven Design Cloud Platform 

Continuous growing cloud architecture Infrastructure agility Application agility Innovations 

Continuous Architecture principles Visions - Know where to go Bi-direction voice Domain-Driven Design Multiple Viewpoints Hands dirty – Go with dev teams Agility Cloud platform Take Away 

Thank you! Kim, Kao @yikaikao, Twitter @Kim Kao, Linkedin