systematischer entwurf von software-architekturen · 2017-02-15 · systematic architecture design...

Systematischer ArchitekturentwurfVortrag Di 2.1, OOP 2017

1/27/2017

© Prof. Dr. Michael Stal 1

SYSTEMATISCHER ENTWURF VONSOFTWARE-ARCHITEKTURENReferent: Prof. Dr. Michael StalVortrag Di2.1 auf der OOP 2017Präsentation: DeutschPräsentationsmaterial: Englisch

FAILURES CAUSE LOSSES

Software EngineeringAccidents cause huge

Economic Losses every year

How can we avoidthese costs?


1/27/2017


Learning objectives

Become familiar with a BestPractice Framework fordesigning and implementinglarge and complex Software-intensive Systems

Learn how to apply theframework in large andcomplex projects

GOALS

© bikejames.com

If you think good architecture isexpensive, try bad architecture

Joseph Yoder, Brian Foote

OUR CHALLENGE

Ways to createGood

Architecture

Ways to createBad

Architecture


1/27/2017


SURROUNDED BY FORCES

External and Internal Forces(Push)

External and Internal Forces(Pull)

FROM YESTERDAY’S FAILURESTO TOMORROW’S BEST PRACTICES

Architects needSystematic Architecture Designinstead of Ad-hoc DesignBest Practices that guide theiractivities in the whole lifecycle

A framework of best practices givesguidance how to

create stable architectural designassess and improve architecturerealize architecturemaintain and evolve architecture

Activities & BestPractices

Skills, Competences,Experiences

ArchitectsBestPracticeFramework


1/27/2017


ARCHITECTINGARCHITECTING

Source: wikipedia

SYSTEMATIC ARCHITECTUREDESIGN PROCESS


1/27/2017


WHERE WE ARE:

Scopes &Boundaries

ArchitectingProcess

ArchitectureBaseline

Qualities

Commonality/Variability

SystematicRe-use

ArchitectureEnforcement

TWIN PEAKS (PROBLEM)

If requirements are fuzzy,architecture design can’t bestableIf customers or product owners donot know what they need, goodarchitecture is impossible=> Requirements Engineering andArchitecting can’t happensequentiallyWhat is the alternative?

Architecting and EngineeringArchitecting and EngineeringRequirements in parallel offers manyRequirements in parallel offers manybenefitsbenefitsSource: Twin Peaks SheriffSource: Twin Peaks SheriffDepartmentDepartment


1/27/2017


TWIN PEAKS (SOLUTION)In high uncertainty* pure sequentialprocesses do not work, because

Requirements engineers do notknow if their specification is feasibleArchitects do not know whetherthey can meet the specification

Twin Peaks is an explorative approach:Requirements engineering,competence ramp-up, andarchitecting happen in parallel andwith tight interactionFeasibility prototypes to clarify anddiscuss open issues early

Twin Peaks helps mitigate risks andreduce waste

* such as unknown domain,such as unknown domain,insufficient technologyinsufficient technologyknowledge, unavailability ofknowledge, unavailability ofa reference architecturea reference architecture

Change of Perspective isessential

UNDEFINED SCOPE ANDBOUNDARIES (PROBLEM)

Without clear scoping and definition ofboundariesit is undefined what a product shouldinclude or exclude, e.g.,

Which functionality should beimplemented in product/solution ?What is provided externally ?How do both parts interact ?What is the domain and what arethe subdomains ?What is common and what isvariable ?

as a consequence, architects cannotfocus on essence

In real life we are also facingIn real life we are also facing(lack of) boundaries(lack of) boundaries


1/27/2017


COMMON SCOPING PITFALLSPitfalls of Scoping

Wrong scope: system does notprovide expected valueToo broad scope: development endsup with extra functionality no oneneeds => more value and morecomplexity than neededToo small scope: system does onlyprovide a subset of requiredfunctionality => less value thanneeded

DEFINED SCOPE AND BOUNDARIES(SOLUTION)

Define clear scope: what is internal andwhat is external (incl. interfaces, actors)Tools for Scoping:

Use case diagrams, Business Drivers,KANO, SWOT-Analysis, C/V Analysis,Domain-Driven Design, FeatureModeling, Model-drivenDevelopment, Context Diagrams,Architecture Styles & Patterns

Leverage a problem domain languageto express scope & boundariesDerive interfaces, formats, andprotocols used at the boundaries System

Administrator

Operator

SAP

Archive

CRM

SAP

UseUse CasesCasesshow theshow thescope of thescope of thesystem insystem interms ofterms offunctionalityfunctionality

ContextContextDiagramsDiagramsdepict itsdepict itsboundaryboundary


1/27/2017


DOMAIN MODELS – ARCHITECTUREDESIGN PERSPECTIVE

The term domain model is overloadedIn software architecture design a domainmodel is a conceptual and idiomaticmodel that incorporates Components,Behavior & Interaction, DataIt is more than a glossary as it comprisesdependencies of concepts as well

Problem domain models capture the core entities ofthe problem domainDomain Driven Design structures domains insubdomainsUML class diagrams are not always the best option todefine a domain modelDSLs help formalize mature or simple (sub)domains

DEFINING A (PROBLEM) DOMAINMODELInput:

Use Cases, User StoriesOutput:

Domain Objects such as WarehouseTopology, Order ManagementStatic and Dynamic Relationsbetween Domain Objects such as calldependencies (ExecuteTransportation Order) andclassifications (Key Customer,Customer)Information passed or maintainedsuch as Purchase Order

A Domain Model needs buy-in ofStakeholders

Customer pays items in Shopping Cart


1/27/2017


WHERE WE ARE:

Scopes &Boundaries

ArchitectingProcess


Qualities


SystematicRe-use


PREREQUISITES FOR SYSTEMATICARCHITECTING

Understanding of Problem DomainHigh Quality Requirementspecification

at least 30% of all requirementsalmost all high priority requirements

Knowledge of Business Drivers,Goals, Strategy,Knowledge of Constraints & RisksRisk mitigation in PlaceAgile/Lean Process ModelTechnology & Tool Competence inSolution DomainAdequate Staffing


1/27/2017


DERIVING ARCHITECTURALLY-SIGNIFICANT REQUIREMENTS

Specification of Architecturally-Significant Requirements

Functional RequirementsConstraints & Infrastructures

Distribution, Multicore, Real-time, …

Quality AttributesOperational Qualities:user experience such asperformance, security,reliability, …Developmental Qualities:developer experience suchas maintainability,modifiability, …

Ab

straction

Layers

>2

MostlyStrategic

Abstraction

Layers0

-2A

bstractionLayers

>2

SYSTEMATIC ARCHITECTURAL DESIGNFROM 30.000 FEET

Get (subset of) requirements,

Constraints

Get (subset of) requirements,Business Goals and

Constraints

Analyze and give feedbackuntil high quality achieved

Prioritize and derivePrioritize and derivearchitecture-significant

requirements

Functional design

Quality attribute driven

Developmental

Quality attribute drivendesign: Operational and

Developmental

Evolution of ArchitectureBaseline

Quality Check byReviews and Tests

Repair and Improvement

Beta Test (optional)

Executable Walking Skeleton

Driver: Even inagile and leanprocesses weneed some frontloading withrespect toarchitecturedesign


1/27/2017


ARCHITECTURE BASELININGThe Architecture Baseline

Captures the essence of a systemand represents the initial walkingskeletonContains a subset of the wholearchitecture and is derived fromthe architecturally mostsignificant driversIs restricted regarding its numberof abstraction layersMust be sufficiently stable andflexible to guide furtherrefinement and evolutionNote: it might be a challenge tobalance stability and flexibilityMind contradicting definitions of“architecting baseline” inliterature

Architecture baseline is the prerequisite for refinement andArchitecture baseline is the prerequisite for refinement andevolutionevolution

Source:Source: wikipediawikipedia

WALKING SKELETON METAPHORSkeleton initially representsarchitecture baselineand is extended slice by slice withfunctionalities or qualities:

User Scenario, e.g.,adding all muscles, nerves, …,needed to move a fingerQuality Attribute Scenario,e.g., response time of fingermovementAfter integration of new slicesRegression-Testing required

which is known as piecemeal growth


1/27/2017


ARCHITECTURE DESIGN ISSYSTEMIC DESIGN (I)

Strategic DesignDesign of Entities withGlobal Impactlimited to HigherAbstraction Layers

Tactical DesignRefinement of StrategicDesignconstrained to Entitieswith Local Impact

Architecting = SystemicDesign = StrategicDesign + Selection ofGlobal Infrastructuresfor Tactical Design

ARCHITECTURE DESIGN ISSYSTEMIC DESIGN (II)

Strategic DesignConsideration ofimportant requirementswith systemic effect butonly up to a maximumabstraction levelInfrastructure for TacticalDesign - Intersection ofTactical and StrategicDesign

Tactical designEverything else

Strategic Design

Tactical Design

Infrastructure forTactical Design

LevelofAb

straction

System design is a sequence of design decisions. Architecture comprises all decisions withsystemic impact =>• Strategic Design is architectural design• Tactical infrastructures with systemic impact are architectural design as well


1/27/2017


LIMITING ABSTRACTION DEPTHLimit Abstraction DepthRule of Thumb: usearound 3 or 4 levels

SystemSubsystemsComponents

Semantics of terms likeSubsystem or Componentneed to be defined bydevelopmentorganization!

System

Subsystems

Components

PRECEDENCE RULESQualities shouldn’t be injected accidentally. Their concreteintegration is driven by priorities:

Functional design before Quality AttributesOperational Quality before Developmental QualityE.g., Extensibility precondition: we must know what to extendStrategic Design before Tactical DesignHigh Priority Requirements before Low Priority Requirements

Scenario-based Functional Design

Scenario-based Operational Quality Attributes

Scenario-based Developmental Quality Attributes


1/27/2017


THE STRATEGIC DESIGN TRIANGLE(SOLUTION)Three main ingredients of strategic design

User scenariosQuality-Attribute ScenariosCore Infrastructures for Distribution, Concurrency

Core InfrastructuresInfrastructural requirements of functional core aremapped to Core InfrastructuresQuality attributes cause integration of additionalInfrastructuresCore needs to consider hardware constraints andis addressed before quality attributesLow Level Layer of wrapper façades to ensuretechnology independence

FunctionalFunctionalArchitectureArchitecture

CoreCoreInfrastructuresInfrastructures

Quality AttributeQuality AttributeInfrastructuresInfrastructures

POSTPONING DECISIONS(PROBLEM)

Software development is subject tofrequent changes and uncertaintySoftware architects may postponedecisions as they don’t want to beresponsible for

wrong decisionsrisks introduced by uncertainty

But: If decisions are not made, theproject will be delayed


1/27/2017


GOOD DECISION MAKING(SOLUTION)Software architects need courage to make

decisions. Theyare aware of risks and their mitigationcan explain the rationale of their decisionsare open to obtain and give feedbackdo not try to make everyone happyintegrate management in decision makingtrace all consequences of such decisions(requirements traceability, architecturetracking!)rollback early from wrong decisions

Wrong decisions can be more beneficial than lackof decisions

WRITE-ONLY DOCUMENTS(PROBLEM)Documenting appears to be a

nasty duty mostly doneduring idle phases or afterproject completionwithout consideration of thetarget audience

Documentation No-GOs:Outdated or wrong informationExplanation of What but not of WhyLack of important information orinclusion of unimportant factsLack of coordinating main author


1/27/2017


READ/WRITE DOCUMENTS(SOLUTION)Documents are core assets

subject to versioning, changemanagement, and reviewscontain the What, Why and How

with …one responsible main authorclear and comprehensive vertical andhorizontal structureConsidering the needs of the target audiencefocus on readability and understandabilitygood habitability of information provided(KiSS)regular but not too frequent updates (e.g.,after each increment)usage of domain language(s)balance between repetition and references

Good Content– Enlightenment guaranteed

MEMENTO (PROBLEM)• Symptom: decelerationof project progress byrepeating discussion ofalready clarified issues

• After a few weekscolleagues won’tremember the outcomeand restart discussions

• You feel captured in atime loop whichdecreases productivitywithout yourself evennoticing it


1/27/2017


PROJECT DIARY (SOLUTION)Introduce a project diary* for everything importantand not documented elsewhere

Decisions and their rationaleDiscussions and their resultsMinutes

Helps remember decisions and discussionsWith a diary you can

prevent unproductive and repeatingdiscussionsunderstand the whole project much bettertrack project history and decisions Source:Source: Basebuilders.comBasebuilders.com

* You may use a Wiki for this purpose

Sometimes, specifications are thrown overthe fence from one role to the other(s)such as:

Requirement specification to architectsArchitecture specification to developers

The message to recipients isI do not care, anymore. Now, it is yourproblem! (see S.E.P.)You may have questions, but I am notavailableThe document is so comprehensive that onlymorons are not capable of understanding itsbrilliance

OVER THE FENCE (PROBLEM)

SourceSource:: businessinsider.combusinessinsider.com


1/27/2017


SYSTEMATIC HAND-OVER(SOLUTION)Authors of a document are responsible for its

usabilityThey share responsibility for all consequencesthat result from the documentDocuments are never thrown over the fencebut introduced, motivated, explained, andhanded over to recipientsAuthors need to be available in thesucceeding phases to

answer questions of recipientsobtain feedback and use it to improvetheir document But communicate in anBut communicate in an

efficient, effective andefficient, effective andmotivatingmotivating wayway

DEVELOPERS WITHOUT GUIDANCE(PROBLEM)Without documented

mandatory guidelines, rules,coding conventions …,

code bases erode overtime, since each developeruses her owninterpretations, styles andidioms

Other extreme: ambiguous,contradicting GuidelinesDissatisfaction guaranteed

However, guidelines should makeHowever, guidelines should makesensesense

SourceSom

ervillePublic

Library


1/27/2017


GUIDANCE FOR DEVELOPERS(SOLUTION)

Strengthen implementation quality,understandability & developer acceptancewith a set of policies that

are mandatoryare enforcedare not contradictingmake sensehelp avoid architecture and code issuesaddress all stakeholders and technologiesdo not omit important aspectsare acceptable for “code users”,…are documentedare easy to understand and remember

Source: J. John (BritishSource: J. John (Britishpastor)pastor)

WHERE WE ARE:

Scopes &Boundaries

ArchitectingProcess


Qualities


SystematicRe-use



1/27/2017


XYZExternal

Components

BusinessObjects

Hardware Interface

GlobalCoordination Core System

Plug-In A<<<<<<

Plug-In B<

ABC CoreSys-temPlug-In <D<<<<<<<<

Plug-In <<<<C DEF CoreSys-tem Plug-In F

Plug In-E XYZ CoreSys-tem Plug-In H

Plug-In G

Hum

an-M

achi

neIn

terfa

ceAnalyze this real worldexampleExcept for the names itcontains the originalarchitecture baselinedesignWould you be able to builda system using this“architecture”?If not, why not?

In terms of habitability, the real world exampleabove, is not very different from the mapbelow

In terms of habitability, the real world exampleabove, is not very different from the mapbelow

WAR STORY – LACK OF BASELINE

CREATE AN ARCHITECTUREBASELINEAccording to agile methodology

assets are built iteratively andincrementallyArchitecture is a core asset itselfand the backbone of the systemConsequence: We must designan architecture baseline forbuilding and evolving systemsConsider the Baseline as thebones of the walking skeleton

Building in Montreal, QuebecBuilding in Montreal, QuebecSource:Source: wikipediawikipedia


1/27/2017


PIECEMEAL GROWTHIncremental design with intermediateresults that are executable applicationswith product quality systems (walkingskeleton)is our safety net

In each iteration the number ofslices, breadth, stability growFor systematic design high riskrespectively priority is addressed first

Sour

ce:b

rillia

nce

Sour

ce:b

rillia

nce

inc.

inc.

INGREDIENTS FOR A BASELINEFundamental Structure, i.e., core, mainresponsibilities, relationships interfaces andcollaborationsInfrastructures for distribution, concurrency,…Approach for addressing external quality,i.e., mission critical strategic qualityattributesGuiding principles and Directives forarchitecture designTraceability between architecturallyrelevant requirements and architecturedecisions

Hardware systems haveHardware systems havebaselines as wellbaselines as well

IBM architecture baseline forIBM architecture baseline forevent processingevent processing


1/27/2017


SEPARATION OF CONCERNSStrictly separate

Business functionality,Infrastructurefunctionality,Support andmanagementfunctionality.

Otherwise,maintainability will bereduced Separation of concerns is the precondition forSeparation of concerns is the precondition for

reducing complexity and increasingreducing complexity and increasingunderstandability & modifiability.understandability & modifiability.

STRATEGIC DESIGN

Strategic design helps focus onessence=> fundamental approach forbaseline architecture creationAddresses commonality plusarchitectural infrastructure forvariability

Without strategic design thinking youWithout strategic design thinking youdo not have a safety netdo not have a safety net


1/27/2017


WHERE WE ARE:

Scopes &Boundaries

ArchitectingProcess


Qualities


SystematicRe-use


CLASSIFICATION OF QUALITIES

Quality

InternalQuality

ExternalQuality

OperationalQuality Attributes

DevelopmentalQuality Attributes

Dependency CyclesCyclomatic ComplexityCohesionCouplingFan In/Out ....

PerformanceSecuritySafetyAvailability…

MaintainabilityFlexibilityTestabilityExtensibilityInteroperability…

Internal: implicit properties thatlead to low expressiveness, …External: explicit propertiesobservable by users of product orcodeOperational: behavior that isexternally observable (end userusability)Developmental: usability ofdesign and code base (i.e.,habitability)Quality Attributes: we do notuse the term “nonfunctionalrequirements”(requirements thatdo not work) but ”quality(attributes)”


1/27/2017


External Black Box View, e.g.,Behavior

Internal White Box View, e.g., Symmetry

External Qualityaddresses qualitiesrelated to thebehavior of thesystemInternal Qualityaddresses qualitiesrelated to thestructure of thesystem

INTERNAL AND EXTERNAL QUALITY

LACK OF EXTERNAL QUALITY CANCAUSE DISASTERS

RadiationRadiation TherapyTherapy SystemSystemTheracTherac--25: lack25: lack ofof qualityqualityandand softwaresoftware failurefailurecausedcaused 33 deathsdeaths

„Even God himselfEven God himselfcould not sink this shipcould not sink this ship“ Challenger Disaster causedChallenger Disaster caused

byby unsafeunsafe rocket booster designrocket booster design

Ariane 5 explosionAriane 5 explosiondue to overflowdue to overflowexceptionexception

TacomaTacoma NarrowsNarrows BridgeBridge(1940)(1940) collapsedcollapsed duedue totoneglectingneglecting resonanceresonanceforcesforces


1/27/2017


HANDLING QUALITY ATTRIBUTES

Performance

ResourceDemand

ResourceManagement

ResourceArbitration

Events Arrive

ResponsegeneratedwithinTimeConstraints

GOAL

Performance

IncreaseComputationEfficiencyReduceComputationalOverheadManage Event RateControl Frequencyof Samples

IntroduceConcurrencyMaintainMultiple Copies ofData/ServicesIncreaseAvailable Resources

Scheduling Policy

SOURCEDriver

STIMULUS:Moves SteeringWheel

ARTIFACT:car steering controlsubsystem

ENVIRONMENT:Normal mode

RESPONSE:Turn to specified direction

RESPONSEMEASURE:mustexecute in<= 100 nsec

SOURCEDriver

STIMULUS:Moves SteeringWheel

ARTIFACT:car steering controlsubsystem

ENVIRONMENT:Normal mode

RESPONSE:Turn to specified direction

RESPONSEMEASURE:mustexecute in<= 100 nsec

(1) Define quality attribute scenarios

(2) Aggregate and prioritize quality attributescenarios

(3) Apply design tactics for quality attributescenarios

Implementation

(4) ImplementTrace back

TRADEOFF AND SENSITIVITY POINTSTwo aspects need consideration:

A point in the architecture that affects aparticular quality attribute is a SensitivityPointA point in the architecture that is asensitivity point for more than one qualityattribute is a Tradeoff Point

Tradeoff Points cause risks. They …must be handled with caremay be sensitivity points for“contradicting” quality attributes thatnegatively affect each other, e.g.:performance & modifiability

Mind Tradeoff andSensitivity Points

Name: Tradeoff by SurpriseContext: Highly Scalable System for PrepaidPhone ticketingProblem: A strict Layers Architecture wasintroduced to allow the flexibility of modifyingsystem parts. Nonetheless, every time thedatabase scheme in the lowest layer changed,the client apps in the highest layer crashedConsequences: It turned out that client appdevelopers did ignore the layered system andused direct access to the low level layers

Name: Tradeoff by SurpriseContext: Highly Scalable System for PrepaidPhone ticketingProblem: A strict Layers Architecture wasintroduced to allow the flexibility of modifyingsystem parts. Nonetheless, every time thedatabase scheme in the lowest layer changed,the client apps in the highest layer crashedConsequences: It turned out that client appdevelopers did ignore the layered system andused direct access to the low level layers


1/27/2017


QUALITY ATTRIBUTE CONSTRAINTS

Quality attributes can’tbe combined in arbitrarywaysExample: According tothe CAP theorem youcan only have 2 of 3:

C onsistencyA vailabilityP artition Tolerance

Consistency: you always see the correctinformation but it may take some timeAvailability: you always get informationwhich may not be currentPartition Tolerance: the system is able tocope with partial failure

CONSISTENCYCONSISTENCY

AVAILABILITYAVAILABILITY

PARTITIONTOLERANCEPARTITIONTOLERANCE

NA

C+A

C+P

A+P

AD-HOC INTEGRATION OF COREINFRASTRUCTURES (PROBLEM)

Wrong AssumptionFor infrastructures such as concurrency a one-size-fits-all approach will doUsage of infrastructure is independent of problemcontextHowever, that does not work:Infrastructures support support different usagepatternsArchitectures are tightly coupled withinfrastructures

Implication: It depends on problem andscenarios which infrastructure to prefer and howto use and deploy it

Multi Threading must beMulti Threading must beapplied appropriately.applied appropriately.Otherwise a Big Ball of ThreadsOtherwise a Big Ball of Threadsis lurking in the designis lurking in the design


1/27/2017


SYSTEMATIC INTEGRATION OF COREINFRASTRUCTURES (SOLUTION)

Infrastructure use depends on problemat hand, e.g.,

In image processing a ConcurrentPipes & Filters architecture is usefulFor control systems Half Sync / HalfAsync is the better choiceFor automation/robotics aConcurrent Reactor model mightbe the way to go

Analyze the problem, check systemswith similar characteristics, and thenconsider which architecturerespectively infrastructure to use andhow

BUTTERFLY EFFECT (PROBLEM)The more tradeoff points in anarchitecture, the more risksWhy? One small change maycause multiple unwanted effectsin various placesThis holds for all architecturalhotspots (design centers)In Product Line Engineering andEcosystems risks/debt havemultiple impact

An issue in one of the coreassets affects all applications

We must keep this under control

Source:Source: wikimedia.orgwikimedia.org


1/27/2017


REDUCING RISKS OF BUTTERFLYEFFECTS (SOLUTION)Ensure Traceability and use

Architecture TrackingOnly create tradeoff pointswhere inevitableMake tradeoff points

explicita responsibility of the wholedevelopment team

Treat them as risks: identify,assess, mitigate, monitor themUse feasibility prototypes toavoid Butterfly Effects

A small cause can have largeA small cause can have largeeffects if architecture & design areeffects if architecture & design arebrittlebrittle

WHERE WE ARE:

Scopes &Boundaries

ArchitectingProcess


Qualities


SystematicRe-use



1/27/2017


OPEN DOOR (PROBLEM)Pitfalls when dealing withCommonality & Variability:

addressing both at onceopening the architecture forvariability w/o closing backdoorsemphasizing variability instead ofcommonalityusing undocumented interfaces –it is like breaking into a house

Whenever there is a locked door,Whenever there is a locked door,someone will try to get insomeone will try to get in

OPEN/CLOSE(D) (SOLUTION)Commonality addressedfirst => Invariant partsbecome design centersVariability pointsintroduced by openingthe architectureProtect other systemparts from unwantedaccess

Design Core(Commonality)

Protection


Protection

Step 1: DesignCommonality

Step 2: Open forVariability


Protection Step 3: Only openvariability pointbut close rest(sandbox)


1/27/2017


VARIABILITY MANAGEMENT(SOLUTION)Variability has a business interface covered by

Domain modeling: defining domains,subdomains, scope, contexts => Product LineCommonality and VariabilityDomain potential analysis: future changes infeatures, technology => future variation pointsCommunality/Variability model: e.g., a Featuremodel => current Variation pointsNote: these artifacts are not static but evolveover time due to product & technologychangesArchitects define explicit variation pointsaccording to variability requirements

VariabilityVariabilityManagement is aManagement is aconcern of allconcern of alldisciplinesdisciplinesSourceSource uniuni--ulm.deulm.de

VARIABILITY IN SPACE/TIMEVariability ismultidimensional:

Variability in Space(current variationpoints)Variability in Time(future variationpoints)

Do only considerknown andexpected variability!

Source: wikipedia.orgSpacetime


1/27/2017


HANDLING VARIABILITY AS AN AD-HOC ACTIVITY (PROBLEM)

Considerations:Variability must be defined,planned, designed andimplementedBinding Time, VariabilityArchitecture & Design are notmere technical aspectsArchitects & Developers are incharge of managing VariabilityVariation points should alwaysbe explicit

Source: nasa.govMany forces have an impact onMany forces have an impact on

variability which also holds for nonvariability which also holds for nonsoftware systemssoftware systems

VARIABILITY – WHO BINDS THEVARIATION POINT

ArchitectsDevelopers & DevOpsAdministratorsUsersTechnical Service StaffIntegratorAnother SystemSystem itself


1/27/2017


ADDITIONAL DIMENSIONS OFVARIABILITY

Kind of VariationExtensionReplacementRemovalReconfiguration

Granularity of VariationSubsystemLayerComponentClassServiceAlgorithmDriverLibrary

Implementation of VariationStructure: e.g., topologyBehavior: e.g., AlgorithmControl Flow: e.g., Rules, WorkflowsEnvironment: Operating System,Middleware, UI, Persistence Providers,Hardware

TARGET OF VARIATIONVariation in Function: e.g.,

optional .NET adapter

Variation in Data: e.g.,adaptation of message

formats

Variation in Control Flow:workflow and rule

changes

Variation in Technology:e.g., upgrading from

Windows 7 to Windows 10

Variation in Quality Goals:e.g., high performanceLAN for connection with

server

Variation in Environment:e.g., integration in

environment - from Javato REST-based APIs

ProductSolution


1/27/2017


VARIATION DEPENDENCIES &CONSTRAINTS

Variation points are no disconnectedislands but may

depend on each otherbe constrained

Without constraints the variation wouldbe too complex to handleExample for a Constraint:

customer may choose a high endengine exclusively for sports cars

TYPES OF VARIATIONBinding Type

Optional:e.g., advanced searchcan be added to onlineshopOne-of-many:e.g., selecting kind ofpaymentMultiple-of-many:e.g., favorite departmentsin store


1/27/2017


POSITIVE AND NEGATIVEVARIABILITY

Positive VariabilityMinimum core; features are added(high degree of variation)

Negative VariabilityMaximum core; features areremoved (low degree ofvariation)

STRUCTURAL AND NON-STRUCTURAL VARIATIONS

Structural Variationi.e., the system isgenerated from a model(=> snow crystal)Non–StructuralVariationoriginates from featuretrees, natural language,…

Structural variation of aStructural variation of a


1/27/2017


FROM PROBLEM TO SOLUTIONDOMAINVariability in the problem domain must

be implemented in the solutiondomainusing mechanisms such as:

Language-features Inheritance,Overloading, Interfaces, TraitsRuntime CompilationPreprocessingComponent ReuseChange of Binary ArtifactShared Libraries, Class LoadersCode variation (Preprocessors,Implicit DSLs, Generators)ConfigurationAdaptation and Compositionsuch as service compositionReflection with Meta Objects

Binding time• Modeling time• Design time• Implementatio

n time• Compile time• Build time

§ Link time§ Deployment

time§ Load time§ Run time§ Maintenance

time

VARIABILITY & PATTERNSPatterns that supportvariability

StrategyDecoratorVisitorObserverPlug-In ArchitectureComponent ConfiguratorPipes & FiltersMicrokernelAbstract Factory… Source: stanford.edu

Using Software Design Patterns in InformationUsing Software Design Patterns in InformationVisualization helps deal with variabilityVisualization helps deal with variability


1/27/2017


HOW TO DESCRIBE VARIABILITY

Feature ModelsMeta ModelsDSLs (e.g., Workflows)WizardsConfiguration/Deployment FilesNatural Language

Example: Feature ModelExample: Feature Model

WHERE WE ARE:

Scopes &Boundaries

ArchitectingProcess


Qualities


SystematicRe-use



1/27/2017


AD-HOC REUSE IN THE LARGE(PROBLEM)

Unsystematic or Ad-hoc re-use is agood recipe for failure:

source code reuse without understandingit90% component reuse problem - only 10%need to be adapted but this incurs highcoststoo small-grained reusetoo coarse-grained re-useemphasis on binary reuseneglecting business driverstactical instead of strategic reuse

STRATEGIC REUSE IN THE LARGE(SOLUTION)Strategic reuse in the large is

systematic re-use:Economics-drivenReuse of interrelated artifacts (code,testplans, documents, configurations, models)Approaches: Product Families, Ecosystems,PlatformsDefined reuse process

Domain Engineering separated fromApplication EngineeringC/V Analysis for Core AssetIdentificationFeature Models (Customer viewpoints)

Systematic (planned) reuse worksSystematic (planned) reuse works


1/27/2017


IGNORING REFERENCEARCHITECTURE (PROBLEM)

Without ReferenceArchitecture, systemdevelopment is complexUsing a “wrong” ReferenceArchitecture is even worseCreating a ReferenceArchitecture

is error-prone and tediousneeds a lot of effortsviolates the DRY principleis inevitable if there is none

A Reference Architecture mustA Reference Architecture mustfit your needsfit your needs

REFERENCE ARCHITECTURE(SOLUTION)A Reference Architecture (RA)

captures the essence of a domainprovides a domain vocabularycomprises common entities andrelations (i.e., the abstractions)addresses variabilityincludes guidelines for itsinstantiationcan be derived from set of existingsolutions, or from a domain model

SOA Reference Architecture TechnicalStandardSOA Reference Architecture TechnicalStandard


1/27/2017


AD HOC REUSE IN THE SMALL(PROBLEM)

Reuse in the small has a coupleof success stories

PatternsDesign TacticsBest Practices

but many liabilitiesinsufficient RoIunmanageable andunmaintainable reusable entitiestoo complex too handle for sets ofinterdependent components

OVERDOSE OF PATTERNS(PROBLEM)Patterns comprise human

intelligence and experiencesThey provide proven solutions forrecurring problems in given contextsUsing a software pattern makessense if it complies with the needsUsing many patterns is beneficialwhen applied carefully & correctlyTreating patterns as building blocksis wrongWrong pattern application mayeven increase design erosion

There are patterns for almostThere are patterns for almostall problem domainsall problem domains


1/27/2017


SYSTEMATIC AND CLEAN PATTERNSAPPLICATION (I) (SOLUTION)

Use patterns where possible and useful(second part is often ignored)Mind the context and the forces as well as theconsequences of applying a patternStatements like “I used all patterns of the Gang-of-Four book” indicate bad designPatterns are no building blocks but blueprints.You can’t build a patterns libraryPatterns may be implemented in infinite waysHome-grown solutions may be the betterchoice sometimes. Example: Observer in Real-time Systems

But mind the side effects!But mind the side effects!

SYSTEMATIC AND CLEAN PATTERNSAPPLICATION (II) (SOLUTION)

Right pattern for the rightpurpose and scale: architecturepatterns, design patterns,idioms, …Role-based Design:

Whenever pattern isapplicable, identify roles andassign them to existingcomponents. Only if neededadd new components

i.e., Patterns are integratedinto the design

Note: one component maycontribute to multiple patterns


1/27/2017


DO REUSE IN THE SMALL BUT IN ACOMMON CONTEXT (SOLUTION)

Reuse in the Small, aprerequisite for Reuse inthe Large

Take core assets as example

needed for complex, reusablefunctionality that is subject tothe DRY principleworks best for reusable entitieswithin same ecosystem (e.g.,.NET Framework, syngo.via, …)

Source: microsoft.com

The .NET Framework is a SDK for .NET ApplicationThe .NET Framework is a SDK for .NET ApplicationDevelopmentDevelopment

RE-USABILITY (PROBLEM)DON’T reuse low qualitycomponents

they contain defective code… which may affect thewhole system

Cost for reusing low qualitycomponents is mostly higherthan the costs for creatingthem from scratch

Only reuse ofOnly reuse of high quality components increaseshigh quality components increasessustainabilitysustainability


1/27/2017


QUALITY REUSE (SOLUTION)Check quality of reusable assetsAn unusable component is not re-usableEstimate costs for refactoring – i.e.,is component expensive to reuseDo not constrain analysis to thecomponent but also investigatethe enclosing contextIntegrating a low qualitycomponent adds accidentalcomplexity and debt

Source: dailymail.co.ukReuse is a matter of scaleReuse is a matter of scale

WHERE WE ARE:

Scopes &Boundaries

ArchitectingProcess


Qualities


SystematicRe-use



1/27/2017


ARCHITECTUREARCHITECTURE--ENFORCEMENTENFORCEMENT

A real world example of architecture driftA real world example of architecture drift

LACK OF ENFORCEMENT(PROBLEM)

Architecture Drift is the gap betweenimplementation and (conceptual)

architectureCan often not be undone (due to highcosts and time efforts)Developers don’t cause driftintentionally but accidentally due to

Lack of informationWrong interpretation of information

House (as planned)House (as planned)

House (as built)House (as built)

UML?Neveragain!


1/27/2017


LACK OF ENFORCEMENT(SOLUTION)

Architects are responsibleto guide & supportimplementationto visit all teams regularlyto clarify open issuesto obtain and usearchitectural feedback forimprovementto coach and mentor keydevelopers & architects

Name: Confusing ArchitectureContext: TelecommunicationsProblem: In a Telecommunicationsproject a telephone conferenceservice was designed. In the designthere were two entities called“Conference Organizer” and“Conference Manager”. Thedeveloper made a (wrong)assumption.Consequences: Implementation had tobe refactored

Name: Confusing ArchitectureContext: TelecommunicationsProblem: In a Telecommunicationsproject a telephone conferenceservice was designed. In the designthere were two entities called“Conference Organizer” and“Conference Manager”. Thedeveloper made a (wrong)assumption.Consequences: Implementation had tobe refactored

KILL THE MESSENGER (PROBLEM)If developers have issues with the architecture

it’s not due to inability to understand youringenious design!

With a “It can’t be a problem in the architecturaldesign”- attitude architects miss a lot ofimprovement potentialÞThey should proactively and regularly ask

developers and other stakeholders forfeedback

It‘s not a quality proof but a problem, whennobody understands the design!


1/27/2017


CELEBRATE THE MESSENGER(SOLUTION)

Consider feedback from developers andarchitects as a safety net

Profit from their combined experiences& skillsMerge theory & practiceNote: an “excellent conceptual idea”might have unwanted side effectsConsider feedback as a gift byreviewers who spend their time toprovide useful information=> A good feedback culture isimportant

SUMMARY OF SYSTEMATICARCHITECTING

The design process has two phases:Phase 1 – establishing baselinePhase 2 – actual implementation

Modus Operandi:1. Start with functional design (higher priority use cases

before lower priority use cases). Use happy dayscenarios first before continuing with rainy day scenarios

2. Integrate core infrastructures for distribution,concurrency, deployment, battery saving, ...

3. Design (a) infrastructure for operational qualities (higherpriorities first)

4. Design infrastructure for developmental qualities (higherpriorities first) and tactical implementation

5. Assess, repair, and iterate to build the system incrementby increment


1/27/2017


OUTRO QUOTE

Although software has nomass, it does have weight,weight that can ossify anysystem by creating inertia tochange and introducingcrushing complexity

-- Grady Booch