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
Tweet

More Decks by Kim Kao

Other Decks in Technology

Transcript

  1. Continuous Architecture : Embracing Multiple Viewpoints for Sustainable Solutions Kim

    Kao (高翊凱)
  2. Agenda • Rapidly changing era against architectures • Why continuous

    architecture • Quality attributes of archiecture • Case sharing • Take away 2
  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
  7. Why Continuous architecture

  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. 8
  9. 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/
  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. 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
  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 ..
  15. How architects survive well in agile world

  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 6 principles of 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

    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
  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 Developers Architects

  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. Case sharing

  37. Business Technology Business leads to technology innovation Technology supports business

    growth Learnt from my first architect experience
  38. 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
  39. 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
  40. Evolution journey 1 Macroservices 30 Microservices API enablement Service extraction

    1 Monolith Short-term migration Mid-term optimization Tightly-coupled programs
  41. 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
  42. • 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
  43. 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
  44. 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
  45. 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
  46. Continuous growing cloud architecture Infrastructure agility Application agility Innovations Production

    Microservices
  47. 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
  48. Thank You!