Skip to content

Latest commit

 

History

History
executable file
·
220 lines (194 loc) · 8.69 KB

architecture-cheat-sheet.md

File metadata and controls

executable file
·
220 lines (194 loc) · 8.69 KB
Raw

Architecture cheat sheet

Communication is more than half of the work of an Enterprise Architecture practice.
The real goal is to make your architecture easy enough to understand so that people can make the right decisions.

What architecture is:

  • Architecture != Tools & Frameworks
  • Postponing decisions about Tooling and frameworks
  • Focus on customer, not environment

Architecture trade-offs

  • Build vs Buy
  • Coding vs Configuration
  • Product customization

Architects ( roles )

  • Enterprise
  • Solution(System)
  • Software(Technical)
  • Infrastructure

Architecture Design

design

  1. Analyze Business Drivers, Stakeholders
  2. From Assessment (result of evaluation) need to set Goals and more specific Outcomes
  3. Gather Requirements from each Outcome
  4. prioritize Requirements - find out ASR
  5. split them to Functional and NonFunctional Requirements

    provide the appropriate level of details to allow develop/implement the solution.

  6. Define Quality Attributes for NonFunctional Requirements
  7. Depict Current Architecture
  8. Design Target Architecture ( with Options to achieve MVP )
  9. Migration Plan to target architecture

Agile and Architecture

  1. not exhausted UpFront design
  2. Documentation only with critical points
  3. Main contributors of decisions - Stakeholders
  4. Incrementatl design
  5. Growing Architecture
  6. Value is visible after 2-3 releases

Architecture context

architecture context

Start drawing, drawing focus and purposes, requirement gathering before drawing

Perspectives

  • inside-in

    develop a broad understanding of what clean-up would be required
    within each domain in scope

  • outside-out

    develop a broad understanding of the
    overall business-ecosystem, in its own terms,
    independent of our own organisation

  • outside-in

    develop a broad to detailed understanding of
    how others would interact and transact with our organisation, from their perspective

  • inside-out

    (usually together with a detailed inside-in): develop a detailed architecture
    for each domain, each from its own perspective,
    drawing on each of outside-in perspectives for guidance

Purpose/Viewpoints

inside-in

  • Informing achieve understanding or obtain commitment.

    The main goal is to elicit feedback to make sure that the communication is effective.

  • Deciding support the process of decision-making and often target managers

    The main goal is to obtain a decision or a choice between several options.

  • Designing support the design process from initial sketch to detailed design

    The main goal is usually to define or refine a target.

Content

  • Overview - helicopter view on a subject which usually mixes multiples domains

    targets decision-makers or enterprise architects.

  • Coherence/Collaboration - focus on one specific topic, but seen through multiple complementary angles.

    collaboration between people, processes or tools.

  • Details - focus on one specific topic and zoom in only one of its aspects.

    subject matter experts or software engineers.

Drawing

  • avoid line crossing
  • bigger elements will be understood as being more important
  • Align elements on a grid and between each other.
  • Use whitespace instead of actually using a visual group.

Waterfall++ - V-Model system design

v-model

Design thinking

  • emphasize
    • hot points
    • who is asking
    • no tech discussions
    • goals ( business, tech )
  • define
    • deep understanding
    • questions
    • use cases
  • idea
    • how to
    • solution architecture
  • prototype
    • implementation
  • test

ADR

Architecture Decision Records also can be used during development/implementation phase ( not only architecture/design )

  • Context
  • Decision
  • Refused options
  • Status
  • Assumptions
  • Constraints
  • Consequences

resilient architecture

  • Timeouts
  • Graceful Degradation
  • Retries
  • Exponential Backoff
  • Circuit Breakers

Application general schema, application demands

  • development
  • operations
  • support
    • L1
    • L2
    • L3
  • data migration ( for evolution/revolution )

Why software architecture

software architecture

Why to make a documentation:

mindmap
documentation)Documentation(
    {{one common vision}}
        common bird-eye view
        naming conventions
        decrease sketching time for each meeting
    {{part of DefinitionOfDone}}
        visibility
        knowledge sharing
    {{one point of truth}}
        new team member
        existing team memeber
        external teams
    {{interchange responsibility}}
        split hard tasks
        real Agile
Loading

Data Architect

EKI

Data + Context = Information
                 Information + Action = Knowledge
                                        Knowledge++ = Experience

Business values of data

  • cheaper
  • better
  • smarter

Data Strategy

  1. caputre & collect
  2. clean & prepare
  3. $ - capitalize

Examples

Big Data cluster

Useful links

books

  • books collection
  • books collection
  • System Design Interview – An insider's guide ( Alex Xu )
  • Software Architecture in Practice ( Len Bass )
  • The Software Architect Elevator ( Grehor Hohpe )
  • Clean Architecture ( Robet C. Martin )
  • Domain-Driven Design: Tackling Complexity in the Heart of Software
  • Software Architecture in Practice ( Len Bass )
  • The Software Architect Elevator ( Grehor Hohpe )
  • 97 Things Every Software Architect Should Know ( Richard Monson )
  • 37 Things One Architect Knows ( Gregor Hohpe )