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 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. Agenda • Rapidly changing era against architectures • Why continuous

    architecture • Quality attributes of archiecture • Case sharing • Take away 2
  2. Start End Requirements • Goal alignment journey • Knowing different

    perspective from different Business • Multiple function stakeholders engaged • Ubiquitous Language led to the same understanding
  3. 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. 8
  4. Focus on technology details rather than business context 9 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/
  5. Comfort zone IT architects get used to reoslve tech issues.

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

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

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

    beck 1996, XP Show, don’t tell ! ... ... (over year and years)
  10. • 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
  11. 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 !?
  12. • 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 6 principles of Continuous architecture
  13. 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
  14. 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
  15. 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
  16. Way to increase survival rate for architeting in agile Microservice

    A PI A PI API EVEN T Microservi ce Microservi ce API Leg acy app API Microservi ce Microservi ce Microservi ce Modern App Leg acy app API Microservi ce Microservi ce API Product platform Leg acy 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
  17. 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
  18. In the past, transactions are measurable But for now, unpredictable

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

    1 Monolith Short-term migration Mid-term optimization Tightly-coupled programs
  25. 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
  26. • 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
  27. 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
  28. Positive feedback • Start from coming-out with ubiquious language, using

    wiki and sticky notes anywhere • Break-out DB Link is amazing, way to controll access pattern • Keep hands-dirty POC earned trust, get familiared with business constraints • With test coverage, functionalities quality is good, lower down the re-produce bug rate • Sit-in with programers for pair, learn from each other • Keep growing transparent decision making documents • Architecture review is useful
  29. 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
  30. 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