Evolutionary architectures

? evolutionary architecturesEvolutionary DataPramod Sadalage, along with Scott Ambler, wrote Refactoring Databases, subtitled Evolutionary Database Design.Key to evolving dbs, particularly relational is the same ideas as codeTestedImpact to an ORMConsider fitness functionsVersionedImportant as dB and code are symbioticIncrementalAutomate the schema updatingChanges incorporated into a delivery pipelineIncorporation of undo changes to help move forward and backward through changesShard dB Integration DB often used to share dataHow avoid problems if 1 app wants to expand dB?Common solution is the expand/ contact pattern Age and quality of the dataTipsDatabase 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 ArchitecturesBring the different dimensions together ofFitness functionsIncremental changeAppropriate couplingMechanics of operationalising analysisGreenfieldsRetro fitting existing architecturesMigrating architecturesMany 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) softwareProblem 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 hellArchitects 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 stepsfirst tasks when untangling a code base is understanding how things are joineddecomposing a monolith, the architect must take coupling and cohesion into accountTip - When restructuring architecture, consider all the affected dimensions.It is critical to understand why the migration is being doneFinding correct service granularity is keyApproaches to getting partitioning...Business functionality groupsTransaction boundariesDeployment goalsEvolving module interactionProblems - 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 discoveryCan achieve via simple proxy layerDetermine discovery strategy early so as changes are applied aligning to discovery can be introducedAll 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 HenneyBe warned, keep an eye on partitioning, poor partitioning in granularity and suitable divisions can result in performance issuesCan be mitigated by migrating in a progressive / pragmatic mannerLook at ...Structural couplingTransaction boundariesIt may make sense to go through iterations of structural breakdownWhen migrating from a monolith, build a small number of larger services first. Sam Newman, Building MicroservicesGuidelines for building evolutionary architecturesRemove needless variabilitySoftware 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 infrastructureSnowflake computers are ones that have been manually crafted by an operations person, and all future maintenance is done by handChad 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 programmaticallyImmutable infrastructure follows our advice to remove needless variablesMany 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 PowerPegMake decisions reversiblesystems that aggressively evolve will fail in unanticipated waysWhen failures occur develop new fitness functions to avoid failures reoccurringBlue/green deployments are a illustration of reversible decisionsFeature switches offer such an approach as wellPrefer evolvable over predictableAll architectures become iterative because of unknown unknowns; agile just recognizes this and does it sooner.Mark RichardsBuild anti corruption layersTip - 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 libraryThe way a library or dependency works becomes enmeshed into the solutiontechnical debt, but projects can inadvertently buy technical debt as well via premature complexityTip: 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 negativelyService templatesWhilst operating as share nothing still need consistency to make operations managableService templates - preconfigured components for service discovery etcInfra teams as orthogonal to service teamsTip Use service templates to couple just the appropriate parts of architecture together—the infrastructure elements that allow teams to benefit from coupling.Mitigate external changeTransitive 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 onremember external libraries provide both benefits and costset 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 repositoryUpdating libraries vs frameworksTip - Update framework dependencies aggressively; update libraries passively.frameworks are a fundamental part of applications, teams must be aggressive about pursuing updatesLibraries form less brittle coupling points than frameworks do, allowing teams to be more casual about upgradesPrefer continuous delivery to snapshotsTip - Prefer Continuous Delivery over snapshots for (external) dependencies.Consider classifying dependencies as fluid or guarded and take dependencies updates accordinglyGuarded dependencies are only taken when neededFor fluid dependencies automatically adopt latest releasesIf a fluid update breaks things, then that dependency should become guardedPart 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 usVersion services internallyTip - When versioning services, prefer internal versioning to numbering; support only two versions at a time.Implement version numbering or tolerant readers inside the servicesTry to limit the number of supported versionsBuild sacrificial architecturesThe 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 BrooksMartin Fowler defines a sacrificial architecture as an architecture designed to be thrown away if the concept proves successfulagain 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 AntipatternsTechnical architectureAnti pattern : Vendor kingCommitment to a large ERP can distort and lock-in ITCan be problematic when the vendor solution isn’t a good fitPitfall leaky abstractions-trivial abstractions, to some degree, are leaky.Joel SpolskyAlways fully understand at least one abstraction layer below the one you normally work in.Many software sagesTip Understand the fragile places within your complex technology stack and automate protections via fitness functions.Antipattern: last 10% trapCOTs 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 impossibleAnitpattern: code reuse abuseSoftware reuse is more like an organ transplant than snapping together Lego blocks.John D. CookReuse can be difficult and sometimes we end up investing in trying to make things reusable that end up not being reusedTip: 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 DevelopmentAvoid choosing tools, frameworks etc that are interesting for your CV rather than the problem at handTip: Don’t build architecture for the sake of architecture—you are trying to solve a problem.Incremental ChangeAntipattern: inappropriate governanceEvery company is now a software company.Forbes Magazine, Nov. 30, 2011What 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 ernance processes reflect underlying constraints - that can change overtime, therefore governance needs to take into accountPitfall: lack of speed to releaseTip: Speed of evolution is a function of cycle time; faster cycle time allows faster evolution.Business ConcernsPitfall product customizationUnique build for each customerPermanent feature togglesProduct driven customizationAntipattern : reportingLayers of abstraction put into place to provide good coupling but then reporting accesses dbs directly meaning schema change breaks reportsBetter to keep separation for reporting as well Pitfall: planning horizonsBudgeting and planning processes often drive the need for assumptions and early decisions as the basis for those assumptionsLarger the planning horizon, the earlier decisions get locked inSunk Cost Fallacy describes decisions affected by emotional investment.Tip: Don’t become irrationally attached to handcrafted artifacts.Putting evolutionary architecture into practiseOrganisational factorsTeams built around domainsCross functional teamsBusiness analystsArchitectureTestingOperationsDataOrganised around business capabilitiesTip: Organize teams around business capabilities, not job functions.Product over projectProject teams moving on is an issue for supporting and maintaining solutions as knowledge goes with the project teamDrives separation of dev and ops and then creates us vs themshifting to product thinking brings ...Sustainability is longer than the life of a projectCross function teams stay with the solutionProduct ownership creates product advocacyOrganisational commitment more likelyDealing with external changeConsumer driven contracts Connections between team memberscompanies have found anecdotally that large development teams don’t work wellJ. Richard Hackman Expert on team dynamicsFormula for connections between people Keeping the number of links down reduces the friction and overheads 2009/05/science/about/psa/2004/06/hackmanTeam coupling characteristicsCultureTell 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 refactor1st time you just do it2nd time, done but dislike duplication3rd time you refactorCulture of experimentationThe real measure of success is the number of experiments that can be crowded into 24 hours.Thomas Alva EdisonExperimentstion can be driven in a no. Of waysOutside ideasExplicit improvementSpike and stablizeInnovation timeSet based development explore multiple options concurrently)Connecting engineers with end-usersCFO and budgetinginteresting 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 functionsWhere to start with fitness functionsLow hanging fruitHighest valueTestingInfrastructureFuture stateFitness functions using AIGenerative testingArchitectural CouplingWhilst coupling is not desirable, it happens and maybe necessaryEvolutionary architecture focuses on appropriate couplingTerminologyModularityModularity describes a logical grouping of related code.Modules in turn may be packaged in different physical ways.Related to Logical groupingComponentsComponents are the physical packaging of modulesRelates to physical partitioningComponents can be divided into ...LibraryResides in the same memory addresss as calling codeCompile time dependenciesServiceTends to have own memory spaceCommunicates over network protocols from TCP to SOAP and RESTHave typically runtime dependenciesArchitectural quanta and granularityBusiness concepts can also bind a system together semanticallySemantic binding can mean functional cohesionTo 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 interactionarchitectural quantum is an independently deployable component withHigh functional cohesionStructural elements for the the system to function properlythe quantum is the entire applicationDomain driven design - bounded contextmicroservices architecture defines physical bounded contexts between architectural elements, encapsulating all the parts that might changeIn 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 architectureArchitecture is abstract until operationalizeddevelopers must pay attention to how their components fit togetherRegardless of which architecture pattern developers choose, architects should also explicitly define their quantum sizeSmall quanta implies faster change because of small scopeQuantum size determines the lower bound of the incremental change possible within an architecture The atomic analogy works to characterise relationships of forces in an architectureThe nuclear force holding atoms together is a strong force and hard to breakBut when broken releases a lot of energySome components can be difficult to break into smaller element - ie strong nuclear forceEvolutionary architecture addresses the quanta of of the system, with the strong nuclear forceEvolvability of architectural stylesEase of change is one reason for patternsPatternsBig Ball of MudIncremental changeDifficultRelated code spread across code baseFixing one breakage can create more breaksGuided change with fitness functionsDifficult as identifying clear partitions is difficultDetermine what needs to protectedEstablish protective functionsAppropriate couplingRepresents inappropriate couplingImpact of change and likely cascade means low evolvabilityChanging access to data means locating all dependencies through entire code baseMonolithsUnstructured MonolithsIncremental changeChange in one class can mean changes needed elsewhereChanges typically trigger large amounts to be deployed (quanta very high)Guided change with fitness functionsAs approach is mature - tooling to helpCoupling presents the challengesAppropriate couplingCoupling can be unpredictable therefore risk of side effects when making changes Each class handles a specific task independentlyCommon operations performed by shared classesLayered architectureIncremental changeWithin a layer is straight forwardChanging across layers can be challenges for coordination (particularly if the organisation reflects Conway’s Law)Presumes each layer has well defined interfacesGuided change with fitness functionsEasier than an unstructured monolithLayers support the ability to do more isolated testingAppropriate couplingEase of understandingEvolution within layers is possibleCoupling within a layer can be high Modular MonolithsIncremental changeWith strong modularity change scope is well containedComponent size can still be large making change deployment harderEase of deployment becomes the controlling factor for rate of potential changeGuided change with fitness functionsTests, metrics etc easier to applyModularity allows for mocking etcAppropriate couplingPresents good appropriate couplingEach component is cohesiveClear boundaries/interfaces Micro kernelIncremental changeOnce core is done most change is in the pluginsTypical to have a registry of plugins installed and contracts supportedWorks well as long of evolution is bounded to plugin developmentMore isolated the plugins the easier the evolutionGuided change with fitness functionsFitness functions relatively easy as they are isolated between pluginsSeparate fitness functions for the core compared to the pluginsCore fitness functions need to guard against core change, risk to scalability and deployment issuesHolistic fitness functions to ensure plugins don’t accidentally impact each otherAppropriate couplingWell defined by microkernelDependent plugins can be troublesome to coordinateHave 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 coreOther for the pluginsCommon for the core to be monolithicPlugins well scoped and independently deployableCore may need to enable inter plugin communicationRisk of plugin dependencies occuringFitness functions for monoliths can be difficultIf you can’t build a monolith, what makes you think microservices are the answer?Simon BrownEvent Driven Architecture (EDA)BrokersIncremental changeServices designed to be loosely coupledLow coupling makes it easier to deploy changesCoupling makes it easier to apply non breaking changeGuided change with fitness functionsAtomic fitness functions easy because of the low couplingHolistic functions a lot harder for the same reasonUse of correlation ids and open tracing will make it easier to do holistic measuringConsider synthetic transactionsAppropriate couplingLow coupling makes it very easyCoupling can occur where contracts between different services occur MediatorsIncremental changeSimilar to the broker based approachGuided change with fitness functionsIndividual functions as easy as the broker modelHolistic fitness functions easier because the coordination makes it more visibleAppropriate couplingTesting becomes easier as coupling more apparentRisk of coupling becoming over complex, therefore testing complexityBecause the routing rules are part of the business logic the architectural quantum has grown Hub mediates or coordinates processesMediator moves the events from queue/topic to the next ensuring business processCan also manage transactional sequencing and rollbackMediator using messaging with processors ensures parallelismProcessors rarely communicate directly with each otherThe trade off of end to end business process clarity vs coupling is something of an architectural trade offSystems linked together via messaging frameworksHighly evolvability as can just hook in new listenersBut price is functional cohesion and transaction mgmt is more difficultSOAESB Driven SOAIncremental changeTaxonomy can help with resources and reuseOrganisational structures around ESB models can mean changes need a lot of inter team coordinationGuided change with fitness functionsIndividual services can be difficult to get discrete tests establishedTendency to rely on holistic testingAppropriate couplingReusing existing services etc can be harder than in theory Common building blocks to EDA modelsDifference between EDA model and service bus is usually the strictly defined taxonomySegregation typically driven by re-useBusiness services try to represent business processes in an abstract wayabstract business services must call code to implement their behavior, which are enterprise services: concrete implementations meant for sharingunderstand why this often fails, see “Antipattern: Code Reuse Abuse”Does bring the benefit of protocol transformationArchitectural quantum is big and can be as big as a monolithMicroservicesIncremental changeUse of bounded context to control scopeContinuous delivery to control riskGuided change with fitness functionsCan build hosticslly and indivudallyAppropriate couplingMicroservices architectures typically have two kinds ofcoupling: integration and service template.Integration coupling - services need to call each other to pass informationService template - prevents harmful duplication. Developers and operations benefit if a variety of facilities are consistent and managed within microservicesphysical 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 designModel around a set of principles ...Model aligns to business boundariesHide implementation detailsCulture of automationHighly decentralizedDeployed independentlyIsolate failureHighly observable Segmentation can result in a bounded context being spread aroundKey factorsContinuous deliveryBounded context principlesService based architecturesIncremental changeWhilst not got the agility of microservices, the principle benefits remainGuided change with fitness functionsCan be harder because of e courser granularity particularly around the dB scopeIncreased code coupling likelyAppropriate couplingDifficulties of coupling are often the driver to adopting this model so can be problemmaticDifference to pure microserviceLarge service granularityLarger granularityMore like portion of a monolithResults the larger unit of changeIdeallysame principles of a deployment pipelineDatabase scopeDatabase segmentation can. Be v difficultTransactional dB not necessarily well united to microservices as overhead of managing coordination can be too costlyIntegration middlewareSometimes the coordination of services need to be or are externalised meaning an integration hub is necessaryUsing an integration hub is a classic architectural tradeoffServerlessIncremental changeShould be as simple as redeploying a functionGood fit for deployment pipelinesGuided change with fitness functionsFitness functions criticalNeed to ensure that the endpoints being stitched together aren’t changingetcAppropriate couplingEasy to evolveLots of the workload has to be handled by the invoker as faas does minimal workWhere is the transactional coordination performed Provides just enough code to hook services togetherEngineering Incremental ChangeAn 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 prerequisitesDevOps practices include architectural monitoring—monitoring not only the services, but also the routes between servicesIf a service isn’t used for a period of time then ops will remove the serviceVersion services internally - the service handles differences in services rather than forcing clients to handle versioning. Aka non breaking change and tolerant readerOnly retire old service when no one is using - collect call metrics to determine retirementTip: 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 categoriesatomic + triggeredunit and functional tests run as part of software developmentfitness 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 + triggeredholistic + triggeredatomic + continualVerify REST services are fit by analysing their definition.holistic + continualoutstanding example of a real-world continual holistic fitness function is Netflix’s Chaos MonkeyGitHub use caseOriginally scripts around git but didn’t move-fast/Built tool called scientist github/scientistDetermines whether to run new solution. This is run alongside the existing path - if discrepancies user given normal resultRandomises order in which old and new are called to ensure no bugs being masked by order dependencyCompares performance of both pathsData oublishedHypothesis and data driven developmentIn 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 insteadOnce 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 ideationExperiments should run long enough to yield significant resultsFitness FunctionsAn 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 madeDifferent 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 systemHowever calculable measures are desirable when practicalCalculable fitness means we can automate the assessmentWe 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 anotherA system is never the sum of its parts. It is the product of the interactions of its parts.Dr. Russel AckoffExample fitness functionsPerformance - repeatably measurablePerformance testing should be conducted early and frequently, in particular to pick up inflection points when performance changes radicallyFitness functions can also be used to maintain coding standards. A common code metric is cyclomatic complexityAn 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 metricAvailability and measures for meantime to recovery can be difficult to automate - so maybe better manually evaluatedCollecting important architecture thresholds and requirements as fitness functions allows for a more concrete representation for previously fuzzy, subjective evaluation criteriaFitness functions can be characterised asFunctions may appear in more than 1 categoryAtomic v holisticAtomic fitness functions run against a singular context and exercise one particular aspect of the architectureHolistic fitness functions run against a shared context and exercise a combination of architectural aspects such as security and scalabilityTriggered v ContinualTriggered 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 testingContinual tests don’t run on a schedule, but instead execute constant verification of architectural aspect(s) such as transaction speedMonitoring-driven development (MDD) - monitor solutions for correct behaviour rather than simply static testStatic v dynamicStatic fitness functions have a fixed result, such as the binary pass/fail of a unit testDynamic fitness functions rely on a shifting definition based on extra context e.g accepting reduced performance metrics when at high scaleAutomated v ManualWhilst ideally everything is automated e.g. fitness functions for metrics in the CI/CD pipelinecritical dimension within a system, such as legal requirements, defies automation And can only be addressed manuallyTemporalThe fitness function needs to be revalidatedFor 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 beenperformedIntentional v EmergentMost fitness functions will be defined at the development outsetHowever additional functions may be identified and arise during the development processDomain specificDomain driven considerations such as security or regulatory complianceGiven an Architecture will be defined in a specific way because of domain factors, these should be captured as fitness functionsIdentify fitness functions earlyRisks of not doing so...Making the wrong design choices that ultimately lead to building software that fails in its environmentMaking design choices that cost time and/or money but are unnecessaryNot being able to evolve the system easily in the future when the environment changesUnderstanding fitness functions and the architectures they may demand can help identify risks and challengesAllows risk managementMitigation of riskEarly 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 dilutedFunctions can be classified into the following categoriesKeyCritical to design and tech choicesInvest in effort to find ways to make change easier in these elementsRelevantConsidered at the feature levelNot likely to impact architectural choicesE.g. code metrics - important but not keyNot relevantChoices that may impact the speed or way to deliver for exampleNot material to the architectureFitness functions not actually needed hereTip: 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 codingReview fitness functionsReviewing fitness functions should entailReviewing existing functionsDetermine is functions still relevsntChange of emphasis on the functionWhether there is a better way to evaluate/measure a functionIdentify those emergent functions and determine if they need to be addedTip : Recommend review atleast once per year1 Software ArchitectureDefinitionRalph Johnson - “the important stuff (what ever that is)”Need to understand business or domain requirementsEvolutionary ArchitectureWho is long term planning possible when everything changes?Introducing changes to a highly dynamic system can yield unpredictable resultsSoftware (eco)system can be considered to be made of...ToolsFrameworksLibrariesBest practices(Eco)systems form an equilibrium - within this development can be understood and built withinAfter each change the equilibrium can be reestablishedDisruptive change can be hard to predict, but some can be understoodDesign recognising there is inevitable changeDon’t have fixed plansUsed need long range plans as change was expensiveWe have techniques like devops, automation etc which allows us to lower the cost of changeSome parts of a system can be difficult to change but risk of self fulfilling prophesyHow to stop an Architecture from decaying?Aka bit rotBy designing to support evolution the chance of bit rot declinesE.g. designing for scale doesn’t mean a system is max scaled to start but can be made to scale ieeeSoftware/whoNeedsArchitect.pdfGuided ChangeProtect characteristics needed by steering the changesEvolutionary computing concept of fitness functionsFitness function measures how well an algorithm meets a goal over timeRepeated measures to determine if fit is improving or notCan evaluate using various metrics, test stats etc etcMultiple architectural dimensionsTo evolve need to consider multiple dimensionsCommon dimensionsTechnicalDataSecurityOperational/systemOther common views Conway’s Law“ _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 manoeuvrebuild architectures such as microservices structure their teams around service boundariesStructure 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 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download