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
   

   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