evolutionary architectures - mp3muncher.files.wordpress.com · web viewtip: when coupling points...

evolutionary architectures

· Evolutionary Data

· Pramod Sadalage, along with Scott Ambler, wrote Refactoring Databases, subtitled Evolutionary Database Design.

· Key to evolving dbs, particularly relational is the same ideas as code

· Tested

· Impact to an ORM

· Consider fitness functions

· Versioned

· Important as dB and code are symbiotic

· Incremental

· Automate the schema updating

· Changes incorporated into a delivery pipeline

· Incorporation of undo changes to help move forward and backward through changes

· Shard dB Integration

·

· DB often used to share data

· How avoid problems if 1 app wants to expand dB?

· Common solution is the expand/ contact pattern

·

· Age and quality of the data

· Tips

· Database transactions act as a strong nuclear force, binding quanta together.

· Refusing to refactor schemas or eliminate old data couples your architecture to the past, which is difficult to refactor.

· Building Evolvable Architectures

· Bring the different dimensions together of

· Fitness functions

· Incremental change

· Appropriate coupling

· Mechanics of operationalising analysis

· Greenfields

· Retro fitting existing architectures

· Migrating architectures

· Many senior developers build the same types of applications year after year, and become bored with the monotony. Most developers would rather write a framework than use a framework to create something useful: Meta-work is more interesting than work. Work is boring, mundane, and repetitive, whereas building new stuff is exciting.

· These issues manifest as ...

· senior developers start writing the infrastructure that other developers use, rather than using existing (often open source) software

· Problem then comes rather than migrating to using off the shelf solutions they stick with what they have built - result is later they’re locked in maintenance hell

· Architects aren’t immune to the “meta-work is more interesting than work” syndrome, which manifests in choosing inappropriate but buzz-worthy architectural styles like microservices.

· Tip - Don’t build an architecture just because it will be fun meta-work.

· Migration steps

· first tasks when untangling a code base is understanding how things are joined

· decomposing a monolith, the architect must take coupling and cohesion into account

· Tip - When restructuring architecture, consider all the affected dimensions.

· It is critical to understand why the migration is being done

· Finding correct service granularity is key

· Approaches to getting partitioning...

· Business functionality groups

· Transaction boundaries

· Deployment goals

· Evolving module interaction

· Problems -

· It maybe possible to make a module a library if the split is clean ...

· Modules can be split cleanly ...

· Module is replicated ...

· With breakdown achieved next step is service discovery

· Can achieve via simple proxy layer

· Determine discovery strategy early so as changes are applied aligning to discovery can be introduced

· All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections.Dave Wheeler and Kevlin Henney

· Be warned, keep an eye on partitioning, poor partitioning in granularity and suitable divisions can result in performance issues

· Can be mitigated by migrating in a progressive / pragmatic manner

· Look at ...

· Structural coupling

· Transaction boundaries

· It may make sense to go through iterations of structural breakdown

· When migrating from a monolith, build a small number of larger services first. Sam Newman, Building Microservices

· Guidelines for building evolutionary architectures

· Remove needless variability

· Software systems undergo constant change, as developers update capabilities, issue service packs, and generally tweak their software. Operating systems are a great example, as they endure constant change.

· dynamic equilibrium problem locally by replacing snowflakes with immutable infrastructure

· Snowflake computers are ones that have been manually crafted by an operations person, and all future maintenance is done by hand

· Chad Fowler coined the term immutable infrastructure in his blog post, “Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components”

· Immutable infastructure refers to systems defined entirely programmatically

· Immutable infrastructure follows our advice to remove needless variables

· Many teams extend the immutable infrastructure advice to the development environment as well. How many times has some team member exclaimed, “But it works on my machine!”? By ensuring every developer has the exact same image, a host of needless variables disappear.

· story in a popular blog called, “Knightmare: A DevOps Cautionary Tale” serves as a cautionary tale of snowflake servers. A financial services company previously had an algorithm called PowerPeg

· Make decisions reversible

· systems that aggressively evolve will fail in unanticipated ways

· When failures occur develop new fitness functions to avoid failures reoccurring

· Blue/green deployments are a illustration of reversible decisions

· Feature switches offer such an approach as well

· Prefer evolvable over predictable

· All architectures become iterative because of unknown unknowns; agile just recognizes this and does it sooner.Mark Richards

· Build anti corruption layers

· Tip - Build just-in-time anticorruption layers to insulate against library changes.

· abstraction distraction anti-pattern describes the scenario where a project “wires” itself too much to an external library

· The way a library or dependency works becomes enmeshed into the solution

· technical debt, but projects can inadvertently buy technical debt as well via premature complexity

· Tip: Build just-in-time anticorruption layers to insulate against library changes.

· architects can’t predict the future, we can at least lower the cost of change so that it doesn’t impact us so negatively

· Service templates

· Whilst operating as share nothing still need consistency to make operations managable

· Service templates - preconfigured components for service discovery etc

· Infra teams as orthogonal to service teams

· Tip Use service templates to couple just the appropriate parts of architecture together—the infrastructure elements that allow teams to benefit from coupling.

· Mitigate external change

· Transitive dependency management is our “considered harmful” moment.Chris Ford (no relation to Neal)

· When relying on code from a third party, developers must create their own safeguards against unexpected occurrences: breaking changes, unannounced removal, and so on

· remember external libraries provide both benefits and cost

· set up an internal version- control repository to act as a third-party component store, and treat changes from the outside world as pull requests to that repository

· Updating libraries vs frameworks

· Tip - Update framework dependencies aggressively; update libraries passively.

· frameworks are a fundamental part of applications, teams must be aggressive about pursuing updates

· Libraries form less brittle coupling points than frameworks do, allowing teams to be more casual about upgrades

· Prefer continuous delivery to snapshots

· Tip - Prefer Continuous Delivery over snapshots for (external) dependencies.

· Consider classifying dependencies as fluid or guarded and take dependencies updates accordingly

· Guarded dependencies are only taken when needed

· For fluid dependencies automatically adopt latest releases

· If a fluid update breaks things, then that dependency should become guarded

· Part of the history of having snapshots was the fact that that testing to confirm a snapshot is fit to release took time - that kind of testing should be behind us

· Version services internally

· Tip - When versioning services, prefer internal versioning to numbering; support only two versions at a time.

· Implement version numbering or tolerant readers inside the services

· Try to limit the number of supported versions

· Build sacrificial architectures

· The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. [...] Hence plan to throw one away; you will, anyhow.Fred Brooks

· Martin Fowler defines a sacrificial architecture as an architecture designed to be thrown away if the concept proves successful

· again by Fred Brooks, when he refers to the second system syndrome—the tendency of small, elegant, and successful systems to evolve into giant, feature-laden monstrosities due to inflated expectations.

· Evolutionary Architecture Pitfalls and Antipatterns

· Technical architecture

· Anti pattern : Vendor king

· Commitment to a large ERP can distort and lock-in IT

· Can be problematic when the vendor solution isn’t a good fit

· Pitfall leaky abstractions

· -trivial abstractions, to some degree, are leaky.Joel Spolsky

· Always fully understand at least one abstraction layer below the one you normally work in.Many software sages

· Tip Understand the fragile places within your complex technology stack and automate protections via fitness functions.

· Antipattern: last 10% trap

· COTs and 4GL languages can give you 80% of a solution quickly. Another 10% by scripting around the sides, but the last 10% can prove to be impossible

· Anitpattern: code reuse abuse

· Software reuse is more like an organ transplant than snapping together Lego blocks.John D. Cook

· Reuse can be difficult and sometimes we end up investing in trying to make things reusable that end up not being reused

· Tip: When coupling points impede evolution or other importance architectural characteristics, break the coupling by forking or duplication.

· Tip: Architects must continually evaluate the fitness of the “-ilities” of the architecture to ensure they still add value and haven’t become antipatterns.

· Pitfall: Resume Driven Development

· Avoid choosing tools, frameworks etc that are interesting for your CV rather than the problem at hand

· Tip: Don’t build architecture for the sake of architecture—you are trying to solve a problem.

· Incremental Change

· Antipattern: inappropriate governance

· Every company is now a software company.Forbes Magazine, Nov. 30, 2011

· What Forbes means in their famous quote is that if an airline company’s iPad application is terrible, it will eventually impact the company’s bottom line.

· Governance processes reflect underlying constraints - that can change overtime, therefore governance needs to take into account

· Pitfall: lack of speed to release

· Tip: Speed of evolution is a function of cycle time; faster cycle time allows faster evolution.

· Business Concerns

· Pitfall product customization

· Unique build for each customer

· Permanent feature toggles

· Product driven customization

· Antipattern : reporting

· Layers of abstraction put into place to provide good coupling but then reporting accesses dbs directly meaning schema change breaks reports

· Better to keep separation for reporting as well

· Pitfall: planning horizons

· Budgeting and planning processes often drive the need for assumptions and early decisions as the basis for those assumptions

· Larger the planning horizon, the earlier decisions get locked in

· Sunk Cost Fallacy describes decisions affected by emotional investment.

· Tip: Don’t become irrationally attached to handcrafted artifacts.

· Putting evolutionary architecture into practise

· Organisational factors

· Teams built around domains

· Cross functional teams

· Business analysts

· Architecture

· Testing

· Operations

· Data

· Organised around business capabilities

· Tip: Organize teams around business capabilities, not job functions.

· Product over project

· Project teams moving on is an issue for supporting and maintaining solutions as knowledge goes with the project team

· Drives separation of dev and ops and then creates us vs them

· shifting to product thinking brings ...

· Sustainability is longer than the life of a project

· Cross function teams stay with the solution

· Product ownership creates product advocacy

· Organisational commitment more likely

· Dealing with external change

· Consumer driven contracts

·

· Connections between team members

· companies have found anecdotally that large development teams don’t work well

· J. Richard Hackman Expert on team dynamics

· Formula for connections between people

·

· Keeping the number of links down reduces the friction and overheads involved

· hbr.org/2009/05/why-teams-dont-work

· Apa.org/science/about/psa/2004/06/hackman

· Team coupling characteristics

· Culture

· Tell me how you measure me, and I will tell you how I will behave.Dr. Eliyahu M. Goldratt (The Haystack Syndrome)

· 3 strikes and you refactor

· 1st time you just do it

· 2nd time, done but dislike duplication

· 3rd time you refactor

· Culture of experimentation

· The real measure of success is the number of experiments that can be crowded into 24 hours.Thomas Alva Edison

· Experimentstion can be driven in a no. Of ways

· Outside ideas

· Explicit improvement

· Spike and stablize

· Innovation time

· Set based development explore multiple options concurrently)

· Connecting engineers with end-users

· CFO and budgeting

· interesting relationship exists between architectural quanta and the cost of architecture. As the number of quanta rises, the cost per quantum goes down, until architects reach a sweet spot

·

· Enterprise fitness functions

· Where to start with fitness functions

· Low hanging fruit

· Highest value

· Testing

· Infrastructure

· Future state

· Fitness functions using AI

· Generative testing

· Architectural Coupling

· Whilst coupling is not desirable, it happens and maybe necessary

· Evolutionary architecture focuses on appropriate coupling

· Terminology

· Modularity

· Modularity describes a logical grouping of related code.

· Modules in turn may be packaged in different physical ways.

· Related to Logical grouping

· Components

· Components are the physical packaging of modules

· Relates to physical partitioning

· Components can be divided into ...

· Library

· Resides in the same memory addresss as calling code

· Compile time dependencies

· Service

· Tends to have own memory space

· Communicates over network protocols from TCP to SOAP and REST

· Have typically runtime dependencies

· Architectural quanta and granularity

· Business concepts can also bind a system together semantically

· Semantic binding can mean functional cohesion

· To successfully evolve software, developers must consider all the coupling points that could break.

· As defined in physics, the quantum is the minimum amount of any physical entity involved in an interaction

· architectural quantum is an independently deployable component with

· High functional cohesion

· Structural elements for the the system to function properly

· the quantum is the entire application

· Domain driven design - bounded context

· microservices architecture defines physical bounded contexts between architectural elements, encapsulating all the parts that might change

· In a microservices architecture, the bounded context serves as the quantum boundary and includes dependent components such as database servers.

· may also include architecture components such as search engines and reporting tools— anything that contributes to the delivered functionality of the service

·

· Traditionally isolated roles such as architect and operations must coordinate in an evolutionary architecture

· Architecture is abstract until operationalized

· developers must pay attention to how their components fit together

· Regardless of which architecture pattern developers choose, architects should also explicitly define their quantum size

· Small quanta implies faster change because of small scope

· Quantum size determines the lower bound of the incremental change possible within an architecture

·

· The atomic analogy works to characterise relationships of forces in an architecture

· The nuclear force holding atoms together is a strong force and hard to break

· But when broken releases a lot of energy

· Some components can be difficult to break into smaller element - ie strong nuclear force

· Evolutionary architecture addresses the quanta of of the system, with the strong nuclear force

· Evolvability of architectural styles

· Ease of change is one reason for patterns

· Patterns

· Big Ball of Mud


· Difficult

· Related code spread across code base

· Fixing one breakage can create more breaks

· Guided change with fitness functions

· Difficult as identifying clear partitions is difficult

· Determine what needs to protected

· Establish protective functions


· Represents inappropriate coupling

· Impact of change and likely cascade means low evolvability

· Changing access to data means locating all dependencies through entire code base

· Monoliths

· Unstructured Monoliths


· Change in one class can mean changes needed elsewhere

· Changes typically trigger large amounts to be deployed (quanta very high)


· As approach is mature - tooling to help

· Coupling presents the challenges


· Coupling can be unpredictable therefore risk of side effects when making changes

·

· Each class handles a specific task independently

· Common operations performed by shared classes

· Layered architecture


· Within a layer is straight forward

· Changing across layers can be challenges for coordination (particularly if the organisation reflects Conway’s Law)

· Presumes each layer has well defined interfaces


· Easier than an unstructured monolith

· Layers support the ability to do more isolated testing


· Ease of understanding

· Evolution within layers is possible

· Coupling within a layer can be high

·

· Modular Monoliths


· With strong modularity change scope is well contained

· Component size can still be large making change deployment harder

· Ease of deployment becomes the controlling factor for rate of potential change


· Tests, metrics etc easier to apply

· Modularity allows for mocking etc


· Presents good appropriate coupling

· Each component is cohesive

· Clear boundaries/interfaces

·

· Micro kernel


· Once core is done most change is in the plugins

· Typical to have a registry of plugins installed and contracts supported

· Works well as long of evolution is bounded to plugin development

· More isolated the plugins the easier the evolution


· Fitness functions relatively easy as they are isolated between plugins

· Separate fitness functions for the core compared to the plugins

· Core fitness functions need to guard against core change, risk to scalability and deployment issues

· Holistic fitness functions to ensure plugins don’t accidentally impact each other


· Well defined by microkernel

· Dependent plugins can be troublesome to coordinate

· Have fitness functions to ensure dependent components integrate properly

·

· Before embarking on an expensive architecture restructuring exercise, architects may benefit from improved modularization of what’s already present.

· microkernal architecture, commonly found in browsers and integrated development environments (IDEs)

· 2 quantum sizes for this approach..

· 1 is for the core

· Other for the plugins

· Common for the core to be monolithic

· Plugins well scoped and independently deployable

· Core may need to enable inter plugin communication

· Risk of plugin dependencies occuring

· Fitness functions for monoliths can be difficult

· If you can’t build a monolith, what makes you think microservices are the answer?Simon Brown

· Event Driven Architecture (EDA)

· Brokers


· Services designed to be loosely coupled

· Low coupling makes it easier to deploy changes

· Coupling makes it easier to apply non breaking change


· Atomic fitness functions easy because of the low coupling

· Holistic functions a lot harder for the same reason

· Use of correlation ids and open tracing will make it easier to do holistic measuring

· Consider synthetic transactions


· Low coupling makes it very easy

· Coupling can occur where contracts between different services occur

·

· Mediators


· Similar to the broker based approach


· Individual functions as easy as the broker model

· Holistic fitness functions easier because the coordination makes it more visible


· Testing becomes easier as coupling more apparent

· Risk of coupling becoming over complex, therefore testing complexity

· Because the routing rules are part of the business logic the architectural quantum has grown

·

· Hub mediates or coordinates processes

· Mediator moves the events from queue/topic to the next ensuring business process

· Can also manage transactional sequencing and rollback

· Mediator using messaging with processors ensures parallelism

· Processors rarely communicate directly with each other

· The trade off of end to end business process clarity vs coupling is something of an architectural trade off

· Systems linked together via messaging frameworks

· Highly evolvability as can just hook in new listeners

· But price is functional cohesion and transaction mgmt is more difficult

· SOA

· ESB Driven SOA


· Taxonomy can help with resources and reuse

· Organisational structures around ESB models can mean changes need a lot of inter team coordination


· Individual services can be difficult to get discrete tests established

· Tendency to rely on holistic testing


· Reusing existing services etc can be harder than in theory

·

· Common building blocks to EDA models

· Difference between EDA model and service bus is usually the strictly defined taxonomy

· Segregation typically driven by re-use

· Business services try to represent business processes in an abstract way

· abstract business services must call code to implement their behavior, which are enterprise services: concrete implementations meant for sharing

· understand why this often fails, see “Antipattern: Code Reuse Abuse”

· Does bring the benefit of protocol transformation

· Architectural quantum is big and can be as big as a monolith

· Microservices


· Use of bounded context to control scope

· Continuous delivery to control risk


· Can build hosticslly and indivudally


· Microservices architectures typically have two kinds ofcoupling: integration and service template.

· Integration coupling - services need to call each other to pass information

· Service template - prevents harmful duplication. Developers and operations benefit if a variety of facilities are consistent and managed within microservices

· physical bounded context in microservices correlates exactly to our concept of architectural quantum—it is a physically decoupled deployable component with high functional cohesion.

·

· Domain driven design

· Model around a set of principles ...

· Model aligns to business boundaries

· Hide implementation details

· Culture of automation

· Highly decentralized

· Deployed independently

· Isolate failure

· Highly observable

·

· Segmentation can result in a bounded context being spread around

· Key factors

· Continuous delivery

· Bounded context principles

· Service based architectures


· Whilst not got the agility of microservices, the principle benefits remain


· Can be harder because of e courser granularity particularly around the dB scope

· Increased code coupling likely


· Difficulties of coupling are often the driver to adopting this model so can be problemmatic

· Difference to pure microservice

· Large service granularity

· Larger granularity

· More like portion of a monolith

· Results the larger unit of change

· Ideallysame principles of a deployment pipeline

· Database scope

· Database segmentation can. Be v difficult

· Transactional dB not necessarily well united to microservices as overhead of managing coordination can be too costly

· Integration middleware

· Sometimes the coordination of services need to be or are externalised meaning an integration hub is necessary

· Using an integration hub is a classic architectural tradeoff

· Serverless


· Should be as simple as redeploying a function

· Good fit for deployment pipelines


· Fitness functions critical

· Need to ensure that the endpoints being stitched together aren’t changingetc


· Easy to evolve

· Lots of the workload has to be handled by the invoker as faas does minimal work

· Where is the transactional coordination performed

·

· Provides just enough code to hook services together

· Engineering Incremental Change

· An evolutionary architecture supports guided, incremental change across multiple dimensions.

· Jez Humble and Dave Farley released Continuous Delivery (2010), a collection of practices to enhance the engineering efficiency in software projects - these are seen as prerequisites

· DevOps practices include architectural monitoring—monitoring not only the services, but also the routes between services

· If a service isn’t used for a period of time then ops will remove the service

· Version services internally - the service handles differences in services rather than forcing clients to handle versioning. Aka non breaking change and tolerant reader

· Only retire old service when no one is using - collect call metrics to determine retirement

· Tip: Architecture is abstract until operationalized, when it becomes a living thing.

· JDepend is a metrics tool that analyzes the coupling characteristics of packages. Because JDepend is written in Java, it has an API that developers can leverage to build their own analysis via unit tests

·

· Need to support multiple servicesvabd

·

· Fitness function categories often intersect when implementing them in mechanisms like deployment pipelines. Here are some common mashups of fitness function categories

· atomic + triggered

· unit and functional tests run as part of software development

· fitness function is a unit test that verifies some aspect of the architectural integrity of the application architecture, such as circular dependencies or cyclomatic complexity.holistic + triggered

· holistic + triggered

· atomic + continual

· Verify REST services are fit by analysing their definition.

· holistic + continual

· outstanding example of a real-world continual holistic fitness function is Netflix’s Chaos Monkey

· GitHub use case

· Originally scripts around git but didn’t scale

· githubengineering.com/move-fast/

· Built tool called scientist github.com/github/scientist

· Determines whether to run new solution. This is run alongside the existing path - if discrepancies user given normal result

· Randomises order in which old and new are called to ensure no bugs being masked by order dependency

· Compares performance of both paths

· Data oublished

· Hypothesis and data driven development

· In the book Lean Enterprise (O’Reilly, 2014), Barry O’Reilly describes the modern process of hypothesis-driven development.

· rather than gathering formal requirements and spending time and resources building features into applications, teams should leverage the scientific method instead

· Once teams have created the minimal viable product version of an application (whether as a new product or by performing maintenance work on an existing application), they can build hypotheses during new feature ideation

· Experiments should run long enough to yield significant results

· Fitness Functions

· An evolutionary architecture supports guided, incremental change across multiple dimensions.

· An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s).

· Fitness functions can and are likely to conflict, performance vs security. It is understanding this that allows the trade offs to be made

· Different stakeholders will have different fitness priorities

·

· fitness functions for evolutionary architecture may not be implementable in software (e.g., a required manual process for regulatory reasons), but architects must still define manual fitness functions to help guide the evolution of the system

· However calculable measures are desirable when practical

· Calculable fitness means we can automate the assessment

· We can also think about the systemwide fitness function as a collection of fitness functions with each function corresponding to one or more dimensions of the architecture.

· systemwide fitness function is crucial for an architecture to be evolutionary, as we need some basis to allow architects to compare and evaluate architectural characteristics against one another

· A system is never the sum of its parts. It is the product of the interactions of its parts.Dr. Russel Ackoff

· Example fitness functions

· Performance - repeatably measurable

· Performance testing should be conducted early and frequently, in particular to pick up inflection points when performance changes radically

· Fitness functions can also be used to maintain coding standards. A common code metric is cyclomatic complexity

· An architect may set a threshold for an upper value, guarded by a unit test running in continuous integration, using one of the many tools to evaluate that metric

· Availability and measures for meantime to recovery can be difficult to automate - so maybe better manually evaluated

· Collecting important architecture thresholds and requirements as fitness functions allows for a more concrete representation for previously fuzzy, subjective evaluation criteria

· Fitness functions can be characterised as

· Functions may appear in more than 1 category

· Atomic v holistic

· Atomic fitness functions run against a singular context and exercise one particular aspect of the architecture

· Holistic fitness functions run against a shared context and exercise a combination of architectural aspects such as security and scalability

· Triggered v Continual

· Triggered fitness functions run based on a particular event, such as a developer executing a unit test, a deployment pipeline running unit tests, or a QA person performing exploratory testing

· Continual tests don’t run on a schedule, but instead execute constant verification of architectural aspect(s) such as transaction speed

· Monitoring-driven development (MDD) - monitor solutions for correct behaviour rather than simply static test

· Static v dynamic

· Static fitness functions have a fixed result, such as the binary pass/fail of a unit test

· Dynamic fitness functions rely on a shifting definition based on extra context e.g accepting reduced performance metrics when at high scale

· Automated v Manual

· Whilst ideally everything is automated e.g. fitness functions for metrics in the CI/CD pipeline

· critical dimension within a system, such as legal requirements, defies automation And can only be addressed manually

· Temporal

· The fitness function needs to be revalidated

· For example, if a project uses an encryption library, the architect may want to create a temporal fitness function as a reminder to check to see if important updates have beenperformed

· Intentional v Emergent

· Most fitness functions will be defined at the development outset

· However additional functions may be identified and arise during the development process

· Domain specific

· Domain driven considerations such as security or regulatory compliance

· Given an Architecture will be defined in a specific way because of domain factors, these should be captured as fitness functions

· Identify fitness functions early

· Risks of not doing so...

· Making the wrong design choices that ultimately lead to building software that fails in its environment

· Making design choices that cost time and/or money but are unnecessary

· Not being able to evolve the system easily in the future when the environment changes

· Understanding fitness functions and the architectures they may demand can help identify risks and challenges

· Allows risk management

· Mitigation of risk

· Early identification of fitness functions help architects plan for breaking a large system into smaller systems, each dealing with a smaller set of fitness functions.

· Allows organisation of teams and code to be aligned - therefore fitness responsibilities not spread around or diluted

· Functions can be classified into the following categories

· Key

· Critical to design and tech choices

· Invest in effort to find ways to make change easier in these elements

· Relevant

· Considered at the feature level

· Not likely to impact architectural choices

· E.g. code metrics - important but not key

· Not relevant

· Choices that may impact the speed or way to deliver for example

· Not material to the architecture

· Fitness functions not actually needed here

· Tip: Keep knowledge of key and relevant fitness functions alive by posting the results of executing fitness functions somewhere visible or in a shared space so that developers remember to consider them in day-to-day coding

· Review fitness functions

· Reviewing fitness functions should entail

· Reviewing existing functions

· Determine is functions still relevsnt

· Change of emphasis on the function

· Whether there is a better way to evaluate/measure a function

· Identify those emergent functions and determine if they need to be added

· Tip : Recommend review atleast once per year

· 1 Software Architecture

· Definition

· Ralph Johnson - “the important stuff (what ever that is)”

· Need to understand business or domain requirements

· Evolutionary Architecture

· Who is long term planning possible when everything changes?

· Introducing changes to a highly dynamic system can yield unpredictable results

· Software (eco)system can be considered to be made of...

· Tools

· Frameworks

· Libraries

· Best practices

· (Eco)systems form an equilibrium - within this development can be understood and built within

· After each change the equilibrium can be reestablished

· Disruptive change can be hard to predict, but some can be understood

· Design recognising there is inevitable change

· Don’t have fixed plans

· Used need long range plans as change was expensive

· We have techniques like devops, automation etc which allows us to lower the cost of change

· Some parts of a system can be difficult to change but risk of self fulfilling prophesy

· How to stop an Architecture from decaying?

· Aka bit rot

· By designing to support evolution the chance of bit rot declines

· E.g. designing for scale doesn’t mean a system is max scaled to start but can be made to scale

· Http://Martin Fowler.com/ieeeSoftware/whoNeedsArchitect.pdf

· Guided Change

· Protect characteristics needed by steering the changes

· Evolutionary computing concept of fitness functions

· Fitness function measures how well an algorithm meets a goal over time

· Repeated measures to determine if fit is improving or not

· Can evaluate using various metrics, test stats etc etc

· Multiple architectural dimensions

· To evolve need to consider multiple dimensions

· Common dimensions

· Technical

· Data

· Security

· Operational/system

· Other common views

· Https://en.wikipedia.org/wiki/4%2B1_architectural_view_model

· Https://www.viewpoints-and-perspectives.info/home/

· Http://codingthearchitecture.com

·

· Conway’s Law

· Http://www.melconway.com/research/committees.html

· “ _every time a delegation is made and somebody’s scope of inquiry is narrowed, the class of design alternatives which can be effectively pursued is also narrowed”

· Thoughteorks - inverse Conway’s Law manoeuvre

· build architectures such as microservices structure their teams around service boundaries

· Structure teams to look like your target architecture, and it will be easier to achieve it.

· evolutionary over adaptable because we are interested in architectures that undergo fundamental evolutionary change, not ones that have been patched and adapted into increasingly incomprehensible accidental complexity

evolutionary architectures - mp3muncher.files.wordpress.com · web viewtip: when coupling points...

Documents