A Reference Architecture Primer

Transcription

1 by Gerrit Muller Buskerud University College Abstract A Reference Architecture captures the essence of the architecture of a collection of systems. The purpose of a Reference Architecture is to provide guidance for the development of architectures for new versions of the system or extended systems and product families. We provide guidelines for the content of a Reference Architecture and the process to create and maintain it. A Reference Architecture is created by capturing the essentials of existing architectures and by taking into account future needs and opportunities, ranging from specific technologies, to patterns to business models and market segments. architect design and engineer build and test Distribution This article or presentation is written as part of the Gaudí project. The Gaudí project philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an open creation process. This is published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the remains complete and unchanged. status: preliminary draft reference architecture reference architecture extracting essentials system architecture family architecture shared asset architecture architectures constraints and opportunities system A system B product family shared assets engineering ation field feedback actual systems

2 1. general introduction 2. level of abstraction 3. content 4. summary 2 Gerrit Muller RAPnavigation

3 General Introduction to Reference Architectures Why Reference Architectures? When to Use Reference Architectures? What do Reference Architectures contain? How to use Reference Architectures? What are inputs of a Reference Architecture? Criteria for a good Reference Architecture. 3 Gerrit Muller RAPintro

4 Graph of objectives of Reference Architectures managing synergy increased complexity scope size Facilitate multi-site multi-organization multi-vendor multi-* system creation and life-cycle support increased dynamics integration Effectively create new: products product lines product portfolio Achieve interoperability between many different and evolving systems providing guidance, e.g. architecture principles, best practices providing an architecture baseline and an architecture blueprint capturing and sharing (architectural) patterns providing a common lexicon and taxonomy providing a common (architectural) vision providing modularization and the complementary context Articulation of domain and realization concepts Explicit modeling of functions and qualities above systems level Explicit decisions about compatibility, upgrade and interchangeability. 4 Gerrit Muller SAFRAwhy

5 When to Use Reference Architectures evolvable product family architecting Reference Architecture multi-site multi-supplier multi-vendor product family architecting Reference Architectures facilitate the step towards product family architecting and evolvability; this often coincides with multi-* problems mono-system architecting mono-system design mono-disciplinary engineering 5 Gerrit Muller RAPwhen

6 RA Elaborates Mission, Vision and Strategy mission vision strategy elaborated in Reference Architecture multiple organizations guidance for future 6 Gerrit Muller SAFRAstrategy

7 RA = Business Arch. + Technical Arch. + Customer Context customer context requirements black box view technical architecture customer enterprise users relations guidance design patterns technology business model life cycle business architecture 7 Gerrit Muller SAFRAarchitectures

8 Instantiation of a RA in few Transformations architect design and engineer build and test reference architecture system architecture family architecture shared asset architecture system A system B product family shared assets extracting essentials constraints and opportunities field feedback reference architecture architectures engineering ation actual systems 8 Gerrit Muller SAFRAinstantiation

9 Inputs of a Reference Architecture existing architectures customer needs business needs guides evolution mining essence architecture patterns exploration & analysis product portfolio future requirements triggers new changes proven concepts & known problems vision Reference Architecture 9 Gerrit Muller SAFRAflow

10 Criteria for a good RA Criteria for a good Reference Architecture customers product managers understandable for broad set of stakeholders project managers engineers accessible and actually read/seen by majority of the organization... addresses the key issues of the specific domain satisfactory quality acceptable up-to-date and maintainable adds value to the business 10 Gerrit Muller RAPcriteria

11 Challenge: Appropriate Level of Abstraction Single System Product Family in Context Capturing the Essence Size Considerations: What is the appropriate level of abstraction? How many details? Decomposition of Large Documents Reference Architecture or Volume 9 Volume 8 Volume 7 Volume 6 Volume 5 Volume 4 Volume 3 Volume 2 Volume 1 Volume 9 Volume 8 Volume 7 Volume 6 Volume 5 Volume 4 Volume 3 Volume 2 Volume 1 Volume 9 Volume 8 Volume 7 Volume 6 Volume 5 Volume 4 Volume 3 Volume 2 Volume 1 11 Gerrit Muller RAPlevelOfAbstraction

12 Level of Abstraction Single System 10 0 number of details system requirements multidisciplinary design static system definition monodisciplinary 12 Gerrit Muller RAPpyramid

13 Product Family in Context number of details enterprise context enterprise stakeholders systems multidisciplinary design 10 9 parts, connections, lines of code 13 Gerrit Muller RAPdiabolo

14 RA: Capturing the Essence number of details enterprise context enterprise stakeholders systems multidisciplinary design parts, connections, lines of code reference architecture some context details are essential some technical details are essential 14 Gerrit Muller RAPdiaboloRA

15 RA: level of abstraction, number of details 10 3 level of abstraction 10 6 number of details market process flow key drivers key performance indicators information model decomposition concurrency & synchronization compact reference architecture few diagrams only high supplier end market policy supplier process policy flow decomposition resource management value chain supplier Cost of Ownership policy key performance indicators exception handling supplier industry roadmap policy interoper ability behavior concurrency & synchronization security strategic key partners drivers business supplier supplier process models policy descriptions policy function flow API's API's API's safety functional models standards supplier policy shared assets extensive reference architecture many s map of systems information model cache design 15 Gerrit Muller RAPsizeSpectrum

16 Size Considerations 10 3 level of abstraction 10 6 number of details market process flow key performance indicators decomposition key drivers information model concurrency & synchronization compact reference architecture few diagrams only low effort to create maintain read easy to share limited guidance anchor value high supplier end market policy value industry supplier roadmap policy strategic chain key drivers supplier Cost policy of partners supplier business policy process supplier descriptions policy supplier Ownership models process flow interoperability policy function flow map of key performance systems indicators standards decomposition resource management exception handling behavior concurrency & synchronization safety functional models security supplier policy API's API's API's shared assets extensive reference architecture many s significant effort to create maintain read difficult to share great guidance anchor value information model cache design 16 Gerrit Muller RAPsizeConsiderations

17 Decomposition of Large Documents structure recursion structure overview atomic compound compound overview compound compound structure overview compound structure overview compound atomic structure overview compound frontpage title identification author distribution status review history changes diagrams tables 1. aap 2. noot 3. mies lists and ca 50% text meta information max 2 pages atomic contents pages 17 Gerrit Muller RAPDesign

18 What should be in Reference Architectures? Guidance from Best Practices Visualizations Structure What content should be in Reference Architectures? 18 Gerrit Muller RAPcontentIntro

19 Guidance from SAF Best Practices 1.1 One of several prerequisites for architecture creative synthesis is the definition of 5-7 specific key drivers that are critical for success, along with the rationale behind the selection of these items 2.1. The essence of a system can be captured in about 10 models/views 2.2. A diversity of architecture descriptions and models is needed: languages, schemata and the degree of formalism The level of formality increases as we move closer to the implementation level. from 19 Gerrit Muller RAPprinciplesSAF

20 Possible useful visualizations COVmotorwayMana gementkeydrivers LWAvalueChain COVsuppliers AVdynamicsURF AVstakeholders AVcontextMotor waymanagement AVsimpleTVmodel AVdynamicModels AVcostBenefitModels SHTexample StoryLayout ETexampleTime ShiftingWhatIf MICAFtypicalCase MICAFtypicalTiming MICAFclinicalInfoFlow MICAFrequestFlow MICAFfinancialContext MICAFsystemLayers MICAFreferenceModel MICAFmarket Segmentation MICAFinformationLayers FVcommercialTree FVfeatureMatrix FVinformationModel FVdatamodel CVfunctional Decomposition CVconstruction Decomposition CVinformationModel CVprocess Decomposition CVreconstruction PerformanceModel CVstartUp CVworkBreakdown MAFTexampleWebShop CVintegrationPlan RVperformance CostEffort RVmemoryBudgetTable ASMLoverlayBudget MICVpresentation Pipeline FFTSstandardInteractive SystemAnnotated EBMImemory TimingARM MAFTstorage Performance actual figures and references to their use at 20 Gerrit Muller RAPvisualizations

21 Ideal Structure does not exist function 1 function 2 function m view 1 view 2 view n object 1 object 2 object i application 2 application n quality 1 application 1 quality 2 quality k technology k subsystem 1 subsystem 2 technology 1 subsystem n technology 2 21 Gerrit Muller OHTstructure

22 Synthesis, Integration, Relation oriented 1. Functional Decomposition acquisition compress encoding display decompress decoding storage Pipeline 3. Allocation 2. Construction Decomposition view play browse audio video TXT tuner drivers scheduler OS Performance MPEG etc. DS P networking CPU Resource usage RAM 4. Infrastructure framebuffer filesystem etc Exception handling Device abstraction 5. Choice of integrating concepts 22 Gerrit Muller LWAarchitectureHow

23 Checklist for RA content customer context technical architecture key performance parameters product features, functions business financials stakeholders benefits, concerns concept of operations relations guidance core technologies critical resources design issues dominant patterns business model life cycle stakeholders benefits, concerns business architecture 23 Gerrit Muller RAPcontentGuidance

24 Summary of the role of Reference Architectures customers market mission vision strategy needs elaboration knowledge technology opportunities Reference Architecture guidance existing architectures multiple organizations new or evolved architectures 24 Gerrit Muller SAFRAroleRA