ArchitecturePatterns - hpepper/henpep-dev-tools GitHub Wiki

Architecture Patterns

Introduction

References

Vocabulary

  • ADR - Architecture Decision Records
    • lessons 55 and 141, 106
  • ATAM - Arcitechture tradeoff analysis method
  • Aggregate - (TODO what is the difference between federate and aggregate?)
  • Business logic -
  • Federate -
  • Message topic -
  • Message queue -

Architecture patterns vs Design patterns

TODO

Pattern Overview

Pattern usage:

  • Blackboard pattern
    • Use
      • Speech recognition
      • protein structure identification
      • summer signal interpretation
    • components
      • blackboard
      • knowledge source
      • controller
    • See:
    • looks for data with e.g. pattern matching
    • Questions
      • A mix of producer-consumer with controller?
  • Broker pattern
    • Use
      • message broker software, e.g. AMQP
      • Connecting a client to a server, where different clients can request different services
      • e.g one client might need mass calculation on a car, where another client might need cost calculation on the car?
    • structure distributed systems with decoupled components
      • these components can interact with remote service invocation
    • Broker coordinate is responcible for the coordination of the communication among components
      1. servers publish their capabilities to a broker
      1. clients request a service from the broker
      1. the broker the redirects the client to a suitable server
    • The client doesn't know anything about the server, just the broker, so the servers can be replaced
    • allows for dynamic change/addition/delition/relocation of objects and makes distribution transparent to the developer
    • Downside
      • requires stanadization of service descriptions
    • Isn't this also a specialization of the 'layer pattern' where here there are only three layers and the server layer can be represented by multiple servers/components.
    • It also seems like a client-server with a broker in between.
  • Client-Server pattern
    • Use:
      • e-mail
      • banking
      • document sharing
    • How is this different from the layer?
      • Is the only difference that the server can have multiple clients?
      • A client server could be one way that two layers communicate?
    • Situations where multiple components connect to a single component for results to queries.
  • Controller-Agent pattern
    • Distributed services
  • Event-bus pattern
    • Use
      • andoid development
      • e-commerce applications
      • notification services
    • Recieve events, publish them to listeners
    • Questions
      • How is this different from the 'broker pattern'?
        • It sounds very much like a specialized broker pattern, to me.
  • event-driven architecture
  • Interpreter
    • Questions
      • What is the concept here?
      • What is the difference to the 'pipe-filter' pattern
  • layered architecture pattern
    • Enable autonomy of components, different teams can own different layers and only have to worry about the interface for the neighbor layers
    • One layer focuses only on a single concept.
      • Does this also make it easier to maintain?
  • microkernel architecture
    • good architecture when you have a lot of exceptions (in business flow?)
      • useful for systems that have custom processing or processing is susceptible to change
    • plug-in modules can easily be added and removed
    • supports evolutionary design
    • easily adapts to changing requirements
    • easily adaptable into another pattern
  • Microservices architecture
    • Use
      • ?
  • Model-View-Controller pattern
    • Seems like a special version of the 'pipe-filter pattern' where one of the components can receive messages from both of the other components.
  • Peer-to-peer pattern
    • Use
      • File sharing network
      • multimedia protocols
      • crypto currency
    • Support de-cantralized computing
    • highly robust in a failure of any given node
    • highly scalable
    • no guarentee of quality of service
    • security is dificult to ensure
    • All agreements have to be negotiated, no component can dictate anything to another component.
    • Questions
      • 'Client-server' has been pushed into a single layer?
      • Can the server aspect have multiple foreign clients connected, in a single instance
        • Or will each server instance always have both the server and client component in the client-server component?
  • Pipe-filter pattern
    • Devides complex processing tasks into a series of simpler tasks, called filters
    • Use: e.g. Compilers
    • How is this different to the layer pattern, isn't this just a one-way layer pattern?
    • Buffering
    • Synchronization?
    • Flowing data through components, where the components should only know how to receive and how to send to their neighbors
    • Useful for smaller deterministic systems with a distinct processing flow
    • filters can easily be added and removed
    • provides for a high level of decoupling
      • de-coupled - easy to add or remove component
    • support evolutionary design
    • able to easily adapt to changing requirements
    • can easily be incorporated into another pattern
  • service-oriented architecture
  • space-based architecture
    • Implementation is very complex
    • it's all about variable scalability...
    • good for applications that have variable load or inconsistent peak times
    • not a good fit for traditional large-scale relational database systems
    • relatively complex and expensive pattern to implement
Layered Event-driven Microkernel Microservices space-based
Deployment - + + + +
Development + - - + -
Overall agility - + + + +
Performance - + + - +
Scalability - + - + +
Testability + - + + -
  • Deployment - how easy/fast/complex is the deployment
  • Development
  • Overall agility: the ability to respond quickly to a constantly changeinng environment.
  • Performance
  • Scalability
  • Testability

my notes

So differnt part of the application/ can use different architecture patterns.

e.g.

  • Acces to The storage could go through a 'Layer pattern'
  • and inter-block communication could happen via the 'Broker pattern'

layered architecture

  • presentation layer - user interface
  • business layer - business rules and business logic
  • persistence layer - persistence ... ???
  • database layer - storage

All layers are closed, meaning the presentation layer has to talk to the business layer in order to get something from the persistence layer.

The request always asks down, never up. The business layer will never ask the presentation layer

Smell: If you start passing things through a layer, then that is an indication that you are using the wrong pattern. (This is also known as the 'sinkhole anti-patter')

  • Every layers architecture will have at least some scenarios that fall into this, it is probably ok as long as no more than around 20% of the scenarios use passthrough on some layers(,p7).

Open layers can be skipped. e.g. a service layer can be open, and thus be skipped.

A layer can contain multiple components. (The SwArcDoc had a layer view)

Good:

  • general purpose architechture
  • easy to implement, test and govern
  • Provide isolation; changes in a layer will only affect the layer directly above the layer being changed.
    • and the changes in the layer only affetc the layer above, if that change is in the API.

Bad:

  • Performance not good
  • Scalability not good.

Advantages? You can relatively easy replace layer implementation

Examples of use:

  • ?

event-driven architecture

See: 007_architecture_patterns_part_1.mp4

aka:

  • EDA - Event Driven Architecture

  • SEDA - stage EDA

  • Event -> event queue -> event mediator -> multiple event channels -> event processors

We have(all individual):

  • Events

  • Process ( can push out new events, that other process can react to)

  • Event - (Ric15,p12)

    • initial event - sent from the client to the event mediator
    • processing event - generated by the event mediator and recieved by the event processing components.

  • event queue -

  • event mediator - seems to hold all steps related to each intial event(Ric15,p14)

    • responsible for orchestrating the steps contained with the initial event(Ric15,p13)
    • it knows of the steps required to process the inital event(Ric15,p13)
      • initial event: customer relocation
      • steps(processing events):
        • change address
        • recalculate quote(for ensurance)
        • update claims
        • adjust claims
        • notify insured
      • It seems that each processing event is synchronous
      • per default steps are only done one at time, but might sometimes some mught be done in parallel
    • e.g.
      • Apache Camel - a rule-based routing and mediation engine
        • empowers you to quickly and easily integrate various systems consuming or producing data.
      • Mule ESB
      • Spring Integration
    • The 'event mediator' can also be replace with a 'broker' technology instead(Ric15,p14)

  • event channel -

    • used by the event mediator to asynchronously pass specific processing events related to each step in the inital event tothe event processor(Ric15,p13)
    • can be
      • message queues
      • message topics(most widely used)(Ric15,p13)

  • event processor -

    • contains the application business logic necessary to process the processing event(Ric15,p13)
    • self contained
    • independet, highly decoupled
    • perform a specific task
    • can be
      • fine grained - perform a single task(Ric15,p13)
      • coarse grained - perform complex tasks
    • You must continuously think about which events can and can't run independently and plan the granularity of your events processors accordingly(Ric15,p18)

  • highly decoupled

  • highly distributed

  • often a high degree of complexity

  • Good for event-based business models and business processes

  • Not good for processes which require a high degree of data sharing, orchestration and reuse.

There are three topologies:

  • Event processor topology
    • for: mediation and orchestration
    • usually centralized or federated event processor
    • Has an event queue
    • Push out to event topic(another name for queue?)
    • Event -> event queue -> event processor -> (multiple) event topics -> (multiple) processes
    • The processor is a component that can do
      • some level of orchestration
      • some level of transformation
      • some sort of mediation
  • broker topology
    • merely for transport
    • e.g. RabbitMQ
    • processes are listeners on specific topics
    • Event -> event topic -> process
    • Process -> event topic -> process
  • broker-less topology
    • all processes needs to know of the processes they should send events to
    • event -> process-a -> process-b -> ...

Smell:

  • if you are using separate processors for something that should be an undivided transaction, this is probably not the right pattern for tour application(Ric15,p18)

When to use:

service-oriented architecture

See: 007_architecture_patterns_part_1.mp4

  • Good pattern for understanding and implementing business processes and services
  • Very high level of complexity
  • Difficult to implement due to complex tools, hype, misconceptions and heavy business user involvement
  • Do not use of you have few shared services

Elements and components

  • business services(BS)
  • Message bus
    • process choreographer - coordinate BS'
    • service orchestrator - linkes the one-to-many between BS and ES'
  • Enterprise services(ES) (designed based on the BS?)
  • Application services(AS) (ES talks to this)
  • Infrastructure services (ES and AS) talks to this)

Business services(BS)

Business services template:

  • type - always abstract
  • owner - business users
  • granularity - course-grained
  • scope - enterprise-level
  • notes -
    • contains name, input, outputs and process flow
    • independent of any technical implementation or protocol
  • examples -
    • ProcessClaim
    • ExecuteTrade
    • PlaceOrder

Ask: What do you do as a business (you do not create customers)

Enterprise services(ES)

Enterprise services template:

  • type - concrete
  • owner - architect or shared services team
  • granularity - course-grained
  • scope - enterprise-level
  • notes -
    • custom or vendor implementation
    • one-to-one or many-to-one relationship with business service
  • examples -
    • CreateCustomer
    • CalculateQuote
    • CheckCompliance

application services

Enterprise services template:

  • type - Concrete
  • owner - application development team
  • granularity - fine-grained
  • scope - application-level
  • notes
    • bound to a specific application context; generally not shared
    • used for validation, database query and updates
  • examples -
    • addDriver (driver of vehicle
    • addVehicle
    • getInventoryCount

Infrastructure services(IS)

Enterprise services template:

  • type - concrete
  • owner - app dev team
  • granularity - fine-grained
  • scope - enterprise-level (because ES can also invoke it)
  • notes
    • supports application and enterprise services
    • implement non-business functionality
  • examples -
    • ?

Message bus

Responsibilities

  • process choreography
  • service orchestration
  • Service registry
  • protocol transformation
  • message enhancement
  • message transformation

e.g

  • CreateQuote ->
    • Message bus
      • CreateCustomer
        • AddDriver
          • WriteAuditTrail
        • AddVehicle
          • WriteAuditTrail
      • CalcQuote
        • CheckDrivingRecord
          • WriteAuditTrail

Pipeline architecture / pipe-and-filter arc

  • 008_architecture_patterns_part_2.mp4

  • pipeline architecture

  • Useful for smaller deterministic systems with a distinct processing flow

  • filters can easily be added and removed

  • provides for a high level of decoupling

    • de-coupled - easy to add or remove component

  • support evolutionary design

  • able to easily adapt to changing requirements

  • can easily be incorporated into another pattern

Consists of:

  • Pipe
    • Uni-directional for performance, but could be message-based for scalability
    • payload can be any type (text, bytes, object, etc.)
  • Filter
    • self-contained and independent form other filters
    • usually designed to perform a single specific task
    • four filter types (producer, consumer, transformer and tester)
      • Producer, a starting point, outgoing only
      • transformer -input, processing, output
      • tester - input, discard or pass-thru
      • consumer - ending point, inbound only

pipeline vs. event-driven

They are very different

  • pipeline:
    • synchronous data filtering
    • single target for pipe
    • simple single purpose filter
  • event-driven
    • asynchronous event processing
    • multiple targets for event
    • complex multi-purpose processors

mircrokernel architecture / plug-in arc

008_architecture_patterns_part_2.mp4

  • good architecture when you have a lot of exceptions (in business flow?)
    • useful for systems that have custom processing or processing is susceptible to change
  • plug-in modules can easily be added and removed
  • supports evolutionary design
  • easily adapts to changing requirements
  • easily adaptable into another pattern

e.g. Eclipse

Components:

  • core system
    • minimal functionality to run system
      • smallest possible to run the system(to be functional)
    • general business rules and logic
    • generally doesn't contain custom processing
  • plug-in module
    • standalone independent module
    • specific additional rules or logic

space-based architecture

008_architecture_patterns_part_2.mp4

  • Implementation is very complex

  • it's all about variable scalability...

  • good for applications that have variable load or inconsistent peak times

  • not a good fit for traditional large-scale relational database systems

  • relatively complex and expensive pattern to implement

Refs:

Components

  • processing unit
    • module
    • in memory data
    • (optional) persistent storage
    • data replication engine
  • virtualized middleware (This seems to be the front-end to the processing unit)
    • messaging grid
    • date grid
    • processing grid
    • deployment manager

Anti patterns

Architecture by implication

010_architecture_antipatterns_part_1.mp4

I'm not sure where this fits in (maybe if you start coding before the arch doc?)

  • what architecture pattern are you using

  • what client model is most appropriate?

  • which platform is best for this solution?

  • does the hw or os matter?

    • most of the times: no

  • how will you handle component integration?

  • What communication protocols are you going to use?

  • is the solution feasible given the skills, budget and time?

  • how secure does the system need to be?

  • does the system need to scale?

  • how much performance is needed from the system

  • how available does the system need to be

  • do you need to be concerned about maintanability?

  • be careful of overconfidence

  • remember that agile methodologies are not a substitute for creating an architecture

Cover your ass-ets

010_architecture_antipatterns_part_1.mp4

Continue to document and present alternatives without ever making an architecture decision

Witches brews

010_architecture_antipatterns_part_1.mp4

architectures are designed by groups resulting in a complex mixture of ideas and lack of clear vision

each architect has their own idea of what needs to be in the architecture document, and they are all conflicting

Fix for the anti-pattern

  • A, single, responsible and knowledgeable architect
  • architecture validation and tradeof analysis (A-ATAM)
  • ongoing architecture discussion and peer reviews

Gold plating

010_architecture_antipatterns_part_1.mp4

Continue to define the architecture well past the point which the extra effort is adding any value.

  • too many details hide the core principles and standards
  • commonly leads to the analysis paralysis anti-pattern in the the initial architecture is never actually released
  • adding gold plating to a well-defined architecture significantly increases costs with little or no value
  • a complex and overly-detailed architecture s hard to understand and comprehend; no "big picture"

Vendor ruler

010_architecture_antipatterns_part_1.mp4

product-dependent architectures leading to a loss of control of architecture and development costs.

e.g. SAP

Fix

  • use a message bus to talk to the 'vendor ruler'(SAP)
    • Now we have "vendor app as a service"

Big bang architecture /aka bug up front design

010_architecture_antipatterns_part_1.mp4

Designing the entire architecture at the beginning of the project when you know least about the system

remediation:

  • only architect what is absolutely necessary to get the project started and on the right track
  • let the architecture evolve throughout the project as you discover and learn more about the system
  • don't forget the following things change constantly, and so must the architecture:
    • requirements
    • technology
    • business needs

armchair architecture

011_architecture_antipatterns_part_2.mp4

  • aka 'paper architect' because all it creates is paper, without code

  • aka 'ivory tower architect'; decision are brought down from on high without any knowledge of what is going in in the software.

  • whiteboard sketches are handed off as final architecture standards without proving out the design

    • Occurs when you have non-coding architect
      • You have to understand the feasibility of the architecture
    • occurs when architects are not involved in the full project lifecycle
    • occurs when architects don't know what they are doing

how to avoid:

  • stay current and try to carve out some coding for yourself, even it it is proof-of-concept code.
    • or try to find time to code review
  • the best architects are the ones who have been in the trenches themselves and know the fallout from bad architecture decisions
  • be careful not to release architecture decisions and standards too early
  • be sure to be an integral part of your development team

playing with new

011_architecture_antipatterns_part_2.mp4

  • incorporating unproven technologies into an architecture that don't really fit the problem at hand

Be careful about being the pioneer, because you are finding all the edge cases

remediation

  • when introducing a new technology, ask yourself:

    • purpose?: what value is it delivering
    • proven?: is this a proven technology for your situation?
    • overlap: is there something we have that is already supplying this functionality?
    • feasibility: does you team have the skills necessary for the technology?

  • RDA - resume driven architecture

    • When an architect wants to expand their resume the pick up the new technology

spider web architecture

011_architecture_antipatterns_part_2.mp4

Creating large number of web services that are never used just because you can.

Leasons:

  • just because you can create a web service at the click of a button doesn't mean you should
  • let the requirements and business needs drive what services should be exposed

infinity architecture

011_architecture_antipatterns_part_2.mp4

Creating architectures and interfaces that are over-generalized with infinite flexibility

generalized architectures that solve every possible need are expensive and difficult to maintain and change (often where you hear "you may need")

instead: use domain-specific architectures to reduce architecture and system scope

remedy:

  • Apply business requirements
    • if there is no business requirement then don't architect it
  • Business goal
    • if there is does not support a business goal that is relevant between now and three years, don't include it
  • business direction
    • are we heading for a merger
    • prepping for buy up
  • industry trend

also: generalized interfaces between components provides infinite flexibility, but at a cost...

  • componen-1 -> hashmap -> component-2
  • great, but where's the contract?
    • how to I find out what component 2 needs?

groundhog day

011_architecture_antipatterns_part_2.mp4

critical architecture decisions made early on are lost, forgotten, or not communicated effectively

aka; e-mail driven architecture (EDA)

symptoms:

  • people forget or don't know a decision was made
  • the same decision keeps getting discussed and made over and over and over...
  • no one understands why a decision was mad and they begin to question it again and again

avoidance techniques

  • capture all important architecture decisions in some sort of work product(doc, wiki, etc) and make it centrally available
    • prefer wiki, it is live
  • make sure the right stakeholders know about critical decisions and where to find them.

stovepipe architecture

011_architecture_antipatterns_part_2.mp4

an ad-hoc collection of ill-related ideas, concepts, and components that leads to a brittle architecture

symptoms:

  • lack of proper abstraction
  • lack of an integration solution
    • [integration, seems to mean; how components talk to each other. And that the same communication method should be used as widely as feasible]
  • lack of architecture guidance
  • architectures that are difficult to change, difficult to maintain, and break every time you change something

related anti-patterns, that tend to lead to stovepipe architecture:

  • architecture by implication
  • witches brew

other architecture patterns

Producer control flow pattern(react pattern)

  graph LR;
  A[Event producer] -->B[event channel]
  B-->C[event consumer]
  D[msg]-->A
  E[flow monitor]-->D
  E-..-B
  • flow monitor - service that monitors event channels and look for delayes/penned up messages
    • wait for upper threshold.
    • tell producers to slow down
    • wait for lower threshold
    • tell producers to resume

Tools

012_tooling_and_documentation.mp4

  • Pick the best tool for the job & the lifecycle station(where you are at in the lifecycle)
  • reevaluate when friction appears
  • invest in suitable replacements
  • build anti-corruption layers

Documentationa

012_tooling_and_documentation.mp4

  • UML - Fowler distilled

  • MDA - Model driven architechture

  • Have a docs directory - root of all documents

  • subfolders

    • current - useful enough to update
      • As soon as it stops being worth your time to update these, then move them to archeology
    • archeology - interesting historical artifacts
      • for figuring out: why are we doing it a certain way instead of different way.

Integration architecture

  • Enterprise Integration Patterns is a book by Gregor Hohpe and Bobby Woolf

Integration styles

  • file transfer
    • pro:
      • universal integration style
      • integration simplicity
      • system decoupling and system abstraction
    • con:
      • file-based processing is expensive
      • error processing
      • timeliness of data synchronization
      • data-only transfer
  • shared database
    • pro:
      • near-universal integration via SQL
      • system abstraction
      • system decoupling
    • con:
      • cannot use persistence caching (ORM) Object Relational M
      • performance bottleneck issues
      • schema change issues
      • data ownership issues
        • tightly couple
  • remote procedure invocation
    • what
      • web service
        • rest
        • corba
    • pro:
      • data encapsulation and ownership
      • external integration via web services
      • mature frameworks and tools
    • con:
      • tight system coupling due to dependency on service availability and location knowledge
      • poor asynchronous communications
  • messaging
    • pro:
      • asynchronous and reliable messaging
      • highly decoupled systems
      • excellent scalability capability
      • monitoring
    • con:
      • external integration beyond firewall
      • implementation and testing complexity
      • cross platform standards still evolving

Enterprise architecture(EA) context

014_enterprise_architecture_concepts_and_fundamentals.mp4

About identifying and addressing the gap between capabilities and the business goal

Primary goals:

  • to facilitate change

Specific goals:

  • provide strategic technical and architecture vision and direction
    • How to we get from current it to business goal
  • lead architecture transformation and organizational change
  • ensure IT capabilities match business needs and goals
  • establish architecture and process oversight and governance
  • communicate goals, metrics and value across the organization

ATAM

014_enterprise_architecture_concepts_and_fundamentals.mp4

Architecture Monday

Architecture styles

  graph LR;
      A[architecture styles]-->B[monolithic];
      A-->C[distributes];
      B---D[layered architecture];
      B---E[modular monolith];
      B---F[microkernel architecture];
      C---G[microservices architecture];
      C---H[service-based architecture];
      C---I[service-oriented architecture];
      C---J[event-driven architecture];
      C---K[space-based architecture];

style template

  • When to use

  • When not to use

  • rating

    • abstraction:
    • agility:
    • deployability:
    • elasticity:
    • evolvability:
    • fault-tolerance:
    • interoperatbility:
    • low-cost:
    • maintainability:
    • performance:
    • scalability:
    • simplicity:
    • testability:

microservices architecture

  • Lesson162 - Microservices Architecture

  • single purpose functions deployed as separate units with each unit owning its own data.

  • bounded context (share nothing architecture)

  • When to use

    • time to market
    • cloud based deployments

  • When not to use

    • large monolithic data, especially relational data that cant be broken apart
    • tight time and budget constraints
    • dev teams organized by technical layers (ui, backend, db, etc.)
    • highly semanticly coupled functionality

  • rating

    • abstraction: 1
    • agility: 5
    • deployability: 5
    • elasticity: 4
    • evolvability: 5
    • fault-tolerance: 5
    • interoperatbility: 3
    • low-cost: 1
    • maintainability: 5
    • performance: 2
    • scalability: 5
    • simplicity: 1
    • testability: 5
graph BT
  C1[client request]
  C2[client request]
  C3[client request]

  U[api layer/gateway] --- C1
  U --- C2
  U --- C3

  subgraph S1[service component]
   m1[module]
   m2[module]
   m1~~~m2
  end

  subgraph S2[service component]
   m3[module]
   m4[module]
   m3~~~m4
  end

  subgraph S3[service component]
   m5[module]
   m6[module]
   m5~~~m6
  end

  subgraph S4[service component]
   m7[module]
   m8[module]
   m7~~~m8
  end

  S1 --- U
  S2 --- U
  S3 --- U
  S4 --- U

  D1[database]
  D2[database]
  D3[database]
  D4[database]
  D1 --- S1
  D2 --- S2
  D3 --- S3
  D4 --- S4
  • Database - could actual be a table in a database.
    • where the service is the owner of

Service-based architecture

  • Lesson163 - Service Based Architecture

  • Well-defined independent domains deployed as separate units of software.

  • When to use

    • fast time to market.
    • high agility.
    • works well with space based architecture.
    • monolithic database, that can't be split.
    • migration or green field target when you are moving to microservices.
      • this could be the first step.
      • allows you to identify the domains, and you do not have to split the database.
      • once deployed we can identify which service components that should be split into microservices.

  • When not to use

    • MTTS(mean time to start) is high
      • slow to respond to higher demands
    • high symantic coupling between the domains(service components)
      • too much comunication between the service components.
    • when we have too many services(above 12)
      • if you have too many domains, then you probably are better served with micro services.

  • rating

    • abstraction: 1
    • deployability: 4
    • elasticity: 2
    • evolvability: 3
    • fault-tolerance: 4
    • interoperatbility: 2
    • low-cost: 4
    • maintainability: 4
    • performance: 3
    • scalability: 3
    • simplicity: 3
    • testability: 4
graph BT
  C1[client request]
  C2[client request]
  C3[client request]

  U[user interface layer] --- C1
  U --- C2
  U --- C3

  subgraph S1[service component]
   m1[module]
   m2[module]
   m3[module]
  end

  subgraph S2[service component]
   m4[module]
   m5[module]
   m6[module]
  end
  subgraph S3[service component]
   m7[module]
   m8[module]
   m9[module]
  end

  S1 --- U
  S2 --- U
  S3 --- U

  D[database]
  D --- S1
  D --- S2
  D --- S3

  • Service component - domain service

    • coarse grained. Represents all the functions of a domain
      • tracking/shipping/order fulfillment, analytics
    • usually have 3-12 services
      • if we go beyond 12 services then we will start to have change control problems. And we will be moving into micro-service land.
        • TODO what problems?

  • user interface layer -

    • can be broken into smaller units, even down to having one user-interface per service component.

  • Database -

    • can be a monolith and can be broken appart even to the point of one database per service component.

  • micro-service - signal, purpose, function

  • architectual quantum - TODO seems to be a set of a single client request, user interface layer, service component and database.

Frameworks

Zachman Enterprice Framework

Lesson 156 - Zachman Framework in 10 Minutes

  • TODO how do I map this to the SwArcDoc?
What How Where Who When Purpose
executive perspective inventory identification process identification distribution identification responsibility identification timing identification motivation identification scope context
business perspective inventory definition process definition distribution definition responsibility definition timing definition motivation definition business concepts
architect perspective inventory representation process representation distribution representation responsibility representation timing representation motivation representation system logic
engineer perspective inventory specification process specification distribution specification responsibility specification timing specification motivation specification technology physics
technical perspective inventory configuration process configuration distribution configuration responsibility configuration timing configuration motivation configuration tool components
inventory sets process flows distribution networks responsibility assignments timing cycles motivation intentions
  • What - inventory sets and entities
    • executive perspective: list of entities that are important to the business.
      • if a cto comes in this is their first question; give me an inventory of all you have.
    • business perspective: business entities and their descriptions
    • architect perspective: system entities
      • e.g. applications and databases.
    • engineer perspective: list of technologies and platforms.
      • What is used to implement the system entities described in the architect perspective.
    • technical perspective: all about infrastructure
      • hardware, networks and other infrastructure entities.
  • how - function and process flows
    • executive perspective: list of major processes the business performs
      • e.g. processing claims
    • business perspective: business process model
      • e.g how do we process a claim; what are the workflows for doing it.
    • architect perspective: system dependencies an communication flows
      • how do systems interrelate
    • engineer perspective: application processes
      • e.g. build and release procedures. e.g. Description of CI/CD pipeline
    • technical perspective: infrastructure processes
      • e.g. procurement, network routes
  • where - distribution network (where do things happen)
    • executive perspective: list of physical locations the business operates
    • business perspective: business process logistics accross locations
      • where do certain things happen
    • architect perspective: distributed system architecture and enterprise integration
      • which system is processing this part of the workflow
    • engineer perspective: application team distributions and locations
      • where our teams are located, do we use off-shore teams, do we have remote teams, where are their locations, how do they interrelate
    • technical perspective: physical topology locations(hardware and infrastructure)
      • are we cloud based? on-prem? the data center where is it?
  • who - actors and responsibility assignments
    • executive perspective: list of organizational units important to the business
      • who does what.
    • business perspective: business actor model and segment/product owners
      • which actors actor upon different parts of the workflow and systems.
    • architect perspective: solution architect system ownership
      • who owns what
      • which architect is responsible of the claims processing subsystem
    • engineer perspective: application ownership and logical security model
      • who is allowed to do what whithin each system
    • technical perspective: infrastructure owners and resposibility
      • who do I contact to get that network started up
  • when - timing cycles and dependencies
    • executive perspective: list of event cycles important to the business
      • monthly/quarterly/weekly/nightly processes the business has to do
    • business perspective: business event cycles and processing schedules
      • when workflows happen.
    • architect perspective: system level events and timin dependencies
      • availability needs and availability dependencies
    • engineer perspective: application availability and dependencies
    • technical perspective: hardware and network timing cycles and availability
      • e.g. when things come down for backup for example.
  • purpose(why) - motivationa and intentions
    • executive perspective: list of important business goals and strategies.
      • where do we want to take the business
    • business perspective: business plan and business/segment objectives
      • e.g. what the segments needs to do to achieve the executive goals.
    • architect perspective: structural(architectural) assertions and justifications.
      • e.g. reasons for using microservices
    • engineer perspective: application business value and capablities assertions
      • the capabilities we are putting into the systems
      • reasons for putting in the functionality
    • technical perspective: technical infrastructure operations justifications
      • reasons for migrating to cloud(TODO is this really at this low a level???) wouldn't it rather be reasons for selecting a certain cloud vendor?