Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Continuous Architecture : Embracing Multiple Viewpoints for Sustainable Solutions

Kim Kao
October 12, 2021

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.

Kim Kao

October 12, 2021

More Decks by Kim Kao

Other Decks in Technology


  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. Start End Requirements • Goal alignment journey • Knowing different

    perspective from different Business • Multiple function stakeholders engaged • Ubiquitous Language led to the same understanding
  4. 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
  5. 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/
  6. Comfort zone IT architects get used to reoslve tech issues.

    Simple, effective ... Business stakeholders just can’t invole in the digital world
  7. 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
  8. Different Perspective working model Goal Finally, enterprise architect’s artifacts couldn’t

    adopt well. Security Architect Software Architect Solutions Architect Data Architect TOGAF
  9. Architectural practices may be too slow Not related to real

    projects. Hands not dirty ! Shot & Run Cloud is not their option ! Old School insist ..
  10. Extreme programming and software architecture First agile methodology – Kent

    beck 1996, XP Show, don’t tell ! ... ... (over year and years)
  11. 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
  12. 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 !?
  13. • 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. In the past, transactions are measurable But for now, unpredictable

    You can’t measure incoming traffic due to too many integration points
  20. 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?
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. Evolution journey 1 Macroservices 30 Microservices API enablement Service extraction

    1 Monolith Short-term migration Mid-term optimization Tightly-coupled programs
  28. 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
  29. 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
  30. 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
  31. 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
  32. 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
  33. 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
  34. 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
  35. 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