Module System Architecture Context

Transcription

1 Module System Architecture Context by Gerrit Muller Buskerud University College and Buskerud University College Abstract The system architecture process is positioned in a wider context: First in the business context, then in the Creation context. 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 document is published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the document remains complete and unchanged. status: draft version: 1

2 Decomposition of a Business by Gerrit Muller Buskerud University College gaudisite@gmail.com Abstract This article positions the system architecture process in a wider business scope. This positioning is intended to help understanding the processes in which the system architect (or team of system architects) is involved. It focuses on an organization that creates and builds systems consisting of hardware and software. Although other product areas such as solution providers, services, courseware, et cetera also need system architects, the process structure will deviate from the structure as presented here. customer Customer Roadmap Business Drivers Information Order Support 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 document is published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the document remains complete and unchanged. status: concept version: 1.1 Policy and presales sales logisticsproduction service material Planning Customer-Oriented,, and roadmaps Budgets roadmap Budget, plan Needs and feedback Creation Technical Documentation Needs and Feedback -related processes Needs and Feedback,, and Management

3 Simplified Decomposition of the Business customer Customer Roadmap Business Drivers Policy and Planning,, and roadmaps Budgets roadmap Budget, plan Information Order Support Needs and feedback presales Needs and Feedback Creation Needs and Feedback material sales logistics production service Customer-Oriented Technical Documentation -related processes,, and Management Decomposition of a Business 3 Gerrit Muller version: 1.1 PDBprocessDecomposition

4 Financial Characterization of Decomposition customer Customer Roadmap Business Drivers Policy and Planning Management,, and roadmaps Budgets roadmap Budget, plan Needs and feedback material Information presales Creation sales logistics production service Customer Oriented Order Tomorrow's Cashflow -related processes Support Cashflow Generation Needs and Feedback Technical Documentation Assets and Management Decomposition of a Business 4 Gerrit Muller version: 1.1 PDBprocessDecompositionByValue

5 Multiple Instances per Customer Oriented : Depends on geography, customer base, and supply chain. Creation : One per entity to be developed, where such an entity can be a product family, a product, or a subsystem. and Management : One per competence, where a competence is a cohesive set of technologies and methods. Policy and Planning : One per business. This is the pro-active integrating process. Decomposition of a Business 5 Gerrit Muller version: 1.1 PDBprocessInstancesList

6 The Value Chain and the Opposite Feedback Flow customer Customer Roadmap Policy and Planning,, and roadmaps Business Drivers Budgets roadmap Budget, plan Needs and feedback material Information Requirements and Feedback Feedback Technical Documentation Order Value Creation related processes Support Customer-Oriented,, and Management Decomposition of a Business 6 Gerrit Muller version: 1.1 PDBprocessDecompositionPlusFlow

7 Decomposition of the Customer Oriented Information Order Support Order Acquisition Material Order Order Realization Service Support Customer-Oriented Decomposition of a Business 7 Gerrit Muller version: 1.1 PDBcustomerOriented

8 Extended with Generic Developments customer Policy and Planning Needs and feedback presales Creation generics Generic Developments Creation sales logistics production service Customer-Oriented Information Order generics roadmap Budget, plan roadmap Budget, plan Needs and Feedback Customer Roadmap Business Drivers Support,, and roadmaps Budgets material Technical Documentation -related processes,, and Management Decomposition of a Business 8 Gerrit Muller version: 1.1 PDBprocessDecompositionExtended

9 The Creation by Gerrit Muller Buskerud University College Abstract The Creation is described in its context. A phased model for Creation is shown. Many organizations use a phased model as blueprint for the way of working. The operational organization of the product creation process is discussed, especially the role of the operational leader. Distribution 0. feasibility needs specification 1. definition 2. system design 3. engineering 4. integration & test 5. field monitoring 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 document is published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the document remains complete and unchanged. status: concept version: 2.2 design verification engineering core information Legend: in draft full under development most information 50% available in concept preparing or updating work information is stable enough to use heavier change control

10 The Creation in Business Context Customer Customer Roadmap Policy and Planning, and roadmaps Business Drivers Budgets roadmap Budget, plan Requirements and feedback material Information presales Requirements and Feedback sales Creation logistics production service Customer Oriented Technical Documentation Order related processes Support and Management The Creation 10 Gerrit Muller version: 2.2 PCPcontext

11 Phasing of the PCP at Business Level sales 0. feasibility logistics production service 1. definition 2. system design 3. engineering 4. integration & test 5. field monitoring development & engineering: marketing, project management, design The Creation 11 Gerrit Muller version: 2.2 PCPbusinessPhases

12 Phasing the Design Control needs design 0. feasibility specification verification engineering 1. definition 2. system design 3. engineering 4. integration & test 5. field monitoring Legend: core information in draft 50% most information available in concept information is stable enough to use heavier change control full under development preparing or updating work The Creation 12 Gerrit Muller version: 2.2 PCPdesignPhases

13 Advantages and Disadvantages of a Phased benefits disadvantages blueprint: how to work reuse of experience employees know what and when following blueprint blindly too bureaucratic transitions treated black and white reference for management The Creation 13 Gerrit Muller version: 2.2 PCPphasesProsAndCons

14 Characteristics of a Phase Model large impact decisions phase transitions check points order long-lead items order high-cost items product announcement 0. feasibility 1. definition 2. system design 3. engineering 4. integration & test 5. field monitoring needs concurrency specification design verification engineering iteration The Creation 14 Gerrit Muller version: 2.2 PCPcharacteristics

15 Decisions and Phase Transitions Define a minimal set of large-impact decisions. Define the mandatory and supporting information required for the decision. Schedule a decision after the appropriate phase transition. Decide explicitly. Communicate the decision clearly and widely. The Creation 15 Gerrit Muller version: 2.2 PCPdecisions

16 Evolutionary PCP model test and evaluate requirements specification 2% of budget (EVO) 2 weeks (XP) up to 2 months per cyclus build design The Creation 16 Gerrit Muller version: 2.2 PCPspiral

17 Decomposition of the Creation Creation Operational Management specification budget time planning progress control resource management risk management project log Design Control technical needs what is needed specification what will be realized design how to realize verification meeting specs following design engineering how to produce and to maintain Marketing profitability saleability customer input customer expectations commercial structure product pricing market introduction introduction at customer feedback The Creation 17 Gerrit Muller version: 2.2 PCPdecomposition

18 Operational Organization of the PCP entire portfolio operational portfolio operational manager technical portfolio architect commercial portfolio marketing manager product family family operational manager family architect family marketing manager single product (single product) project leader product architect product manager subsystem subsystem project leader subsystem architect module developers The Creation 18 Gerrit Muller version: 2.2 PCPoperationalOrganization

19 Prime Responsibilities of the Operational Leader Specification Quality Resources Time The Creation 19 Gerrit Muller version: 2.2 PCPoperationalTriangle

20 The Rules of the Operational Game business management project leader define project update project specification, resources, time accept or reject assess risks determine feasibility accept execute project within normal quality rules The Creation 20 Gerrit Muller version: 2.2 PCPoperationalGame

21 Operational Teams Sales Manager Application Manager Quality Assurance Logistics Operational Support (project manager) Requirements Analyst Service Marketing or Manager Test Engineer Operational Leader (project leader) Architect - Specific Architects Development support Subsystem Architects Subsystem Operational Leaders Manufacturing The Creation 21 Gerrit Muller version: 2.2 PCPconcentricTeams

22 The System Architecture by Gerrit Muller Buskerud University College Abstract The System Architecture is positioned in the business context. This process bridges the gap between the Policy and Planning and the Creation. The purpose of the System Architecture is to provide the Integral Technical overview and consistency, and to maintain the integrity over time. Subjective characteristics as elegance and simplicity are key elements of a good architecture. The scope of the system architecture process is illustrated by showing 5 views used in a reference architecture, ranging from Customer Business to Realization. customer 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 document is published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the document remains complete and unchanged. status: concept version: 2.3 Customer Roadmap, and roadmaps Business Drivers Policy and Planning Budgets roadmap Context, Vision Budget, plan Needs and feedback Reality check material presales Needs and Feedback Creation sales logisticsproduction service Customer-Oriented Technical Documentation related processes,, and Management Information Systems Architecting Order Stakeholder interaction Support

23 System Architecting in Business Context customer Customer Roadmap Business Drivers Policy and Planning, and roadmaps Budgets roadmap Context, Vision Budget, plan Needs and feedback Reality check material Information presales Systems Architecting Needs and Feedback Creation sales logistics production service Customer-Oriented Technical Documentation Order Stakeholder interaction related processes Support,, and Management The System Architecture 23 Gerrit Muller version: 2.3 SAPprocessSimplified

24 Map of System Architecting and Neighborhood Business Marketing Systems Architecting Budget Roadmapping and requirements specification design engineering verification Design Control Project Management Policy and Planning Creation The System Architecture 24 Gerrit Muller version: 2.3 SAPprocessMap

25 System Architecting Relation between PPP and PCP Context: Portfolio, Time Policy and Planning Vision, Policy, Intention Practical Knowledge Feedback from Reality Creation The System Architecture 25 Gerrit Muller version: 2.3 SAPcouplingPPPtoPCP

26 System Architecting Key Issues key words balancing acts External internal requirements balance Short term needs long term interests Efforts risks from requirements to verification consistency Mutual influence of detailed designs Value costs integrity simplicity elegance stakeholder satisfaction performance qualities example trade-offs synergy functionality specific solution The System Architecture 26 Gerrit Muller version: 2.3 SAPkeyIssues

27 Exercise Creation 1. Map operational organization. 2. Report on one flip the best case. 3. Identify the relationships of the core team: geographical, organizational, psychological, et cetera. 4. Report the result of 3 on one flip. Exercise Creation 27 Gerrit Muller version: 2.3 MSACexercise

28 Decomposition of a Business Importance in Financial terms Value Chain and Feedback Flow customer customer Customer Roadmap Business Drivers Policy and Planning Management,, and roadmaps Budgets roadmap Budget, plan Needs and feedback material Information Creation presales sales logisticsproduction service Customer Oriented Order Tomorrow's Cashflow -related processes Support Cashflow Generation Needs and Feedback Technical Documentation Customer Roadmap Policy and Planning,, and roadmaps Business Drivers Budgets roadmap Budget, plan Needs and feedback material Information Requirements and Feedback Feedback Technical Documentation Order Value Creation related processes Support Customer-Oriented Assets and Management,, and Management intentionally left blank intentionally left blank Exercise Creation 28 Gerrit Muller version: 2.3

29 Creation PCP involves all disciplines, much more than D&E Phased 0. feasibility 1. definition 2. system design 3. engineering 4. integration & test 5. field monitoring 0. feasibility 1. definition 2. system design 3. engineering 4. integration & test 5. field monitoring needs specification sales design logistics verification production engineering service development & engineering: marketing, project management, design Legend: core information in draft full under development 50% preparing or updating work most information available in concept information is stable enough to use heavier change control Incremental Development test and evaluate requirements specification intentionally left blank 2% of budget (EVO) 2 weeks (XP) up to 2 months per cyclus build design Exercise Creation 29 Gerrit Muller version: 2.3

30 PCP Decomposition and Operational Management PCP decomposition Architecture at all levels; From portfolio to subsystem Creation entire portfolio operational portfolio operational manager technical portfolio architect commercial portfolio marketing manager Operational Management Design Control Marketing product family single product family operational manager (single product) project leader family architect product architect family marketing manager product manager specification budget time technical profitability sellability subsystem module subsystem project leader developers subsystem architect Operational Commitment Specification Core: Operational + Technical + Commercial Sales Manager Application Manager Quality Assurance Logistics Operational Support (project manager) Resources Quality Time Requirements Analyst Service Test Engineer marketing manager architect - Specific Architects Development Support project leader Subsystem Architects Subsystem Operational Leaders Manufacturing Exercise Creation 30 Gerrit Muller version: 2.3

31 System Architecture In Business Context Customer Roadmap, and roadmaps Business Drivers Policy and Planning Budgets roadmap Context, Vision Budget, plan Needs and feedback Reality check customer material Creation presales sales logisticsproduction service Customer-Oriented Needs and Feedback Technical Documentation related processes,, and Management Information Systems Architecting Order Stakeholder interaction Support Key Issues key words balance consistency integrity simplicity elegance stakeholder satisfaction balancing acts External internal requirements Short term needs long term interests Efforts risks from requirements to verification Mutual influence of detailed designs Value costs example trade-offs performance synergy functionality qualities specific solution 5 Views drives, justifies, needs enables, supports intentionally left blank What does Customer need in and Why? Customer What Customer How What How Customer objectives Application Functional Conceptual Realization Exercise Creation 31 Gerrit Muller version: 2.3