Continuous Architecture : Embracing Multiple Viewpoints for Sustainable Solutions

The talk is shared at DDDesign Taiwan conference 2021. Aim to share as an architect, Kim Kao has spent for 8 years to find out a collaboration model with multiple stakeholders. In the agile era, it would be great to ask architects could have deeper engagement models with diversity takeholders, willing to co-work in detail, and come out continuous architecture beyond centrallized and transparent decision making records.

Transcript

1. 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
2. Agenda • Rapidly changing era against architectures • Why continuous architecture • Quality attributes of archiecture • Case sharing • Take away 1
3. “Rapidly change” is beating the Corp ...
4. How to survive in The disrupting innovation world
5. App architectures & patterns have evolved over the years
6. Start End Requirements • Goal alignment journey • Knowing different perspective from different Business • Multiple function stakeholders engaged • Ubiquitous Language led to the same understanding
8. 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
9. 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/
10. Comfort zone IT architects get used to reoslve tech issues. Simple, effective ... Business stakeholders just can’t invole in the digital world
11. Perception of Architects as not adding value
12. 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
13. Different Perspective working model Goal Finally, enterprise architect’s artifacts couldn’t adopt well. Security Architect Software Architect Solutions Architect Data Architect TOGAF
14. Architectural practices may be too slow Not related to real projects. Hands not dirty ! Shot & Run Cloud is not their option ! Old School insist ..
16. Extreme programming and software architecture First agile methodology – Kent beck 1996, XP Show, don’t tell ! ... ... (over year and years)
17. Where we are : architecture, agility, and continous delivery
18. 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
19. 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 !?
20. • 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
21. 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
22. 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
23. 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
24. 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
25. Quality attributes of archiecture
26. Pillars of AWS Well-Architected Cost Optimization Reliability Security Operational Excellence Performance Efficiency
27. 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
28. Reliability, Scalability issue ... Don’t design for unknown
29. In the past, transactions are measurable But for now, unpredictable You can’t measure incoming traffic due to too many integration points
30. 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?
31. Making and governing architectural decisions Provide Guidelines Visibilities
32. Goal Alignment Facilitating Problem Domain Resources alignment
33. 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
34. Put feedback loop in your architecture
35. 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
36. 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
38. Business IT Business leads to technology innovation Technology supports business growth Learnt from my first architect experience
39. 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
40. 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
41. Knowing the legacy Embrace multiple viewpoints Variety Stakeholder Goal & Vision Architecture diagrams
42. 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
43. Evolution journey 1 Macroservices 30 Microservices API enablement Service extraction 1 Monolith Short-term migration Mid-term optimization Tightly-coupled programs
44. 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
45. 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
46. 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
47. 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
48. 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
49. 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
50. 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
51. Continuous growing cloud architecture Infrastructure agility Application agility Innovations
52. 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
53. Thank you! Kim, Kao @yikaikao, Twitter @Kim Kao, Linkedin