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
Tweet

More Decks by Kim Kao

Other Decks in Technology

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

    View Slide

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

    View Slide

  3. “Rapidly change”
    is beating the Corp ...

    View Slide

  4. How to survive in
    The disrupting innovation world

    View Slide

  5. App architectures & patterns have evolved over the
    years

    View Slide

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

    View Slide

  7. View Slide

  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

    View Slide

  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/

    View Slide

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

    View Slide

  11. Perception of Architects as not adding value

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

  15. View Slide

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

    View Slide

  17. Where we are : architecture, agility, and continous delivery

    View Slide

  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

    View Slide

  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 !?

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  25. Quality attributes of archiecture

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

  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?

    View Slide

  31. Making and governing architectural decisions
    Provide
    Guidelines
    Visibilities

    View Slide

  32. Goal
    Alignment
    Facilitating
    Problem
    Domain
    Resources alignment

    View Slide

  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

    View Slide

  34. Put feedback loop in your architecture

    View Slide

  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

    View Slide

  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

    View Slide

  37. View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  51. Continuous growing cloud architecture
    Infrastructure agility
    Application agility Innovations

    View Slide

  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

    View Slide

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

    View Slide