Human Measure and architecting

logo TBD
Gerrit Muller
Embedded Systems Institute Den Dolech 2 (Laplace Building 0.10) P.O. Box 513, 5600 MB Eindhoven The Netherlands
gerrit.muller@embeddedsystems.nl

Abstract
This book bundles the human measure and architecting articles. The articles address the relationship between product creation and humans and the role of the system architect.

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. All Gaudí documents are available at: http://www.gaudisite.nl/

version: 0.2

status: preliminary draft

January 22, 2010

Contents
Introduction 1 The System Architect; Meddler or Hero? 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Practical experience: memory usage in a medical workstation. 1.3 Introducing an Architect . . . . . . . . . . . . . . . . . . . . 1.4 What is architecting? . . . . . . . . . . . . . . . . . . . . . . 1.5 CBA: Conclusions, Benchmarking and Acknowledgements . . 1.5.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Benchmarking . . . . . . . . . . . . . . . . . . . . . 1.5.3 Acknowledgements . . . . . . . . . . . . . . . . . . . 1.5.4 Gaudí homepage . . . . . . . . . . . . . . . . . . . . 1.6 Does architecture belong in the research laboratory? . . . . . . 1.7 What is an architect? . . . . . . . . . . . . . . . . . . . . . . The Importance of System Architecting for Development 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2.2 The Challenge . . . . . . . . . . . . . . . . . . . . . . 2.3 Architecting . . . . . . . . . . . . . . . . . . . . . . . 2.4 Architecting Courses . . . . . . . . . . . . . . . . . . ix 1 1 2 6 8 13 13 13 14 15 16 18 20 20 21 23 27 31 31 32 35 39 42 47 52 53

. . . . . . . . . . .

. . . . . . . . . . .

2

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3

Decomposing the Architect; What are Critical Success Factors? 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 What is an Architect? . . . . . . . . . . . . . . . . . . . . . . 3.3 Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Nature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Discussion and Conclusions . . . . . . . . . . . . . . . . . . 3.8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

4

Architecting for Humans; How to Transfer Experience? 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 4.2 User Experience . . . . . . . . . . . . . . . . . . . . 4.3 Engineering . . . . . . . . . . . . . . . . . . . . . . 4.4 Education . . . . . . . . . . . . . . . . . . . . . . . 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . 4.6 Acknowledgements . . . . . . . . . . . . . . . . . . From the soft and fuzzy context to SMART engineering 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 5.2 Case description . . . . . . . . . . . . . . . . . . . . 5.3 Why SMART? . . . . . . . . . . . . . . . . . . . . 5.4 Examples of smartening fuzzy requirements . . . . . 5.5 How to verify? . . . . . . . . . . . . . . . . . . . . 5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . 5.7 Acknowledgements . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

54 54 57 62 64 66 67 68 68 70 72 76 80 81 82 83 83 85 87 88 92 94 95 96 97 97 97 100 102 104 104 104 111 113 114

5

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

6

Communicating via CAFCR; illustrated by security example 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 The ”CAFCR” model and qualities . . . . . . . . . . . . . 6.4 Zooming in on security . . . . . . . . . . . . . . . . . . . 6.5 The wonder of communication . . . . . . . . . . . . . . . 6.6 Story telling . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 6.8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . Architect and Human Measure; the integration role 7.1 Introduction . . . . . . . . . . . . . . . . . . . . 7.2 Illustration of the problem . . . . . . . . . . . . 7.3 What is architecting? . . . . . . . . . . . . . . . 7.4 The architect . . . . . . . . . . . . . . . . . . . Architecture; the building as a product 8.1 Introduction . . . . . . . . . . . . . 8.2 The Product: Building WDC . . . . 8.3 The Product: Digital Video Recorder 8.4 Discussion . . . . . . . . . . . . . . 8.5 Conclusion . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

7

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

8

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

Gerrit Muller Human Measure and architecting
January 22, 2010 version: 0.2

Embedded Systems Institute

page: iii

. . . . . . . . . . . . . . . Five viewpoints for an architecture. . . .18 1. 2 3 4 4 5 5 6 7 7 8 9 10 11 11 12 13 13 14 15 16 17 18 19 21 22 23 1. . . . Practical experience. Question generator . . .15 1. . . . . . . . . . . Guiding how by providing five how-viewpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 1. . . . . . The task of the architect is to integrate all these viewpoints. . . . . . . . . .List of Figures 1. . . . . . . Gaudí homepage . . . . .22 1. . . . . Positioning the Gaudí research ambition in the worldwide efforts . in order to get a valuable. . . . . . . . A small subset of contributors. . . . . . . . Architecture and research? The technology management cycle . . . .16 1. . . . . . . . . . . . . . . . . . The Challenge . . . . . . . . . . . . . . .3 1. . . . . . . . . . . . . . . . . . . a medical workstation . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . The architect as integrator . . .1 2. . The engineer’s perception of the architect . . . . . . . . . . .13 1. . . . . . . . . . .10 1. . . . . here mostly participants of the System Architecture course . . . .3 . Integration uncovers hidden problems . . . .7 1.2 1. . . The meddling architect as complementing factor in a team full of heroes . . . . . The customer issues which are relevant for the case illustrated in this article . . . . .2 2. .. . .9 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 1. . . . . . . . . . .23 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 1. . When all pieces fit . . Architecting scope . . . . . . . . . . . . . . . . . .8 1. . . . . . .6 1. . . . Question generator . . . . . . . . .5 1. . . . . . . . . . Architecting visualized .19 1. . . . .20 1. . . . . Is architecting scientific? . . . . . . . . . . . . . . . .11 The position within the organisation . . . . Simplified process view . . . . . . . . . . . . . . . .12 1. . . . . . . . . . . . . Solution: measure and redesign . . . .14 1. . . . . . . . . . Architecture awareness evolution . . . The architect maintains technical roots . . . . . . . . . . . . . .1 1. . . . . usable and feasible product. . . . . . Problem: unlimited memory consumption . Method: process based budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . Architects Collect a Rich Set of Patterns . . . . . . . . . . . . The outline of a CAFCR based architecting method . . Example of Generic Smoothing Consideration . . . . . . . .4 2. . . . . . . .4 3. . . . . . . . . Connecting System Design to Detailed Design . . . .20 3. . Major Bottleneck: Mental Dynamic Range . . Profile of an ”Ideal” System Architect . Architect: Connecting Problem and Technical Solution . . . Goals of 2-day Management SARCH course Program of 2-day Management SARCH . . . . . . . . . . . . . . . . .8 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Growth in technical breadth. . . For Comparison: Profile of a Project Leader . . . . . .5 2. .13 2. . . . intermediate functions from specialist to system architect . .1 3. . . . . . Conclusion .25 3. . . . . . . . . . . . . . . . .10 2. . . . . . . . . . . . . Profile of System Architect . . . . Positioning System Architecting . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 3. . . . . . . . . . . . . . . 2010 version: 0. . . . .16 3. . . . . . . . . . . . . . . . . . . . . . . .9 2. . . . . . . . . .16 3. . . . . . . . . . . . . . . . . . . . . Discretization effects . . . . . . ”CAFCR” model . .12 3. . . . . . . . .2 Embedded Systems Institute page: v . . . . . . . . .8 3. . . . . . . . . . . . . . . . . . . .3 3. . . . . . . . .5 3.26 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 2. Gerrit Muller Human Measure and architecting January 22. . . . . .18 3. . . . Architecting Scope . . . . . . . . . . . Example of Discretization Problem . . . . . . . . . . . . . . Gaudí ambition . . . . . . . . . . . . . . . .19 3. .27 System architecture process . . . . . . . . . . . . . . . What Can We Do to Improve the Environment? .21 3. Draft System Architect Curriculum . . . . .12 2. Operational hierarchy .2. . . Business Organization Stovepipe . . . . . . . . . .11 3. .11 2. . . . Different Concerns . . . . . . . . . . . . . . . . . . . . . . Typical Development of a System Architect . . . . . . . . . From SW input to physical Effect . 23 24 24 25 25 26 26 27 28 28 29 29 30 32 32 33 34 35 35 36 37 37 38 39 39 40 40 42 43 43 44 45 46 47 48 48 49 50 50 52 Decomposing Contributing Factors . . . . . . Line Organization Stovepipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 3. . .2 3. . . . . . . . . Project Leader versus System Architect . .6 3. Most Discriminating Characteristics . . . . . . . . . . . . . . . . . . . . . . . . Proposed Curriculum for System Architects . Course status in Philips . . . . . . . . . Different Architecting Scopes . . . Example: Trapezoid Pattern . .24 3. . . . Simplified decomposition of the Business . . . . . . . . . . . . . . . . . . . .14 3. . . . . . . . . . .14 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 3. . . . . . . . . . . . .22 3. . . . . .13 3. . . . . . . . . . . . . .17 3. . . . . . . . . . . . . . .9 3. . . . .15 2. . What is architecting? . .7 2. . . . Organizational Problem: Disconnect . . . . . . . . . . . .23 3. . . . . . . . . Guiding how . . . . . . . . . . . . . . . . . . . . . . . . . Stakeholders Architect . . . . . . .

. . . . . . . . . . . . . . . . From SMART to Fuzzy . .6 5. . . . .4 Did you ever program a Video Recorder (VCR or PVR)? Product Creation Cycle . . . . . . . . . . . . . . . . . . . . . . .13 5. . . User access point to long food-chain . . . .11 4. . . . . . . . . . .16 4. .4 4. . . . . . . . . . .12 5. . . . .1 5. . . . . Image Quality . . . . . . . . . Fashionable . Stakeholders and concerns . Changing Education model in time . Problem Statement . . . . . . . . . . . . . . . . . . . . .15 5. . . .12 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interaction or Irritation? . . . . . . . . . . . . . . . . Problem (2): From Imagination to Formalization Theory: Subcontractors require SMART relation Critical Success Factor: Mutual understanding . . . . . . . . . . Example product: mobile infotainment Value chain . . . . . . . . . .15 4. . . . . . . . . . .11 5. . . . . . . . . . . . . . . The ”Fuzzy” needs of the User . . . . . . . . . Bridging the gap between Experience and Engineering . . . . . . .17 5. . . . . . . . . . Factors influencing the User Experience . . . . . . . . . . . . . . . . . . Example Time Shift recording .9 5. . . . .1 4. . . . . . . . . . . . . Educational Material per education stage . . . . . . . . . .9 4. . . . . . . .6 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2010 version: 0. . .13 4. . . . . . . . . . . . . . . .17 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 5. . .10 5. . . . . . . . . . . . . 54 55 56 56 57 58 59 59 60 61 62 63 64 64 65 66 66 70 70 71 72 73 74 74 75 75 76 76 77 77 78 78 79 79 80 81 83 85 85 86 Gerrit Muller Human Measure and architecting January 22. . Why SMART is needed . Product Creation is much more than Engineering . . . . Internal stakeholders . . . . 2 Levels of Experience . . . . . . . . . . . The ”Fuzzy” needs of the Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 5. . . . . .3 5. . . . . . .8 4. . . . . . . . . . . . . . . . . . .4 5. . . . . . . . . . . . . . . . . . . . ”Fuzzy expectations” and ”SMART descriptions” Supply Chain Stakeholders . . . . . . . . . . . . . .2 4. . .7 4. . . . .2 5.19 6. . . . . . . . . . . . . . . . What are the requirements for these products? . . . . . . . . . . . . . . . . . . . . . . . . . . . The world of the construction . . . . . . . . . . . .10 4. . . . . . . . .3 6. . . .4. . . . . . . . . Experience Transfer . . . . . . . . . .1 6. . . . . . Increasing Initiative required . . . . . . . . . . . . . .14 5. . . . . . Views on Aggregation. . . . . . . . . . . . . . . . . . . . . .3 4. What if? . . . .2 6. . . . . . . . . . . . . . . . OOTI workshop 2001 . . . . . Architecting for Humans . . . . . . . . . . . . . . . . . .16 5. . . . . . . . . . . . . Specifiable characteristics . . . . . . . . . . . . . . . . .5 4. Response Time: Latency Budget . . . .8 5. . . . . . . Key Success Factor: Feedback . . . . . .5 5.14 4. . . . Infinite Experience Space . . .2 Embedded Systems Institute page: vi . . . . . . . . . . The ”SMART” world of the Design . . . . . . . Complementing views . . . . .

The abstracted customer . . . . .7 7. . . . . . . . . . . .4 8. .13 101 101 102 102 103 105 106 106 107 108 109 109 110 111 112 112 113 114 Gerrit Muller Human Measure and architecting January 22. . . . . . .12 8. . . . . The architect integrating all specialist teamplayers .6 6. . . . . . . . . .9 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . in order to get a valuable. .12 6. . . . . . . The task of the architect is to integrate all these viewpoints. . . . . . . . . . . . . . . . WDC architecting mapped on ”CAFCR” . . . . . . . .2 7. The architect maintains technical roots . . . . . . . . Philips management objectives w. . . . . . . . . . . . . . . . . . . . Story telling method . . . . . . .13 6. . The quality needles are generic integrating concepts through the 5 CAFCR views . . . . . . . Product Creation Cycle . . . What is Architecting? . . . . . . . . . . . . . . . . . . . .1 8. . . . . Required architect know-how per view. . . . . . . . . . . . . . . . . . . . .5 The ”CAFCR” model .10 6. . . . . . . . . . . . Architecting visualized . . . . . . . . . . . . . . . . . . . . . . . . . . .9 8. . . . . . .1 7. . . . .16 7. . . . . . . . . . . . The technical side of the architecture . . . .6 7. . . . . . . . . . . . . usable and feasible product. Intense interaction needed for mutual understanding . . . . . . . . . . . . . . . . . .3 7. . . . . Architecting dynamics . . . . Bridging the gap between Human Experience and Engineering . . How do these stakeholders communicate? . . . . .9 8. . . . . . . Mutual understanding as function of time .7 8. . . . . . . . . .8 7. . . Campus The architects vision . . . Example security through all views .r. . . . . . . . . . . . . . . . . . . .11 6. . . . . . . . . . . . . . After user amendation . . . . . The task of the architect is to integrate all these viewpoints. .11 8. . . . .8 8. . . . . . . . . . . . . . . . . . . . . Did you ever program a VCR? . . . .5 8. . . .5 6. . . . . . . . . . . . . . . . . Guiding how by providing five how-viewpoints . . Summary . . . The product . . . .4 7.7 6. . . . . . . . . . . . . .14 6. . . . . Active listening: the art of the receiver to decode the message . . . . Bridging 2 worlds . Example product: Digital Video Recorder . . . . . . . . .8 6. . . . . . . . . . .2 Embedded Systems Institute page: vii . . . . . . . Five viewpoints for an architecture. . . . . . . . . .6 8. . . . . .3 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2010 version: 0. . . . . . . . . . . . . . . . . . in order to get a valuable. . . . . . . . . . . . . . . . . . . . .15 6. . . .2 8.t. Role of views . Product architecting mapped on ”CAFCR” . . . . . 87 88 89 89 90 91 92 92 93 94 95 95 97 98 99 100 7. . . . . . . . . . . . . . . . . . . . . . The technical side of the architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . typical for current architects and the preferred profile. . . .6. usable and feasible product. Space impression . . . Five viewpoints for an architecture. . . . . . . . . . .10 8. . . . . . . . . . . . . . .

. . . . . . . . . the Campus . . . . .t. .r. . . Engineers are educated in construction disciplines . . . . . . . . . . . . . . .4 Construction limits intrude in Experience .r. . . . . . .1 8.4 5. . . . . . . . . . . . . .1 8. . . Objectives of the Philips management w. . . . . Wishes and concerns of the inhabitants .3 8. . . . . . . . .2 8. . . . . . . . .List of Tables 4.2 4. . . . . . How to ”SMART”en Experience? .t. . . . . . Prerequisites for continuous successfull product creation . . . . . the Campus Subgoals w. . . . . . . . . .3 4.1 4. . . . . . . . 57 60 62 65 68 105 107 108 111 The meaning of SMART . . Consumer Objectives . . . . . . . . . . . . . . . . . . . . . . . .

. Most articles are updated based on feedback from readers and students.Introduction This book bundles the articles about Human Measure and Architecting. At this moment the book is in its early infancy. The most up to date version of the articles can always be found at [7]. The same information can be found here in presentation format. Chapters can be read as autonomous units.

2 Embedded Systems Institute page: x . 2010 version: 0.Gerrit Muller Human Measure and architecting January 22.

where a program is result driven 1 Donderdag Ochtend Voordrachten: Thursday morning presentation. . Figure 1. diagram other (more) important organisational dimensions are shown: • program and projects.Chapter 1 The System Architect. which is used to explain the contribution of the architect and the tension this causes in an organisation. such as the opening which positions the speaker in the research line organization. Meddler or Hero? How much memory do you use? That is too much! asks questions uncovers problems has nicest job architect engineer for many engineers the system architect = threat or menace 1.1 Introduction This lecture is presented at the DoVo1 lecture series. However in this. The last section of this article ”CBA” is also tradition. This long history also means that many traditions or rituals are followed. The presentation itself focuses on a case.1 shows the position of the speaker in the organisation. This lecture series is an ”institute” within Philips Research. Some background material is added about what an architect looks like and about the relation between architecture and research. Three short lectures (20 minutes) per session are used to share research work between all researchers. somewhat satiric.

The software designers of this product did an excellent job. research wide objective driven management • know how transfer. ”The Art of Systems Architecting” [14]. via the CTT (Centre for Technical Training) Another interesting tradition is that groups are more often identified by the name of the leader than by the technical competence. 2010 version: 3.1 Embedded Systems Institute page: 2 healthcare ISD ISH .3 shows the memory usage at the beginning of the integration phase. The medical workstation[8] is an add-on product to existing X-ray systems. introduced in the market in 1992. see figure 1.1: The position within the organisation • LRTO (Long Range Technical Objectives). This emphasis on the human (leader) contribution is nice. for example memory usage. by means of a so called CRT-copy.line Philips Medical Semiconductors CE Components Research NatLab CTT EST IST ISM SARCH SWA IA IPA ESAS IT program projects DM comp DS AV Gerrit Muller FAM SW reuse Heartcare PB PvdH HO O RT L Figure 1. However many integral design aspects did not get the right attention level. X-ray systems used to print the imaging results directly on film.2. One workstation can serve multiple examination rooms. 1.2 Practical experience: memory usage in a medical workstation. The workstation is positioned between X-ray system and printer and adds formatting and layout capabilities. Recommended literature is the book by Rechtin. Figure 1. an exact copy of the monitor display on film. applying many new technologies in a fruitful way. Gerrit Muller Human Measure and architecting January 22.

makes models and budgets. This process decomposition enables a manageable granularity of the budget and sufficient implementation freedom for designers. A minor shortage of memory is handled by the virtual memory system. which is based on a process decomposition of the system. This is also known as the 95% ready syndrome. measures it. When the integration begins problems become visible. Only when the system is integrated and used under production conditions the performance problem becomes visible. It also enables measurement and verification. The architect starts to ask questions about the memory usage. a medical workstation The figure clearly shows a disastrous problem: the system needs much more memory (ca 200 MByte) than available as physical memory (64 MByte). Figure 1. At the bottom of the figure the performance of the system is shown as a function of the memory use. making and testing their component. Projects run without (visible) problems during the decomposition phases. This redesign realized an acceptable memory usage. see figure 1. The result is that in cooperation with the software engineers an iterative redesign was implemented.6 visualizes this process. All components builders are happily designing.5 shows the memory budget.4. but a major shortage leads to an unacceptable drop in performance. The SW engineers of the medical workstation did not experience any performance problem while creating their components. when the project members declare to at 95%.2: Practical experience.typical clinical image (intestines) URF-systems EasyVision: Medical Imaging Workstation Figure 1. Models and budgets are important means of the architect. 2010 version: 3. The invisible problems cause a significant delay2 . This late visibility and detection of problems is quite normal in the development of complex systems. Figure 1. because the operating system and the analysis tools use process boundaries as natural resource management boundaries. then actually more than half of the work still needs to be done. because every individual component fits easily in the available memory. 2 Gerrit Muller Human Measure and architecting January 22.1 Embedded Systems Institute page: 3 .

2010 version: 3. measurement DLLs tuning 74 MB measured budget Figure 1.3: Problem: unlimited memory consumption 200 MB fragmentation bulk data data code OS anti-fragmenting budget based awareness.4: Solution: measure and redesign Gerrit Muller Human Measure and architecting January 22.1 Embedded Systems Institute page: 4 .total measured memory usage O S code data bulk data fragmentation performance 0 physical memory 64 MB memory usage paging to disk 200 MB Figure 1.

1 Embedded Systems Institute other UI 20 shared libraries print server data 30 MByte communication server storage server page: 5 . scheduled closing date realized closing date integration and test delay During integration numerous problems become visible Figure 1.6: Integration uncovers hidden problems Gerrit Muller Human Measure and architecting January 22.5: Method: process based budgeting UNIX component 1 component 2 component 3 component 4 Do you have any design issues for the design meeting? The default answer is: No.10 0 code 10 20 measured (left column) budget per process (right column) Figure 1. 2010 version: 3.

1. As soon as the integration starts all invisible problems suddenly become visible. trouble shooting and problem solving earns a lot of credit. An architect needs sufficient know-how to understand the context as well as the technology. This changes the appreciation of the architect dramatically. suddenly he becomes an indispensable team member! After completion of the integration the mood returns to good.8 shows the phases an organisation is going through in a typical project where an architect is introduced. in order to design a solution.1 people scope including Embedded Systems Institute page: 6 .3 Introducing an Architect portfolio architect product line architect system architect architect function product product line product scope portfolio solution context fitting individuals (human factors) including stakeholders architect technical sound including designers (process) technology only context technology Figure 1. In general increasing the product scope of an architect coincides with an increase in people scope at the same time. Figure 3. The common denominator for all these architects is the bridge function between context and technology (or problem and solution). which changes the mood to poor. Most of these engineers are simply not aware of potential problems! This lack of awareness is reflected in the difficulty to plan design meetings. the beginning of a crisis. which fits in the context and is technical sound at the same time. by hard work. brainstorming. As long as individual designers can work independently the collective mood is great. see also figure 1. Figure 1. An architect who proves himself in this difficult stage.4 shows that the scope of architects widely varies. Sometimes the best in class technical specialist gets the architect title imposed.7: Architecting scope One of the main causes of the late visibility of problems is the limited context awareness of most component engineers. because they don’t see any issues to be discussed. In a Gerrit Muller Human Measure and architecting January 22. In both cases the introduction of a broad system architect causes a shock effect in the organisation. Quite often the engineers don’t see the benefit of such a meeting. Many organisations don’t have explicit system architects. 2010 version: 3. while an architect is mostly perceived as a threat or a menace.9.

1 Embedded Systems Institute page: 7 . he always discovers some weak spots.8: Architecture awareness evolution next project. begin of project 2 aware. The architect does the top level design. the nice hand-waving work. An architect always starts to ask questions. the architect only worsens the problem. even excellent architects will not prevent this. Whenever you want to benefit from the architect’s expertise. However this crisis will be less severe. without being too concerned with the nasty details.9: The engineer’s perception of the architect The judgement or the opinion is based on a sample of all data.essential team member perception of architect hard shared labour. by showing even more hidden problems. 2010 version: 3. Despite the incompleteness of the data and despite a lack of domain and solution know-how the architect forms an opinion anyway. crisis threat menace 1 mood unaware. end of integration 5 4 3 mutual respect. before integration good Figure 1. again during integration the mood will degrade. fitting in the limited available time. begin of integration poor. How much memory do you use? That is too much! asks questions uncovers problems has nicest job architect engineer for many engineers the system architect = threat or menace Figure 1. by asking for a solution. While sampling the problem and solution domain in this way. to build up understanding and overview. The identification of problems and risks is often based on a judgement or an opinion. Gerrit Muller Human Measure and architecting January 22.

The conceptual view contains a decomposition.1. based on intention and context understanding) in combination with bottom up (constraint aware. Or in even more popular terms: do the right things and do the things right Understanding Describing Guiding Why What How Do the right things Do the things right Figure 1.12 shows these 5 views with some relevant issues with respect to the illustrated memory usage. 2010 version: 3. It also contains concepts to constrain the memory usage. where an examination has a typical size of 20 images. The application and functional view are here shown together. Architects do this job by frequent viewpoint hopping. such as anti-fragmentation and dynamic link libraries.4 What is architecting? Architecting in product creation spans from understanding the why. Top down (objective driven. looking at the problem from many different viewpoints. The realization view contains the actual measured memory usage as well as the budgeted usage.10: Architecting visualized Architecting is a job which is done by all members of the product creation team. The customer objectives view and the application view provide the why from the customer. which includes (despite the name) also the non functional requirements. The how of the product is described in the conceptual and realization view. as shown in figure 7. identifying opportunities. via describing the what to guiding the how. as shown in figure 7. The job of the architect is to integrate these views in a consistent and balanced way. Gerrit Muller Human Measure and architecting January 22. what and how A useful top level decomposition of an architecture is provided by the socalled ”CAFCR” model.1 Embedded Systems Institute page: 8 . database and print servers.5. constrained by a street price of 50k$. Figure 1. sampling the problem and solution space in order to build up an understanding of the business.4. amongst others in import. which are auto-printed on 3 film sheets. expressed by a typical case with 3 connected X-ray system. The functional view describes the what of the product. know how based). however the architect is responsible for the consistency and balance of why. where the conceptual view is changing less in time than the fast changing realization (Moore’s law!). The customer objectives are expressed in a number of keydrivers.

The how of the product is created by many specialists. 2010 version: 3.11: Five viewpoints for an architecture. The how is guided by the architecture. Figure 1. At least 5 views are required for guidance: • • • • • functional decomposition construction decomposition allocation of functions to construction elements infrastructure integrating concepts Figure 7. The axis of this space are: • functions • (HW) components • characteristics The question in any point in space looks like: ”How about characteristic c in HW component h when performing function f?” Nearly all questions formulated in this way will get an answer unknown. Gerrit Muller Human Measure and architecting January 22.What does Customer need in Product and Why? Customer Customer What How Customer Application objectives understanding Product What Functional intention Product How Conceptual objective driven Realisation context opportunities constraint know how awareness based Figure 1. This question generator is based on a discrete 3-dimensional space.6 visualizes these 5 how views. where every point in this space can be used to formulate a question. The task of the architect is to integrate all these viewpoints. which can be used to uncover potential problems.1 Embedded Systems Institute page: 9 .15 shows a question generators.14 and 1. in order to get a valuable. which in most cases means here is a potential problem. usable and feasible product.

which uses a priori know-how to select the really relevant questions.street price 50k$ Customer How Application Product What Functional Product How Conceptual Realisation measured 200 MB * 3 exam rooms per exam: * 20 images * auto-print on 3 sheets decomposition antifragmentation DLL's budget 74 MB Figure 1. strengths and weaknesses Gerrit Muller Human Measure and architecting January 22.1 Embedded Systems Institute page: 10 . value of functions and performance • how critical. The a priori know-how includes: • importance.What does Customer need in Product and Why? Customer What Customer objectives key drivers: * throughput * diagnostic quality * film saving . sensitive technical solutions are • people and organisation bias. 2010 version: 3.12: The customer issues which are relevant for the case illustrated in this article Note that a good architect uses a more refined question generator.

2. Infrastructure view audio play video drivers framebuffer TXT etc.13: Guiding how by providing five how-viewpoints How about the <characteristic> of the <component> when performing <function> ? browse functions What is the the play game play movie record show broadcast latency induced by graphics generator when browsing video processor graphics generator mixer monitor control tuner tic s SNR ris latency accuracy component cte ch ara processing memory usage Figure 1. Choice of integrating concepts Figure 1. Functional Decomposition 3. browse networking OS CPU Resource usage RAM etc Exception handling filesystem Device abstraction scheduler MPEG DSP Construction Decomposition tuner Performance 5.14: Question generator Gerrit Muller Human Measure and architecting January 22. 2010 version: 3.1.1 Embedded Systems Institute page: 11 . Allocation acquisition compress decompress encoding storage display decoding Pipeline 4.

1 Embedded Systems Institute page: 12 .How about the <characteristic> of the <component> when performing <function>? functions query DB render film play movie next brightness import server What is the memory usage of the user interface when querying the DB user interface print server database server export server SNR tics accuracy ris memory usage processing latency component ch ara cte Figure 1. 2010 version: 3.15: Question generator Gerrit Muller Human Measure and architecting January 22.

Benchmarking and Acknowledgements Conclusions meddling architect manufacturing application mechanics electronics marketing software service specialist specialist specialist specialist specialist specialist specialist team full of heroes Figure 1. 2010 version: 3.1 Embedded Systems Institute specialist optics page: 13 .5 1.1. so the architect is not the hero. Sometimes the architect is meddling in the work area of specialists. with the intention to serve the overall objective.5. all team members are heroes.5.2 Benchmarking certainty predictability "informatica" curriculum in the Netherlands optimization SEI (CMU) INCOSE IEEE1471 Gaudi ambition scope technology only including including including agility process stakeholders full life cycle business and human factors Figure 1.16: The meddling architect as complementing factor in a team full of heroes The work of the architect is always overlapping with the work of others. The integration of views is the main added value of the architect.17: Positioning the Gaudí research ambition in the worldwide efforts Most software engineering oriented institutes in the world. such as SEI(CMU) stress the importance of systematic approaches and the use of processes. 1. see figure 7.7. This Gerrit Muller Human Measure and architecting January 22.1 CBA: Conclusions. The architect can only be succesfull by virtue of the rest of the team.

The participants of these courses provide me always with valuable feedback and often trigger new insights. Eddy Veldmans. Peter Watabe. Bart Driesen. Peter Beuk. Figure 2. Jan Mulder. Erwin Stut. Luc Krikhaar. Peter Blijd. Gerian Engbers. Sudeendra Milosevski. Michiel van Bommel. Paul Bruin. Gertjan Koushik. Ger de Kruif. Klaas Muijen. Yasuma van Ouwerkerk. Frank Wouters. Johan Ham. Eric Crins. Erik Vermeer. Theo Gijsbers. Hammer. Maurice America. Peter Daenen. Rene van Wetten. Wim van der Laak. William Soede.18: A small subset of contributors.3 Acknowledgements Figure 1. JGH Schelkers. Huub den Dekker. Jan Gooren. Albert Aarts. Gerben Bingley. Jaap Vermeulen. Jo van Bommel. M Peters. Part of that work is consolidated in ”standards” for best practices. Jeroen van Venrooy. Onno van den Donker. Tom van Gogh. Joost Verberkt. The actual danger is in the less skilled people applying the systematic approaches in rigid ways. Wim Patrzalek. Jeroen Kaag. Juergen Gieles. Wil Mueller. Patrick Lobo. Stefan Pu. Rajaraman Misdom. Timo Vos. Jarek Vergoossen. Lincoln van de Meulenhof. Rene van den Brink. Auke Huiban. Dennis Houtepen. Rob Hofsink. Pierre Fischer.5. Agile formalization can be supportive. here mostly participants of the System Architecture course Jürgen Müller again critically reviewed the presentation. Jan de Waal. which is mostly flourishing in the military and aerospace industry. Wim Luttikhuizen. Gerard van den Heuvel. such as IEEE1471. Mark van der Linden. Alwin de Wit. Frans de Greef. Andre van Rooijen. Cristian van Loon. Steven Soepenberg. Peter Versteijlen. Lex Schippers. Han Schatorie. Paul Bandakka. Richard Penners. Frank Medema. Robert Joosten. Ton Gonot. Henk Stroucken. Vlatko van den Broek.emphasis often results in formalization. Paul Poesse. Robert van Balen. Jan Spaak. Frank Wubben. Rob Huis in 't Veld. William van der Sterren and Peter Strictly speaking formalization and agility are not contradictions. Marc Wijnstra.18 shows some of the participants of the SARCH courses. Peter Follon. Gert Jan Vullings. Raymond van der Heijden. Nic Zieringer. Dieter Hoogenstraaten. which quite often is related to human aspects. Roel Elzinga. Mahesh Ledeboer. Raymond Engel. Jarl Dijkema. Erik Pijpers. Pierre Jaspers. H Huijnen. Piet Zwaans. Wim Heerink. Roland Dobbelsteen. Mathieu van Splunter. Ad van Bakel. Joost Beelen. Ferdinand Merkus. Nico Vugts. Jurgen Deckers. Sjirk ten Pierick. Bas van Rijnsoever. Gerry Stroucken. Henk Bas. John Figure 1. Frank Stevers. helped to streamline it and discussed the right sequence of presenting. Ad Peeters. The System Engineering community. Frank van Velden. Henk Boot. Hans Eggenhuisen. Werner Janson. Robert Buurman. Clemy Wissink. John Boer. stakeholders and life cycle management. Bob Obbink.1 Embedded Systems Institute page: 14 . Kees van der Sterren. Insight. 1. Xuemei Boom. 3 Gerrit Muller Human Measure and architecting January 22. 2010 version: 3. Hans Zondag. Rob Schellingerhout. Olu Gopalan. Getty Engelsma. Han Rankers. Leo Koolen. is very mature with respect to requirements engineering. Adrian Akiwumi-Assani. The ambition of the Gaudí project is to provide more insight in the art part of architecting.8 positions several worldwide activities with respect to formalization level and scope. Bjorn Giesselman. Wim Thus. Jodie Geron. Louis Young Tai Liu van der Steen. Frans Faber. Marcel Roelandt. understanding and overview are more important in a broad perspective. Francoise Jansen. Marcel Siereveld. Alef Schreppers. Huib Kloprogge. Egbert Derks. Paul van Tuijl. Pieter Jan Thijssen. Kees Bos. which endangers the flexibility and adaptivity to fast changing technology and markets3 For wider scopes formalization is more difficult and less fruitful. Jan Gerben Algra. Ben Harmsze.

4 Gaudí homepage http://nlww. 1.philips. ESA stakeholders.pdf oldPresentations. Jaap van der Heijden.pdf MedicalImagingPaper. OOTI req eng links on this homepage: this presentation annotated text background information Medical Imaging original documentation Medical Imaging MeddlerOrSaviorSlides. 2010 version: 3. Jaap van der Heijden pointed out the areas of interest for the target audience. see[7] for the www internet URL.19 shows the URL for the Gaudí homepage.research. See also the bibliography for more recommended reading.com:8080/ research/swa_group/muller/ containing : more than 30 recent articles and or presentations course material SARCH.natlab. Niek Lambert and Milan van den Muyzenberg patiently listened to the trial run and politely pointed out the missing steps and unclear issues. Gerrit Muller Human Measure and architecting January 22.19: Gaudí homepage Figure 1.html Figure 1.1 Embedded Systems Institute page: 15 .van den Hamer suggested a lot of improvements.5. Pierre America.pdf MeddlerOrSaviorPaper.

Redefinition of architecting as enabling technology to specify.20 shows a model for technology management[3]. research is taking care of the long term. It makes quite a lot of sense to explore architecting methods as well as consolidate architecting methods.1.6 Does architecture belong in the research laboratory? Research laboratories are used to in-depth technology research. where system know how is mostly required to build a proof of concept. what do we mean with scientific? Figure 1. which means that the application often happens in close cooperation with the industry. based upon 3 phase cycle. fits architecting in a natural way in this technology management model. the so called industry as laboratory. However the application of architecting methods often needs the full product creation context. This figure shows that architecting methods span a significant range of scientific methods.20: Architecture and research? The technology management cycle One of the main functions of research is technology exploration. 2010 version: 3. The next question is: Is architecting research scientific?. Or in other words the architecture researcher borrows methods from other scientific paradigms. Exploration of new ideas Exploration of new ideas Application of technology Application of technology Consolidation of know how Consolidation of know how Research Product Division Figure 1.21 shows several sciences as a spectrum with respect to the hardness level of the scientific methods. design and integrate complex systems. Figure 1. The answer of this question requires a philosophical basis. striving for as hard results as possible4 Which means that the results can be very soft. Product divisions focus on short and medium term business objectives. The consolidation is needed for the transfer. where the technology application is needed for learning and proof of concept. Architecting at the other hand is very broad and not tangible. How to distinguish plausible results from an integer researcher from convincing results from a charlatan? 4 Gerrit Muller Human Measure and architecting January 22.1 Embedded Systems Institute page: 16 .

21: Is architecting scientific? Gerrit Muller Human Measure and architecting January 22.1 Embedded Systems Institute page: 17 .mathematics hard prove certainty physics medicine human sciences descriptive reasoning plausible charlatan soft handwaving convincing legend hard science prediction confidence statistics evidence based architecting methods crypto biometric identification example: security human factor soft science no science Figure 1. 2010 version: 3.

3 specialist Embedded Systems Institute page: 18 .22: The architect as integrator The role of the architect is an integrator role. as shown in figure 7. The real world is less black and white. Later when growing in the above mentioned directions the difficult challenge is to maintain sufficient technical know how and feeling. as shown in figure 1. see [6]. Architects must have sufficient roots in the technical domain. The main growth direction are: • • • • technical generalist business insight process insight human insight breadth of knowledge generalist generalist specialist specialist specialist specialist specialist specialist specialist depth of knowledge Figure 1.22.7 What is an architect? The architect is good technical educated engineer. who has grown into an architect. which is highly complementary to the specialists.9.1. a complete spectrum exists between specialists and generalists. Gerrit Muller Human Measure and architecting January 22. which means that they must experience angineering in at least one discipline. 2010 version: 0.

23: The architect maintains technical roots Gerrit Muller Human Measure and architecting January 22.breadth of knowledge all-round specialist system architect aspect architect depth of knowledge specialist root knowledge Figure 1.3 Embedded Systems Institute page: 19 . 2010 version: 0.

such as project leaders.Chapter 2 The Importance of System Architecting for Development customer marketing manager business manager st ra te gy sales. Complementary integral teamplayers. The next step in enabling these complementary core teams. in the form of a two day workshop is developed to create a shared insight in the role of the architect and architecting.1 Introduction Systems architecting is one of the integrating disciplines in Product Creation. the ESA course and the SARCH course. service good sflow means & line manager methods architect pc p suppliers product manager project leader SARCH engineers MSARCH 2. is to address the managerial context of the system architect. Several efforts are ongoing to help potential architects in developing the needed skills and obtaining sufficient knowhow. A special course. production logistics. such as the architecure school at research. architects and product managers can form the core of highly effective product creation teams. .

System architecture is one of many measures to attack the challenge of dramatically increasing the designer productivity. Historical data shows that the effort increase is also exponential. despite many promising reuse. ranging from business to people management. Figure 2.2. in order to keep the product creation teams at a manageable size. The increase of functionality and performance results in an increase of the effort to make new products. COTS (Commercial Off The Shelf) et cetera approaches.1: The Challenge In the keynote speech at the Philips Software Conference 2001 Ad Huijser showed that this challenge must be addressed by a multitude of measures. like Moore’s law for electronics. Gerrit Muller Human Measure and architecting January 22. platform.3 Embedded Systems Institute page: 21 . see figure 2. 2010 version: 0.2.2 The Challenge The functionality and performance of products is ever increasing.1 shows the challenge we are facing: to increase the designer productivity dramatically. required team size 1000 ic tren d 2010 2005 2005 Manage large PCP teams of > 1000 people 2010 our challenge histor 100 2000 or Significantly increase SW productivity 1995 10 1 10 100 SW productivity from: Ad Huijser Philips Software Conference 2001 Figure 2. The increase of designer productivity (new functionality or performance increase per designer year) is rather limited.

3 Embedded Systems Institute from: Ad Huijser Philips Software Conference 2001 Integral approach: value chain.. roadmap People and Process Technology Enables Drives Market products page: 22 .Business Orientation Application Know-how Research Architecture and Component approach Make..2: When all pieces fit . 2010 version: 0. Gerrit Muller Human Measure and architecting January 22. Buy Partnering Education Open Source InnerSource Effective Processes (SPI) Decision Process Basic Enabling Figure 2.

3: Simplified process view Figure 2.3 Architecting The architecting courses at this moment use a few fundamental concepts as the basis of system architecting. customer real i policy and planning syst hec k Philips business ty c val customer oriented process (sales. Normally an architect will spend 80% of his time in product creation and 20% in product policy and planning. see figure 2. 2010 version: 0.3.3 con te visi xt. production) PCP people and technology management process Figure 2. as well as the relations with the other processes.2. service. service. on em arc proc hitectu r ess PCPe ue er old eh ction k sta tera in comparable with: + project management + marketing Figure 2. production) people and technology management process Gerrit Muller Human Measure and architecting January 22. A simplified process decomposition. is used to explain the context of system architecting in the business context.4 shows the system architecting process overlayed on this process decomposition. customer Philips business policy and planning customer oriented process (sales.4: System architecture process Embedded Systems Institute page: 23 .

5. the actual work is done by the designers and engineers. Figure 7.5: What is architecting? During the course often the ”CAFCR” model is used as simple reference model. justifies.4 drives. The architect is mostly guiding the implementation. The fundamental architecting activities are depicted in figure 7. needs enables.6 shows that architecting involves many more aspects and especially the integrating concepts are crucial to get working products. Understanding Describing Guiding Why What How Do the right things Do the things right Figure 2. Guiding the implementation is done by providing guidelines and high level designs for many different viewpoints. Figure 7.3 Embedded Systems Institute page: 24 . This model is a refinement of figure 7. The architect must play an independent role in considering all stakeholders interests and searching for an effective solution. see figure 6. Many more initiatives are ongoing in the world.One of the fundamental messages is that architects must combine know how of the solution (technology) with understanding of the problem (customer/application).6: ”CAFCR” model Creating the solution is a collective effort of many designers and engineers. Figure 2. 2010 version: 0. The figure shows that the system architecting efforts are not heading for a fixed set of rigid proce- Gerrit Muller Human Measure and architecting January 22. supports What does Customer need in Product and Why? Customer What Customer How Product What Product How Customer objectives Application Functional Conceptual Realization Figure 2.4. Note that many people think that the major task of the architect is to define the decomposition and to define and manage the interfaces of this decomposition.8 defines the relative position of these initiatives and the ambition of the Gaudí project.6 shows some of the frequently occurring viewpoints for guiding the implementation.

from component level to product portfolio.7: Guiding how dures. Infrastructure view audio play video TXT etc. et cetera). Parallel with the increase of the scope in the product direction the scope of the architect is increasing in the people direction. These 3 roles exist recursively at other levels. certainty predictability "informatica" curriculum in the Netherlands optimization SEI (CMU) INCOSE IEEE1471 Gaudi ambition scope technology only including including including agility process stakeholders full life cycle business and human factors Figure 2.9 shows this operational oriented hierarchy in product creation.9 makes clear that the architecting role is present at multiple scopes. In most cases the project leader is operational organization oriented. adaptable.3 Embedded Systems Institute page: 25 . browse networking OS CPU Resource usage RAM etc Exception handling filesystem Device abstraction drivers frametuner buffer Performance scheduler MPEG DSP Construction Decomposition 5.1. but instead are stimulating architects to fill their personal toolbox with many flexible tools to remain agile (responsive. Choice of integrating concepts Figure 2. Figure 2. 2. as shown in figure 3. Figure 2. 2010 version: 0.4 Gerrit Muller Human Measure and architecting January 22.8: Gaudí ambition The architect is the technical oriented integrating core team player. Allocation acquisition compress decompress encoding storage display decoding Pipeline 4. Functional Decomposition 3. and the product manager commercial oriented.

3 Embedded Systems Institute page: 26 .operational technical architect family portfolio commercial marketing manager family entire portfolio product family single product subsystem portfolio operational manager family operational manager project leader project leader architect product marketing manager product manager (single product) architect subsystem (subsystem) architect module developers Figure 2. 2010 version: 0.10: Architecting Scope Gerrit Muller Human Measure and architecting January 22.9: Operational hierarchy solution context fitting individuals (human factors) including people scope including portfolio architect product line architect system architect architect stakeholders architect technical sound including designers (process) technology only context technology function product product line product scope portfolio Figure 2.

For most architects this is a difficult step. At the top of the figure the growth path of a system architect[6] is shown.14 shows the current status of courses within Philips. production logistics. Note that this broadened scope will somewhat reduce his technology involvement.2.11: Stakeholders Architect The course tries to stimulate the (potential) architect to broaden his profile. Instead it is a palet of courses.11 shows the architect and his stakeholders. Philips may gain a lot of effectiveness if the Gerrit Muller Human Measure and architecting January 22. One of the main messages to the architects is that they themselves must earn credibility and create visibility. managers should coach and help architects through this transformation. Figure 2. as shown in figure 7. where the architect must select the courses which best fit his current needs. the ESA course started mid 2000 and the MSARCH was first given begin 2002. which limit them in performing the job in the broad role as described here.4 Architecting Courses The two main types of architecting courses are: • courses for (potential) architects and close relatives • courses for the managerial context Figure 2.13.15 shows the goal of the 2 day management SARCH workshop. In color coding is indicated if courses are available inetrnal or external. Below the courses or course subjects are shown which fit in the architect career path. Note that this is not a unified list for all architects.8.3 Embedded Systems Institute page: 27 . Figure 2. The architect has to learn to cooperate with the designers and engineers to compensate for this reduction. A first attempt to define a curriculum for architects is shown in figure 2. service good sflow means & line manager methods architect p pc suppliers product manager project leader SARCH engineers MSARCH Figure 2. Many architects complain that their (managerial) context does not share the same view on architecting. customer marketing manager business manager st ra te gy sales. The first SARCH course has been given end of 1999. 2010 version: 0. and positions the SARCH and the MSARCH in this landscape.

while the subtle relationships. 2010 version: 1. Nevertheless to reach the desired objectives this is the minimum time needed.12: Profile of System Architect root technical know-how specific technologies and methods MPEG RF UML and more EMC generalist technical know-how system design methodology business & application insight process insight broaden non technical scope increase skills business methodology psycho-social skills broaden technology scope stimulate personal development architecture school ESA SW ESA silicon ESA system mechatronics industrial vision optics COPA value engineering cost engineering QFD design for manufacturing systems engineering reliability machine control process control performance HW/SW effective leading communication safety and more SARCH ESA stakeholders roadmapping SPI/CMM integral architecting integration negotation advanced presentation conflict management and more hands-on SARCH advanced SARCH technology management change management available marketing leadership coaching and more external missing early draft and more presentation and more Figure 2. That creates an illusion of understanding.Current Architects Required Architects l l n n er io ua na tio m s at pt tio to tive lica e is s nc al p nc cu jec fu re ap co b o Figure 2. That is the main reason that more than half of the time is spent (inter)active. If managers are not yet ripe to show commitment by investing these two Gerrit Muller Human Measure and architecting January 22. see figure 2. with practical illustration and even more important active hands-on work. well defined models and processes. It is extremely dangerous if the management course only consists of glossy. When approaching management teams the investment of 2 full days is often a hurdle.13: Draft System Architect Curriculum managers are working and facilitating in the same direction. Alltogether a very loaded program is followed.2 Embedded Systems Institute page: 28 .16. The challenge for a Management SARCH is to balance the theory (200+ sheets of SARCH material). by sharing the same vision on architecting and architects. conflicting interests and non ideal behavior are not experienced.

like given a short interactive presentation. Gerrit Muller Human Measure and architecting January 22.number of courses upto May 2002 Abbreviation Course appr. total participants 230 80 12 Lecturers System Architecture Embedded Systems Architecting. 2010 version: 1.2 Embedded Systems Institute page: 29 . than other bootstrapping activities. Only self motivated teams will benefit from such a course. Stakeholders System Architecting for Managers SARCH ESA MSARCH 15 5 1 Gerrit Muller 2002 H2: others Pierre America Frank Pijpers Gerrit Muller Figure 2.15: Goals of 2-day Management SARCH course days.14: Course status in Philips managerial awareness of: + what is architecting + business impact of architecting + role and profile of an architect to + enable integral approach + stimulate architects to substantially contribute: * at business level * to strategic goals * from technological strength Figure 2. are needed before forcing this course on them.

evaluation Figure 2. roadmapping HRM aspects.session day 1 morning subject positioning the System Architecture Process Product Creation Process product families.2 Embedded Systems Institute page: 30 . appraisal. generic developments day 1 afternoon role and task of the system architect profile of the system architect documentation. etcetera wrap up. how to continue. career path. reviewing and other supportive processes day 2 morning day 2 afternoon requirements capturing.16: Program of 2-day Management SARCH Gerrit Muller Human Measure and architecting January 22. expectations. selection. 2010 version: 1.

We identified a number of missing steps in between these courses: addressing multi-disciplinary design. has been given 36 times (May 2006) to about 570 participants. which addresses the technical broadening of designers. system architects? At Philips and the Embedded Systems Institute we have been very successful in teaching the non-technical aspects of systems architecting to people. We fill this hole by ”single aspect” courses that address one aspect at the time. but they struggle to integrate this into an architecting approach. and effective. but the teacher is not satisfied. for instance. is also successful. This course. that has been given more than 20 times to more than 300 participants. . We also provide the Embedded Systems Architecting course (ESA). The performance oriented course. What are Critical Success Factors? Environment variation feedback stimulating patterns skills Experience Education Nature 3. that has been given 7 times to about 100 people. The dissatisfaction of the teacher is that the participants pick up many submethods and techniques provided in the course. The evaluation after 3 courses revealed a problem: the participants are satisfied. The next course that we developed to fill this hole is the Multi-Objective System Architecting and Design (MOSAD) course. called SARCH.Chapter 3 Decomposing the Architect. performance or reliability.1 Introduction One of the big challenges of today is: How do we get more.

2 What is an Architect? root technical knowledge generalist technical knowledge business.Environment variation feedback stimulating patterns skills Experience Education Nature Figure 3. 2010 version: 1. value. Figure 3.2 Embedded Systems Institute page: 32 . The system architect is rooted in technology. customers. A thorough understanding of a single technological subject is an essential underpinning. logistics. 3. environment. We decomposed these factors into four categories: education. We will discuss these four categories in separate sections.2: Typical Development of a System Architect System architects need a wide range of knowledge.2 shows a typical development of a system architect. The next step is a broadening of the technical scope. experience. skills and experience to be effective. We will start with a section about the architect.1. it will become obvious that most problems have a root cause outside of technology.1: Decomposing Contributing Factors This conclusion triggered the analysis of critical success factors for system architects. Two main parallel streams are opened: • The business side: the market. as shown in Figure 3. When the awakening system architect has reached a technological breadth. and nature. to create a baseline for the further analysis. application insight process insight psycho-social skills Figure 3. competition. service aspects • The process side: who is doing what and why Gerrit Muller Human Measure and architecting January 22.

9 shows a more gradual spectrum from specialist to system architect. Most developers of complex high tech products are specialists. The decomposition of the development work is most often optimized to create a work breakdown enabling these specialists to do their work with as much autonomy as possible. This root is important for the generalist himself. intermediate functions from specialist to system architect Architects require a generalist profile. 2010 version: 1. Specialists are needed for their in depth knowledge. It is vital in the communication with other specialists. The system architect will view these dimensions from a technological perspective. because it gives the generalist credibility. The growing awareness of the psychological and the sociological aspects is the next phase of growth. Figure 7. while the generalists are needed for their general integrating ability. such as the amount of available time and the finite capacity of the human mind. The figure also shows that a generalist has somewhere his roots in in detailed technical knowledge.2 Embedded Systems Institute page: 33 .During this phase the system architect will broaden in these two dimensions. Both generalists and specialists are needed. The arrows show that intermediate functions exist in larger product developments. The step from a specialist to a generalist is of course not a binary transition. breadth of knowledge all-round specialist system architect aspect architect depth of knowledge specialist root knowledge Figure 3. since one of their primary functions is to generate the top-level specification and design of the system. Again when a sufficient level of understanding is attained an awareness starts to grow that people behave much less rationally than technical designs. There are more functions in the Product Creation Process which benefit from a generalist profile.3: Growth in technical breadth. For instance the function of project-leader or tester both require a broad area of know how. Most generalists are constrained in the depth of their knowledge by normal human limitations. which are natural Gerrit Muller Human Measure and architecting January 22. since it provides him with an anchor and a frame of reference. Normally there are much more specialists required than generalists. They need an in-depth understanding of the applicable technology to effectively guide the product development.

in order to design a solution. in order to design the software architecture of the entire system. In general increasing the product scope of an architect coincides with an increase in people scope at the same time. Figure 3.2 Embedded Systems Institute page: 34 . which fits in the context and is technical sound at the same time. Examples of aspect architects are: • subsystem architects • SW.4: Different Architecting Scopes Many products are becoming so complex that a single architect is not capable of covering the entire breadth of the required detailed knowledge areas. as this will improve the credibility of the team of architects. however the limited scope reduces the required breadth to a hopefully realistic level. The common denominator for all these architects is the bridge function between context and technology (or problem and solution). In those cases a team of architects is required. On the other hand a subsystem architect requires multi-disciplinary knowledge. people scope including solution context fitting individuals (human factors) including portfolio architect product line architect system architect architect stakeholders architect technical sound including designers (process) technology only context technology function product product line product scope portfolio Figure 3. that is complementing each other in knowledge and skills. mechanics or electronics architects For instance a software architect needs a significant in-depth knowledge of software engineering and technologies.4 shows that the scope of architects widely varies. 2010 version: 1.stepping stones for the awakening architect. It is recommended that those architects have complementary roots as well. An architect needs sufficient know-how to understand the context as well as the technology. Gerrit Muller Human Measure and architecting January 22.

2010 version: 1.3 Education root technical know-how apply theory in practice generalist technical know-how become all-round architecture school mathematics physics chemistry mechanical engineering computer science electronical engineering business. At the top of the figure the growth path of a system architect is shown. In color coding is indicated if courses are available internal or external.5: Proposed Curriculum for System Architects A curriculum proposal for architects is shown in Figure 3.5.EVO. Note that this is not a unified list for all architects. Instead it is a palette of courses. process and many more reliability engineering QFD and more Bredemeyer SW architecture available external missing Figure 3. logistics decompositions + mapping technical functions and several more Conceptual + construction decomposition + functional decomposition + information model and many more Realization + budget + benchmarking + performance analysis + safety analysis and many more safety performance a priori solution know-how story analyse design use case analyse design detailed design U" U' diagnostic quality CoO image quality U throughput T IQ spec purchase price B typical case BoM CPU budget S render engine P' Moore's law memory budget common console P M' M processing library pixel depth memory limit profit margin standard workstation Figure 3.6: The outline of a CAFCR based architecting method Gerrit Muller Human Measure and architecting January 22.2 Embedded Systems Institute page: 35 . method outline framework submethods integration via qualities explore specific details reasoning market vision method visualization Customer objectives + key drivers + value chain + business models + supplier map Application + stakeholders and concerns + context diagram + entity relationship models + dynamic models Functional + use case + commercial. Below the courses or course subjects are shown which fit in the architect career path. where the architect must select the courses which best fit his current needs. application insight process insight experience the non-technical aspects psycho-social skills see every human as an individual ESA SW ESA silicon ESA s ystem System design methods Execution architecture Architectural reasoning SARCH ESA stakeholders advanced SARCH legend conventional curriculums ESA mechatronics Thomas Gilb . requirements eng Bredemeyer Role of the architect marketing.3.

10 0 10 1 10 2 10 3 number of details system requirements design decisions parts connections lines of code and growing every year. high level or generic. The translation of system requirements into detailed mono-disciplinary design decisions spans many orders of magnitude.. system 10 4 10 5 10 6 10 7 10 8 multidisciplinary monodisciplinary Figure 3. Story telling is the starting point for specific case analysis and design studies. Customer Objectives. The framework is a decomposition into five views. Figure 3. The decomposition into CAFCR views and into qualities both tend to be rather abstract. as it is being used in the MOSAD or Architectural Reasoning course..Figure 3. a complementary approach is added to explore specific details: story telling. The stories and detailed case and design studies should help to keep the insights factual. the “CAFCR” model. Functional. Per view in the decomposition a collection of submethods is given. and parts. The basic working methods of the architect and the decompositions should help the architect to maintain the overview and to prevent drowning in the tremendous amount of data and relationships. The collection is filled by borrowing relevant methods from many disciplines. Therefore.6 shows the overall outline of an architecting method.. 2010 version: 1. Conceptual. connections. The combination of Figures 3. The right hand side shows the visualization of the steps of the method. The technical product description is the accumulation of monodisciplinary formalizations. The decomposition into qualities is orthogonal to the “CAFCR” model. The collections of submethods are open-ended.2 Embedded Systems Institute page: 36 .7: Connecting System Design to Detailed Design These approaches are combined into a thread of reasoning: valuable insights in the different views in relation to each other. Qualities are used as integrating elements.6 and 3.7 shows this dynamic range as a pyramid with the system at the top and the millions of technical details at the bottom. cost and size in the system requirements specification ultimately result in millions of details in the technical product description: million(s) of lines of code.7 brings us to a very common organi- Gerrit Muller Human Measure and architecting January 22. Application. The few statements of performance. and Realization views. A decomposition in itself is not useful without the complementing integration.

Figure 3. In essence the architect must combine and balance breadth and depth iterations. Figure 3..9..How can the product be realized What are the critical decisions What does Customer need in Product and Why? Customer objectives Application Functional Conceptual gap Realisation system requirements design decisions parts connections lines of code and growing every year.9: Architect: Connecting Problem and Technical Solution Our definition of the work of an architect places this role as a bridge between these two worlds.2 Embedded Systems Institute page: 37 . We should realize that this architect role is quite a stretching proposition.. CAFCR) and technical expertise (depth. application and business direction and at the same time the same architect is expected to be able to discuss technological details at nuts and bolts level. What does Customer need in Product and Why? How can the product be realized What are the critical decisions Customer objectives Application Functional Conceptual Realisation 10 0 10 1 10 2 10 3 10 4 10 5 10 6 10 7 10 8 number of details system requirements design decisions parts connections lines of code and growing every year. The architect is stretched in customer.. time does and brain capacity don’t allow the architect to Gerrit Muller Human Measure and architecting January 22. the mono-disciplinary area in the pyramid).. 2010 version: 1. By necessity the architect will function most of the time at higher abstraction levels.8 shows this disconnect. as shown in Figure 3..8: Organizational Problem: Disconnect zational problem: the disconnect between customer oriented reasoning (breadth. Figure 3.

2010 version: 1. and even more challenging connecting breadth and depth appears to be very difficult.10 0 10 2 10 3 10 4 10 5 10 6 10 7 system architect senior engineer stretch 10 1 number of details stretch 100 engineer 10 Figure 3.2 stretch 1 Embedded Systems Institute page: 38 . Gerrit Muller Human Measure and architecting January 22.10 shows that different people fill different spots in the abstraction hierarchies. The MOSAD course provides means to address: • the breadth of systems architecting • the depth of technological design • the connection of breadth and depth If we look back at the first editions of the MOSAD course. then we see that participants have the tendency to either go for breadth or for depth. For communication purposes and to get a healthy system design the roles must have sufficient overlap.10: Major Bottleneck: Mental Dynamic Range spend all time at detailed design level. But exploring both breadth and depth. This means that all players need to be stretched regularly beyond their natural realm of comfort. Figure 3.

and reasoning power.4 9 8 7 6 5 4 3 2 1 0 Nature t g l t st al ic al w ty ill ht ht nt e n e e n g n rk n s le s st g n tio wo atio kin ope rtis ialis rali ptu at itic nh tivi l sk sig sig me nes du res co kin alu atur sigh hin ctio aisa atio k a a n n v s . A more complete description of this profile and the skills in this profile can be found at[11]. A project leader is totally focused on the result. know-how.12: For Comparison: Profile of a Project Leader The required profile is so requiring that not many people fit into it. it is a socalled sheep with seven legs. 9 8 7 6 5 4 3 2 1 0 l t st al ic al w ty ill ht ht nt e n e re ht g n g n rk n s le s st g n tio wo atio kin ope rtis ialis rali ptu at ritic knh tivi l sk sig sig me nes du res co kin alu atu sig hin ctio aisa atio v e c s . For comparison the profile of a project leader is shown in Figure 3. which as a team are close to this profile. This profile is strongly based upon an architecting style. which is based on technical leadership. In real life we are quite happy if we have people available with a reasonable approximation of this profile.11. which is the core discipline for project leaders. l t e g c e r a a n n m a ca v e e n ni eam en ti-ta ble exp pe en nc rag ve c ion cre nu s i s i ove lete sch pro itia m er s fe al i coa sel pp oti u t a m r s ic i s g co p ti pt a m l p in ion om le rci r m r c t sa e m oce olit imp om cu mu flex by s m ito ci cus p c tru so th m do pr co on de ns ab au m om c co Figure 3. This requires project management skills.3. Gerrit Muller Human Measure and architecting January 22. as shown in Figure 3. where the architect provides direction (know-how and reasoning power) as well as moderates the integration (interpersonal skills).2 Embedded Systems Institute page: 39 .11: Profile of an ”Ideal” System Architect The profile of the ”ideal” system architect shows a broad spectrum of required skills. Quite some emphasis in the skill set is on interpersonal skills. The combination of complementary approximations allows for the formation of architecture teams.12. e c l t e g c r m r a ca v e e ni eam en ti-ta ble exp pe en nc rag e c ion cre nu s i s i ove lete sch pro itia m er s fe al in coa sele pp oti u t a m r s ic i s g co p tiv pt a m l p in ion tom le rci r m r c m oce olit imp om cu mu flex by s m ito sa e ci cus p c tru so th m do pr co on m de ns ab au m co co Figure 3. If this ability is missing the person runs a severe risk on a burn out. 2010 version: 1. The multi-tasking ability is an important prerequisite for the project leader.

open auth by expertise specialist generalist human resource man coaching selection appraisal motivation 6.0 0.0 2.2 Embedded Systems Institute page: 40 .0 3.0 5. people walking in) occur all the time.0 communication teamwork documentation multi-tasking flexible. The next step is to detect those people which need time and concentration to make progress.11 and 3.0 8.0 7.14 are quite discriminating when selecting (potential) system architects: The first reduction step.project leader system architect interpersonal skills 9. this would block the progress of many other people. where frequent interrupts (meetings.0 know-how commercial customer value sales feature commercial insight reasoning power completeness schedule monitor progress initial cost decision making project man process process insight politics insight improvement conceptual pragmatic constructive critical absorption knhw creativity Figure 3. Ignoring these interrupts is not recommendable.0 4.12 are grouped together. Whenever these Gerrit Muller Human Measure and architecting January 22.14: Most Discriminating Characteristics In practice the characteristics shown in Figure 3. 2010 version: 1. This step reduces the input stream with one order of magnitude. telephone calls. • Generalist • Multi-tasking • Authority by expertise • Constructive critical • Balance between conceptual and pragmatic Figure 3. These people become unnerved in the job of the system architect. where the more detailed skills from Figures 3. is to select the generalists only. when searching for architects.0 1.13.13: Project Leader versus System Architect The comparison is further visualized in Figure 3.

The attitude of the (potential) architect is important for the long term effectiveness. Conceptual-only people dream up academic solutions. However in the long run the inbreeding of ideas takes its toll. This requires a pragmatic approach. The balance between conceptual thinking and being pragmatic is also rather discriminating. Architecting based on know-how and contribution costs a lot of energy. We have observed that architects asking for formal power are often successful on the short term. Building up authority requires know-how and visible contribution to projects.people become system architect nevertheless they are in sever danger of stress and burn out. 2010 version: 1. However the capability to translate these concepts in real world activities or implementations is crucial. Roughly two attitudes can be distinguished: architects that ask for formal power and architects that operate on the basis of build-up authority. but it pays back in the long term. hence it is also the benefit of the person itself to fairly asses the multitasking characteristic. Conceptual thinking is a must for an architect. Gerrit Muller Human Measure and architecting January 22. creating a single focus in the beginning.2 Embedded Systems Institute page: 41 .

This same behavior is also present in the actuation of gradient fields in MRI scanners. as shown in Figure 3. conversion. 2010 version: 1. moves with a constant velocity to the next position.2 Embedded Systems Institute step expose brightness t vx page: 42 .16 shows such a chain of three steps: computation. grey level mapping invert contrast / brightness gradient field generation RF Gz wafer stage movement vy Look up table TE TR output contrast input Gx Gy expose Figure 3. transmission). designer and architect. more electronic steps (controllers. In all years of being an engineer. and then stays at the next position for some time (constant). If all these events are processed by the (potential) architect. One of the very common technical problems is the actuation by software of some physical entity. In the system a chain of transformations takes place to get from a high level software representation towards an actual physical behavior by physical objects. then a frame of reference is created that is very valuable for future architecting work. and actuation. and more mechanical steps (motors.3. where this parameter is constant at different levels for some time and switches linearly from one level to another level.15. moving or displaying.15: Example: Trapezoid Pattern In this section we will illustrate the experience factor by means of a few architecture patterns that repeatedly popped up in completely different domains. a sample table is at a given position (constant). Note that this chain is often more complex in real systems with more software steps (controller algorithms. In these cases the software often has to create set-points for one parameter. For instance.5 Experience The effectiveness of an architect depends on experience. For this purpose we look at the Trapezoid Pattern. amplifiers). and in the grey level mapping in imaging displays (although the last example uses grey levels as running parameters instead of time). Figure 3. for instance for positioning. a lot of different needs in different contexts with different solutions with different complicating challenges pass by. corrections). The high level software representation that is the starting point is unconstrained (high precision in time as well as Gerrit Muller Human Measure and architecting January 22.

The virtual model in the high level software does not take this into account or makes (calibrated) assumptions. y 4) (x 1. y 1) (x n. variations et cetera.17: Discretization effects The computation step transforms the unconstrained representation into a constrained sampled list of values. V(t) DAC actuation discrete samples analog signal mechanical optical or physical effect [m/s] [mT/m] Figure 3. v 2 ) (t. y 1) (x 2. Normally the digital to analog conversion is a bottleneck in the values that can be reached. . y 3) (x 4. noise.16: From SW input to physical Effect in value). The conversion and actuation steps have their own particular transfer functions. (1. see Figure 3. This conversion can be very Gerrit Muller Human Measure and architecting January 22. y 2) computation conversion breakpoints (x 1. Not all values can be reached . y n) . The question is how this software output is transformed into the actual physical actuation and if artifacts will be observable in the physical performance.2 Embedded Systems Institute page: 43 .(x 3. These steps may introduce additional delays. This discretization may introduce system level problems: Staircase effects the linear shape is approximated by many staircase-like steps. The most common representation is break-point based: the coordinates. are specified. v t) . where the running parameter changes the linear behavior. input is discrete output is discrete potential problems: staircase effects not all values can be reached impact on frequency domain broken invariants (surface) potential benefits: optimized algoritms (fixed point) Figure 3. . . 2010 version: 1. v 1 ) (2. This transformation is a discretization in two directions: time and value.17.

However. The consequence of this limitation is that the physical reality may differ in a systematic way from the virtual model in the high level software. Broken invariants (surface) The high level software model in many systems is based on invariants. In this example the frequency of the modulation may introduce unexpected physical behavior. Discretization problems.14159 the system should be at position x = 2. the artifacts introduced by discretization. The time-values are also limited. such as 255 = 5V olt) reduces processor load.much limited in low cost solutions (8-bits. If the model assumes we move with v = 3.1m/s and 42% of the time v = 3. while actually the system is controlled to stop at t = 3. Interestingly.718281. 2010 version: 1. due to aliasing-like problems the system performance might degrade in unexpected ways. if we control velocity linear.1.18: Example of Discretization Problem Gerrit Muller Human Measure and architecting January 22.2 Embedded Systems Institute page: 44 . 256 values) to limited (16-bit.1m/s. the measures against artifacts are also universally applicable. varying from sub-microsecond for more expensive solutions to milliseconds for simple low-cost controls. Many of the higher frequency artifacts are filtered out in the analog and physical part of the chain. then the position will deviate significant. A priori use of the need for discretization can also turn into a benefit. For example the high level software may have determined that at moment t = 3.2m/s. Especially the consequent use of integer representations (with some pragmatic normalization. For instance. will violate the higher level assumption. x = 2. but introduce again their own next level of problems and artifacts. at lower software level. However.7. 65536 values). such as vibrations. These solutions work. the low level software can compensate for this error by modulating the value: 58% of the time v = 3. then we expect that we now the position as the integral of velocity. memory use and may increase system performance.14159m/s. Discretization. false contour f(x) 10 bits pixel value 8 bits pixel value x Figure 3. the exact consequence and the right countermeasure are domain dependent. while we actually move with v = 3. Impact on frequency domain The staircase approximation of linear behavior introduces many higher frequencies in the frequency domain.

Concatenation of multiple processing steps can strongly increase this type of artifacts. clipping) Figure 3. related to mono-disciplinary experts and multi-disciplinary design. image. For the human eye an artefact is visible between pixels that are mapped on a single grey value and neighboring pixels that are mapped on the next higher grey value. and system integration. This subset as its has been discussed here is highly technical.As example of discretization problems Figure 3.19: Example of Generic Smoothing Consideration An example of a pattern that builds further on this transformation chain is shown in Figure 3. Despite the low-pass characteristic of the later part of the chain artifacts might still be induced by the discontinuity. in real life technical patterns and organizational patterns are experienced concurrently. A solution for this discontinuity is to smooth the input function. However. This artefact is invisible if the natural noise is still present. has to be transformed into a grey value f (x) that is used to display the image on the screen.20 the career of an architect is shown with the repeated encounters Gerrit Muller Human Measure and architecting January 22. Note that most analog and mechanical systems are already natural low-pass filters. Again this is an example of a pattern that is universally applied in multiple domains. The example showed a small subset of patterns that an architect experiences.18 shows a typical image quality problem that popped up during the integration phase of a Medical Imaging Workstation. Physical systems in general start to show artifacts with discontinuous inputs. For example in the trapezoid example also a number of organizational patterns pop up. Due to discretization of the pixel values to 8 bits false contours become visible. These remaining artifacts can be further removed by using an explicit low-pass filter in the high level software model. discontinuity in first derivative smooth smooth curves prevent artefacts (vibration. In Figure 3. then the acceleration jumps at the break-point. It is the levelling effect caused by the discretization that becomes visible as false contour. The linear approximation used in the trapezoid pattern has a discontinuity in the derivative. 2010 version: 1. For example.19.2 Embedded Systems Institute page: 45 . for instance by a low-pass filter. corresponding to the amount of X-ray dose received in the detector. The pixel value x. if we control velocity.

Potential problem areas are identified and design issues are weighted very fast. All these patterns form a frame of reference for the architect as an individual. 2010 version: 1.2 Embedded Systems Institute page: 46 . Gerrit Muller Human Measure and architecting January 22.20: Architects Collect a Rich Set of Patterns of patterns in different products and in different environments. This frame of reference helps the architect to assess new architectures very quickly. thanks to this frame of reference. We estimate that an experiences architect encounters (and files and uses) thousands of patterns.time architects move from: product to product environment to environment architects experience: thousands of patterns design patterns in systems process patterns in environments human patterns in environments legend environment system design pattern process pattern human pattern Figure 3.

plan Product roadmap material presales sales logistics production service Customer Oriented Process Product related processes Technology. Process and People roadmaps Technical Product Documentation Requirements and Feedback $$ Product Creation Process People Technology Process People and Technology Management Process Figure 3.2 Embedded Systems Institute People Technology Process Budgets page: 47 .3. All other processes only spend money. The function of the 4 main processes is: Customer Oriented Process This process performs in repetitive mode all direct interaction with the customer.21.6 Environment The business process for an organization which creates and builds systems consisting of hardware and software can be decomposed in 4 main processes as shown in figure 3. Product Creation Process This Process feeds the Customer Oriented Process with new products. customer Information Customer Roadmap Business Drivers Support $$ Product Order Product Requirements and feedback Policy and Planning Process Budget. This primary process is the cash flow generating part of the enterprise. This process ensures the continuity of the enterprise by creating products which enables the primary process to generate cash flow tomorrow as well. Gerrit Muller Human Measure and architecting January 22. 2010 version: 1. This process decomposition model is more extensively discussed in[9]. People and Technology Management Process Here the main assets of the company are managed: the know how and skills residing in people.21: Simplified decomposition of the Business The decomposition in 4 main processes leaves out all connecting supporting and other processes.

For the medium term these roadmaps are transformed in budgets and plans. not constrained by short term goals. These roadmaps give direction to the Product Creation Process and the People and Technology Management Process.22: Line Organization Stovepipe The challenge for companies is to organize themselves in a way that support these 4 different types of processes.22. see Figure 3.23: Business Organization Stovepipe The Product Creation Process maps often on a business oriented project organi- Gerrit Muller Human Measure and architecting January 22. business unit 1 project 1 project 2 project 3 project 4 product/market oriented business unit 2 product/market oriented Figure 3. Rather common is that the People and Technology Management Process is mapped on the line organization. 2010 version: 1. it is defining the future direction of the company by means of roadmaps. This figure also shows a common problem of hierarchical organization structures: the organizational entities become (over)specialized stovepipes.Policy and Planning Process This process is future oriented. which are committal for all stakeholders.2 customer support Embedded Systems Institute manufacturing purchasing marketing logistics sales page: 48 . CEO finance & administration goods flow human resource management commercial research & engineering mechanical engineering electrical engineering software engineering Figure 3.

where the two types of organizations have different concerns. The System Architecture Process bridges the Policy and Planning Process and the Product Creation Process. re-use driven long term project 1 project 2 electrical engineering software engineering purchasing customer oriented result driven short term project 3 project 4 Figure 3. It shows the relations between products. although the stovepipes are now in the product/market direction. or introvert d co omi mp na lem ting en sto tar ve y c pip ult e ure s? competence. as shown in Figure 3. but an introvert perspective. The business organization is customer oriented and result driven. 2010 version: 1.2 Embedded Systems Institute customer support extrovert manufacturing logistics mechanical engineering marketing sales page: 49 . The line organization is competence and skill oriented. skill oriented synergy. looking for synergy and re-use opportunities. It relates products and technology to the (long lead) development of people and process The System Architecture Process is the process that: • Gathers input for the Policy and Planning Process • Brings in technical overview and common sense in the Policy and Planning Process and the Product Creation Process • Transfers the intention of the Policy and Planning Process into the Product Creation Process Gerrit Muller Human Measure and architecting January 22. such as re-use of technology.23.25 positions the System Architecture Process in the simplified process decomposition. The line organization typically has a long term focus. but an extrovert perspective.zation. The stovepipe problem is here also present. The business organization typically has a short term focus. Figure 3. It positions the product in the technology life-cycle.24: Different Concerns The combination of both organization models results in a matrix organization. The roadmaps made in the policy and planning process are the shared understanding of direction of the company: • • • • It positions the products in the market and within the product portfolio.

The natural growth direction in this environment is specialization. Vi sion Product Creation Process People Technology Process s Con Figure 3. cost of Gerrit Muller Human Measure and architecting January 22. we have seen organizations where customer key drivers. such as conflicting interests and complementing (or opposing?) characters. In some organizations the security or standardization efforts hurt the architecting effectiveness. 2010 version: 1. Process and People roadmaps Arch itec . Specification. A complex environment that is full of human factors. integrity and balance. systems engineering as discipline job rotation stimulate architect exposure stretch all engineers cultivate customer & market oriented culture share and invest in future exploration and vision Figure 3.2 text People and Technology Management Process Embedded Systems Institute People Technology Process ture Budgets Pro ces St a Technical int keho era Productlde cti on r Documentation Requirements and Feedback Sys tem $$ page: 50 . Design and Verification • Maintains the consistency.26: What Can We Do to Improve the Environment? Until now we have sketched the organizational and process environment in which the system architect operates.25: Positioning System Architecting • Performs the system level Requirement analysis. For example.customer Information Customer Roadmap Business Drivers Support $$ Product Order Product Requirements Rea and feedback lity che ck Policy and Planning Process Budget. plan Product roadmap material presales sales logistics production service Customer Oriented Process Product related processes Technology.

Organizational ownership for systems engineering as a discipline counter-balances the natural tendency towards specialization. The extremely challenging job of a system architect becomes somewhat more feasible if the engineers are at least systemaware. Most organizations have a severe lack of systems engineers and systems architects. Systems engineering as discipline Conventional disciplines are technology oriented.2 Embedded Systems Institute page: 51 . systems engineering has grown into a discipline itself. it is a prerequisite to become systems engineer Stimulate architect exposure to help them overcome their introvert nature and to help them bridge the gap between managers and architects. The cultivation of a systems attitude requires such a broadening. The gap as described in Figure 3. Some investment is needed to create a vision and to keep the vision up-to-date. electrical. cultivate customer and market oriented culture Especially in large organizations the distance from local organizational concerns to customers and market can become large. A vision becomes much more powerful if it is shared throughout the organization. share and invest in future exploration and vision Good architects base their work on a vision. System architects suffer tremendously from introvert organizations. 2010 version: 1. and market roadmaps are marketing confidential. stretch all engineers The broadening mentioned before should not be limited to (potential) system architects. for instance: mechanical.26 shows what we can do to improve the environment from system architecting perspective. and software engineering. Gerrit Muller Human Measure and architecting January 22.8 is here imposed by the organization. Figure 3. However.ownership models. because the architect has to connect the customer and market needs to technological decisions. Job rotation is one of the means to broaden employees.

Without the ability to quickly determine value. Environment : stimulate job rotation expose engineers recognize multi-disciplinary Customer objectives Application Functional Conceptual Realisation Experience : >1000 design patterns and process patterns Education : How to educate. This process can be supported by explicit reflection. relate and weight issues. relevance and criticality. for instance triggered by a mentor or intervision by peers. • Environmental issues.3. Such a frame of reference helps to position. • System architecting education for people that do not fit in this architect profile is. 2010 version: 1. • A frame of reference grows over time and is the result of experience. • Architects need to be stimulated and supported to break through roadblocks imposed by the environment. stimulate depth and breadth? Nature : Foster engineers with architect potential Figure 3.27: Conclusion Figure 3.2 Embedded Systems Institute page: 52 . nevertheless. designers drown in the practical infinite space of problems and solutions. a good investment. such as organization and processes. Analysis of the critical success factors for system architects provides us with the following insights: • Only a limited set of technical educated people have a personality profile (the nature component) that fits with the architecting role. and to identify risks.7 Discussion and Conclusions This paper was triggered by the not yet satisfactory results of our newly developed MOSAD course. • To integrate and use multi-disciplinary design techniques a broad frame of reference is needed. have a big impact on the effectiveness of architects.27 summarizes the conclusions: Education How do we stimulate and educate breadth and depth synthesis? Gerrit Muller Human Measure and architecting January 22. System aware designers ease the job of the system architect.

8 Acknowledgements Louis Stroucken detected a painful copy-paste error and provided other useful feedback. Good architects have a very rich frame of reference with thousands of patterns. Environment has a big impact on architect effectiveness. rewarding system) must recognize the value of multi-disciplinary design.3 Embedded Systems Institute page: 53 . 2010 version: 1. Stimulation of job rotation helps to enrich the frame of reference. Experience plays a very critical role in cultivating architects.Nature People with architecting genes are scarce. We have to foster and stimulate those people that fit in the architecting profile. By exposing engineers to multi-disciplinary aspects the awareness for system issues increases The environment (management. 3. Gerrit Muller Human Measure and architecting January 22.

Figure 7. .2.1 shows a multiple choice set of feelings for programming the well known Video Cassette Recorder (VCR) or its later successor the Personal Video Recorder (PVR).Chapter 4 Architecting for Humans.1 Introduction Many modern appliances cause an alienated feeling for (less-technical) consumers. How to Transfer Experience? To create an User Experience A Design Experience is needed architect project leader engineers B Success requires feedback C D Experience is not predictable and never garantueed 4. This product creation cycle is shown in figure 7.1: Did you ever program a Video Recorder (VCR or PVR)? A long lasting process is performed to come from some consumer need to a manufacturable. A depressed B desparate hysteric C Figure 4. salable product. This task of programming the VCR is often delegated to the family member with sufficient technical feeling.

The final result of the engineering effort is a ”product documentation”. et cetera. which is used by manufacturing to produce the product and by sales to sell the product. opinions. Gerrit Muller Human Measure and architecting January 22. architect and project leader. consisting of engineers. to design a product. 2010 version: 1. The experience of the human using a new product. which is to bridged by an architecting effort.2: Product Creation Cycle The word ”experience” in the title of this article is used in a double meaning: • the feelings and emotions an user experiences when using the system • the accumulated skills and know-how of working many years in the domain Both concepts of experience share the difficulty or in fact impossibility of transferring experience from one human to the next. resulting from an engineering activity. feelings. Figure 4. is determined by emotions. Factory Retailer or Provider Product User Architect Product manager Project Leader product documentation Engineers design Figure 4. Figure 7.It starts with a product manager.3 Embedded Systems Institute page: 55 . who perceives a product opportunity as a need from the user. Via the retail channels the product finally arrives at the consumer.3 visualizes these 2 forms of experience. At the other hand engineering a product from available technologies is in many aspects a very SMART activity. which are used by a development team. See also [10] for a further discussion on the relation between ”fuzzy” user needs and SMART engineering.3 visualizes the gap between the user experience and the engineering world. The product manager formulates the product requirements.

Definition Technology requires Verification Engineering Figure 4.3 Embedded Systems Institute page: 56 . smell.3: 2 Levels of Experience Sense.4: Bridging the gap between Experience and Engineering Gerrit Muller Human Measure and architecting January 22. 2010 version: 1. Opinions Experience From Fuzzy to SMART Appliances Architecting Analysis.User For Whom What er Us ence ri xpe E Product Architect Product manager By Whom How tion rea ience C r pe Ex Project Leader Engineers Product Creation Process product documentation design Figure 4. feel Humans use Devices have Emotions.

1 shows a number of construction limits.3 Embedded Systems Institute page: 57 . In order to be able to resume the viewing of the movie he pauses the viewing. 2010 version: 1.6.4. which is broadcasted via conventional means. but also more extensive user stories. Sometime later he resumes viewing where he left of.1: Construction limits intrude in Experience Construction limits. show how the intrinsic simple model can detoriate into a more complex interaction model. Gerrit Muller Human Measure and architecting January 22. Table 4. Figure 8. see figure 4.2 User Experience As an example of user experience Time shift recording is used. while in the background the recording of the not yet finished movie continues. which are relevant for the external behavior of the appliance. In this example the user is watching a movie.5: Example Time Shift recording In this simple form (pause/resume) this function provides freedom of time to the user. However when such an appliance is designed limits out of the construction world pop up. After some time he is interrupted by the telephone. Interference of different user inputs and interference of appliance limitations compromise the simplicity of the interaction model. which starts invisible the recording of the remainder of the movie. 20:00 start movie 21:00 broadcast record view play 22:00 end movie 23:00 talk view phone rings pause viewing finish conversation resume viewing Figure 4. • • • • number of tuners number of simultaneous streams (recording and playing) amount of available storage management strategy of storage space Table 4.9 shows the concurrent activities that occur when straightforward time shifting is used. This appears to be very attractive in this interaction modus. which intrude in the user experience.

see figure 4.6: What if? The story behind figure 4. nor did it help to identify the critical or difficult issues. preferences and physical status. the students have to design such a time shift appliance. In the Post doctoral education for computer science designers at the technical university Eindhoven.3 Embedded Systems Institute page: 58 . walks in the room and zaps to CNN. This thick stack of paper did not really help the students to understand the essence of the appliance. is watching the latest Meryl Streep movie on television. ranging from environmental factors. Five minutes later dad. which immediately surfaced a number of critical issues and enabled discussion and feedback on the user interaction model. In the function of ”requirement expert” I was involved in this design workshop.20:00 start movie 21:00 broadcast 22:00 end movie 23:00 1. After challenging them the students build a functioning prototype on a PC. such as social status.6 is that Sharon. At 9 o’clock a recording should start of a soap series. The initial effort of the students was heavily focused on creating a requirement specification. This wide variation of influencing Gerrit Muller Human Measure and architecting January 22. very long phone call finish conversation resume viewing Figure 4. to watch the latest developments. Sharon pauses the movie and talks extensively with her sister. such as education. full with tables defining requirements. Bob. Most Personal Video Recorders have only one tuner and will therefor not support the three persons satisfactory. programmed recording of other station record view play talk view play phone rings pause viewing 3. The big questions in this story is: What is recorded when? and Who is able to watch the desired content later this evening?. 9:15 Sharon says her sister good bye and presses resume to continue with her Meryl Streep movie. 2010 version: 1.7. The user experience is influenced by many factors. programmed by daughter Brigit. location and time to personal factors. This entertainment is interrupted by a phone call from her sister. Dad zaps 2. mother of 15-year old Brigit.

Figure 4.1. Although the infinite size of the experience space might suggest the impossibility to design good products.1. A consequence of all factors which determine the user experience is that the experience space is in practice infinitely large.1.1 Real-time data requirements 2.3 Non-real time data requirements 1.2.1.9 shows for only a few influence factor the size explosion of this experience space.1.3.Visual Basic Prototype: enables "experiencing" Requirements specification Many tables.2. during watching of this title play pause record EPG 1.8: Factors influencing the User Experience The challenge is to make the user experience more tangible.2.1.1 User must be able to pause and unpause a title.1.7: OOTI workshop 2001 factors is shown in figure 4. Table 4.1.3 Embedded Systems Institute page: 59 . from HDD. it is not that bad: Gerrit Muller Human Measure and architecting January 22.1. for instance by ”SMART”ening the experience.1 Access to the non-real-time data must be done in such a way that it does not interfere with the realtime data 1.1 Software Requirements Real-time data requirements 1.1 1. time and date of registration) Figure 4.1. played from HDD.1.1.3.3 Responsiveness for non real-time data is less then 150ms (the time for writing a block on HDD) for 2KB of non-video data 1.3 Names of titles should be derived from the information from the EPG (name of the program to be recorded.1.3 Non-real time data requirements 1. 2010 version: 1.1. mostly addressing details 2.1.2 User can jump forward and backward in a title.8.1 Management of HDD content must only be possible through the TOC in order to prevent unauthorized access to content of HDD 1.1.2 indicates what we would like to do with a ”SMART”ened experience. while (s)he is watching it 1.1.2 Visual feedback is provided to the user via OnScreen Display 1. The size of this experience space is the product of all users and all values that every influencing factor can have. environmental factors personal factors social status relation family education mental status trauma emotional status group influence fashion physical status allergy handicap culture taboo cultural religion location time taboo preferences taste Figure 4.1.2 There must be no disruptions in output of video signal during the operation of VCR 1.3 User input is provided via the RC 1.2 Implementation detail 1.3.2 Implementation detail 2.

Number of People on earth Human lifespan in seconds Square meters of planet earth . Gerrit Muller Human Measure and architecting January 22.9: Infinite Experience Space It is not that bad :-) Many nice and successful products exist! One of the important means to achieve successfully products is the abundant use of feedback... Figure 4.10 shows some important aspects of obtaining feedback. use short development cycles and observe and listen to users.. O(10 9) * O(10 9) * O(10 14 ) * . 2010 version: 1. get architects and designers out of the development laboratory.2: How to ”SMART”en Experience? People Time Location ..3 Embedded Systems Institute page: 60 ... Size of experience space Figure 4.• • • • define measure predict verify Table 4.

2010 version: 1.10: Key Success Factor: Feedback Gerrit Muller Human Measure and architecting January 22.Obtain feedback from real users: .Observe .3 Embedded Systems Institute page: 61 .Use short development cycles Don't stay in the development lab Figure 4.Experiment .(Dare to) Listen .

• • • • • • Programming languages Operating systems Algorithms Data structures Formal specification and verification techniques Analysis.3 Embedded Systems Institute page: 62 .3: Engineers are educated in construction disciplines Product Creation is much more than engineering only. where creativity is based on diverse sources as intuition.4. Figure 4. which enables the engineers to re-use methods. trial and error et cetera.11: The world of the construction The engineers are educated in construction disciplines: how to apply technologies to realize a solution which fits the specified requirements. lateral thinking. Gerrit Muller Human Measure and architecting January 22. Engineering is an important part of product creation. Table 4. Product oriented Means oriented Application software Compilers Methods Domain specific sw Domain hardware Operating system Other SW tools Procedures Computing hardware Case Tools Figure 4. while the creativity is developed (and should be latent available) mostly by experience. The engineering know-how can be teached in courses.12 for more detail).3 shows some of the disciplines in the education of an engineer.3 Engineering The world of engineering and construction is full of tcechnologies and tools. simulation techniques Table 4. However on top of engineering also creativity is needed. tools et cetera (see figure 4. 2010 version: 1.11 shows some commonly used elements of this world.

2010 version: 1.12: Product Creation is much more than Engineering Gerrit Muller Human Measure and architecting January 22.Product Creation = Engineering Known: Facts Notations Methods Tools Patterns + Creativity Intuition Observation Trial and error Lateral thinking Collection of references Education Experience Figure 4.3 Embedded Systems Institute page: 63 .

then into apprenticeship and finally it becomes peer coaching. reading and interacting and listening. see figure 4.3 Embedded Systems Institute page: 64 .13: Educational Material per education stage Figure 4. Available educational material K ind a erg rte n ry nta me ool Ele sch ty h rsi Hig ool ive Un ch s job the g On ainin tr ic list n Ho ectio rf pe Figure 4. 2010 version: 1.14.4. The doing during school and university is mostly practising by making exercises. Gerrit Muller Human Measure and architecting January 22. Do Exercise Practical training apprenticeship Seminars Workshops Conferences Magazines Journals time Peer coaching Interact and Listen Lectures: Explain Show examples Handbook Course material Read Figure 4.13 shows that for education at schools and universities quite a lot of educational material is available. However the more advanced education becomes the less material is available.14: Changing Education model in time The education can be decomposed in 3 types of learning: doing.4 Education The understanding that product creation is a combination of engineering and creativity helps to formulate an educational curriculum for architects and designers. this evolves into practical training. This figure also shows that the contents for these categories changes over time.

well organized. no well organized curriculum exists anymore.4: Prerequisites for continuous successfull product creation Table 4. Both the manager as well as the employee should be aware of the need for further personal development.3 Embedded Systems Institute page: 65 . workshops. Do Exercise Practical training apprenticeship Seminars Workshops Conferences Magazines Journals Peer coaching Interact and Listen Lectures: Explain Show examples Handbook Course material Read time highly organized well specified small scope few (if any) stakeholders initiative required uncertainty rules large scope many stakeholders Figure 4. • • • • Awareness of engineers of human aspects Active personal development drive of engineers Awareness of managers of education models Active motivation by managers Table 4.15 annotates the education lifecycle with the characteristics.4 shows the prerequisites to be successfull in product creation on a continuous basis. In the later stages the initiative for further education should come from the employee itself. where the manager should stimulate and the engineer should have a personal drive.The interacting and listening and reading evolve from a preprogrammed fashion at school and university into a selection of seminars. The early lifecycle is characterized by a limited scope.15: Increasing Initiative required Figure 4. 2010 version: 1. At the later stages the characteristics are more or less the opposite: a large scope full of uncertainty and with many stakeholders. Gerrit Muller Human Measure and architecting January 22. well specified subjects and involvement of a few (if any at all) stakeholders. magazines et cetera.

feedback and peer coaching. Using methods derived from design experience and applying lots of feedback increases the chance on success. To create an User Experience A Design Experience is needed architect project leader engineers B Success requires feedback C D Experience is not predictable and never garantueed Figure 4. This requires a lot of practical training. Gerrit Muller Human Measure and architecting January 22.16 and 4.17: Experience Transfer Design experience itself is not tranferable.5 Conclusion Figures 4. nor is it possible to guarantee an experience. by means of on the job training.17 summarize the article. 2010 version: 1. Later on this engineer must continue his personal development.4.16: Architecting for Humans User experience is never predictable.3 Embedded Systems Institute page: 66 . education is a means which can enable in potential good engineers to build up experience faster. Design experience is not transferable education is no substitute Regular education = Transfer of Engineering methods + Training Transfer is approximated by personal development Personal Development = On the job training + feedback + continuous personal education Figure 4.

6 Acknowledgements Daniel Malacarne provided feedback on a number of figures. Gerrit Muller Human Measure and architecting January 22.4. 2010 version: 1.4 Embedded Systems Institute page: 67 .

Chapter 5

From the soft and fuzzy context to SMART engineering
Home Server Network Providers Service Providers Content Providers

Appliance

User

5.1

Introduction

Engineering education and process improvement actions always stress the importance of ”SMART”ness of requirements. Table 5.1 shows the meaning of SMART. The original use of this acronym was by George T. Doran, in an article about management goals and objectives [4]. Today the acronym is mostly used to stress the specificity and measurability, the ”ART” part is used in many variations as shown in this list. • Specific • Measurable • Assignable (Achievable, Attainable, Action oriented, Acceptable, Agreedupon, Accountable) • Realistic (Relevant, Result-Oriented) • Time-related (Timely, Time-bound, Tangible, Traceable) Table 5.1: The meaning of SMART It is a sound advice to write product specifications with the SMART acronym in mind, every violation is a potential problem. However it is also important to try

to capture and communicate the understanding on which these smartened specifications are based. This understanding often deals with much more fuzzy issues. By following one example it is shown which fuzzy inputs are provided in the beginning, what the different stakeholder needs are and how these inputs can be transformed into more SMART specifications.

Gerrit Muller Human Measure and architecting
January 22, 2010 version: 1.4

Embedded Systems Institute

page: 69

5.2

Case description

Figure 5.1 shows the type of products used as an example: a Mobile Display Appliance and Mediascreen. The function of these products can vary from portable television to home control to web browser et cetera.

Mobile Display Appliance

Mediascreen
Original pictures from Nokia

Figure 5.1: What are the requirements for these products? Characteristic of these kind of products is that the functionality is typical a function of the appliance itself plus functions and content provided by the context. Figure 5.2 shows the total chain of systems which can be involved in the functionality.

Home Server

Network Providers

Service Providers

Content Providers

Appliance

User

Figure 5.2: User access point to long food-chain The architect of this appliance will receive many fuzzy expectations as inputs and for some parts he will get SMART descriptions. Figure 5.3 shows the fuzzy input as clouds and the SMART input as rectangles. Clearly a significant amount of fuzzy input is provided.

Gerrit Muller Human Measure and architecting
January 22, 2010 version: 1.4

Embedded Systems Institute

page: 70

4 Embedded Systems Institute page: 71 .3: ”Fuzzy expectations” and ”SMART descriptions” Gerrit Muller Human Measure and architecting January 22. 2010 version: 1.User Experience Appliance Specification and Design Standards Stakeholder interests Heterogeneous Implementations Context: social cultural mental etcetera Home Server Network Providers Service Providers Content Providers Appliance User Figure 5.

5 shows the problem statement by visualizing all the fuzzy needs at the one hand and the SMART facts at the other hand. Finally the sales channels sell the systems and deliver the systems to the customers.3 Why SMART? The supply chain stakeholders of the design process are shown in figure 5. To make this relationship work it is important that the integrator has know-how and understanding of the supplier and vice versa. Figure 5. Retailers Sales. which often causes redundant specifications at the interface (one from the integrator point of view and one from the supplier point of view). Service Manual Catalog Brochure Product Creation: Order Realization: user Networking Service Content Providers Decomposition and Integration Ordering and Assembly Subsystem Subsystem Subsystem Specification Design TPD Partnering Subcontracting Outsourcing Component Component Component Figure 5.4. as shown in figure 5.6 sharpens the problem statement by showing the fuzzy elements playing mostly in a creative world (imagination) and the formalizations often used to make things work in a supply chain environment. (Did you ever try to tell a sales manager: ”don’t worry the product will be fast. The final formalization is laid down in a contract. to prevent problems. Often outsourcing or purchasing processes are highly formalized.8.5. Figure 5. test and sell the product. Later during manufacturing the components and subsystems are ordered from suppliers and assembled into a system. 2010 version: 1. assemble.4: Supply Chain Stakeholders All the stakeholders involved in this supply chain need specific and verifiable data to order. will have a nice image quality and it will be very fashionable”. One very specific stakeholder is the supplier.7 shows this relationship.4 Embedded Systems Institute page: 72 . without any further hard facts?) Figure 5. The product Creation Process takes care of the decomposition of the system in subsystems and components as well as the integration and test of the system. The decomposition and integration of the system requires SMART data at Gerrit Muller Human Measure and architecting January 22.

9 shows the functions in both processes. 2010 version: 1. both for product creation as well as for the supply chain.5: Problem Statement all aggregation levels. Gerrit Muller Human Measure and architecting January 22. where SMART data are important.User Experience Context: social cultural mental etcetera User Standards Stakeholder interests Commercial concept from to Fuzzy SMART architecting Product Creation Marketing Sales Service Order Realization Heterogeneous Implementations Network Providers Network Providers Service Providers Content Providers Service Providers Content Providers Figure 5. Figure 5.4 Embedded Systems Institute page: 73 .

4 Embedded Systems Institute page: 74 .7: Theory: Subcontractors require SMART relation Gerrit Muller Human Measure and architecting January 22.User Experience Specifications Project management Context: social cultural mental etcetera Commercial concept Processes Procedures from Fuzzy to SMART Contracts TPD Stakeholder interests Quality Control Audits Certification Legislation Figure 5.6: Problem (2): From Imagination to Formalization Integrator Supplier System design Subsystem Specification Design Flow "System" Specification "System" design level of know how and understanding Integrator Shared Knowhow and Understanding Supplier design depth Figure 5. 2010 version: 1.

4 Embedded Systems Institute page: 75 . Why SMART is needed Gerrit Muller Human Measure and architecting January 22.8: Critical Success Factor: Mutual understanding Product Creation Decomposition and Integration System Order Realization Specify Design Engineer Build Validate Verify Transfer Integrate Order SubSystem SubSystem SubSystem Assembly Adjust Test Component Component Component Component Component Component Figure 5.9: Views on Aggregation.Integrator intangible informal Intention based on Mutual Understanding Supplier System and Context Understanding System and Context Understanding System design Subsystem Specification Design Flow "System" Specification "System" design tangible formal Contract acceptance procedure acceptance test Subsystem in Integrator perspective = "System" in Supplier perspective Figure 5. 2010 version: 1.

However the qualified needs do provide insight in the motivation of users and in that way are useful to help others to obtain a better understanding.11 shows in the same way the fuzzy needs of the providers and the retailers. light) Non Obstrusive Robust Attractive content Responsive Crisp images Fluent dynamic images Realistic sound Context: social cultural mental etcetera Home Server Network Providers Service Providers Content Providers Appliance Good Performing: User Affordable (integral!) Figure 5.5. which are also stakeholders of these products. Systems are decomposed and interfaces are defined in SMART terms.11: The ”Fuzzy” needs of the Provider The world of the designers is much less fuzzy. As shown in this figure none of these requirements is specific nor measurable et cetera.12 shows the decomposition for this kind of product.4 Embedded Systems Institute page: 76 .10. is it a TV or a PC?) Appealing product Figure 5. Gerrit Muller Human Measure and architecting January 22.10: The ”Fuzzy” needs of the User Figure 5. Figure 5. Food Chain User Experience Appliance Specification and Design Standards Heterogeneous Implementations Stakeholder interests Context: social cultural mental etcetera Home Server Network Providers Service Providers Content Providers Appliance User Providers: Retailers Sales. Service Networkin g Service Content Providers Manual Catalog Brochure Product Creation: Order Realization: Ensure payment Freedom of commercial packaging Accessibility of wide range of customers user Retailers: Ordering and Assembly Decomposition and Integration Subsystem Subsystem Subsystem Specification Design Partnering Subcontracting Outsourcing TPD Supply Chain Component Component Component Clear product category (on which shelf does this product belong.4 Examples of smartening fuzzy requirements The user or consumer needs are shown in figure 5. 2010 version: 1. Fashionable Usable: Appliance Specification and Design User Experience Standards Heterogeneous Implementations Stakeholder interests Easy to use Portable (small.

4 Embedded Systems Institute page: 77 . Philips Semiconductors. 2010 version: 1.13 shows the decomposition annotated with specification items. Note that the top part of the budget is well defined and in control of the appliance designer. The designer of the appliance need to make assumptions about the context in order to make a good design. and the answer travels in the opposite way.12: The ”SMART” world of the Design In such a decomposition many specification items can be defined.Standard Interactive System Applications Data transport Security Virtual Machine Display and UI free after Nick Thorne. Such a model can be calibrated by measuring the context for as far as it exists already. figure 5.14 shows an (academic) budget for this response time. however the lower levels of the budget are assumptions made by the appliance designer about the context. Footprint Applications Servers & Networks Throughput Latency Distance Power Data transport Security Level Performance Encryption Authentication Security Display size Color depth Rendering Performance IQ UI modi Display and UI Virtual Machine Functionality Performance Power. as presented at PSAVAT April 2001 Figure 5.13: Specifiable characteristics All functions in the chain contribute to the response time. Systems Laboratory Southampton UK. Standard Interactive System Functionality Performance Power. Figure 5. Footprint Figure 5. The wider the context becomes the more uncertainty will be present in the numbers. Also a typical flow is shown for some user interaction: some request enters via the user interface. As an example we will have a look at the performance in terms of the response time. Gerrit Muller Human Measure and architecting January 22. Reality is infinitely complex due to the possible variations in the food chain and the dynamics (changes over time). However the designer should stay aware (as with all of his models) that this model is a tremendous simplification of reality. flows through al the blocks to the relevant service. These assumptions will be based on a model of the context.

Response Time (ms) 310 150 100 ctive Intera nce rie Expe Home Server ting Irrita ence eri Exp Network Providers Service Providers Content Providers Appliance User Figure 5. less than 200 ms). This insight will influence a lot of specification and design decisions. maybe supported by all kind of clever tricks such as look ahead.15 the model indicates good response times for functionality which stays within the appliance. bright.e. smooth moving) image quality.15: Interaction or Irritation? A different area of fuzzy needs is image quality. some local solution is required. caching et cetera.4 Embedded Systems Institute All numbers are imaginary and for illustration purposes only page: 78 . For all functions which require true interactive responses (i.times in milliseconds Appliance Data transport Security Virtual Machine Application Graphics and UI Message Latency 40 10 10 10 10 0 Response Time 100 20 20 20 30 10 Home Network Provider Infrastructure Last-Mile network Backbone network Service server Content server Home Server Network contention 10 10 10 20 10 10 20 50 30 20 20 40 50 50 50 160 Total User need 110 310 200 Figure 5. but poor response times for functions which need interaction with far away servers. The user needs good (sharp. As shown in figure 5. 2010 version: 1.14: Response Time: Latency Budget One of the important characteristics for the user of the appliance is the response time. The verifiable image quality is often based Gerrit Muller Human Measure and architecting January 22.

16 visualizes these different types of needs. which requires all kinds of functions such as format. However some product functions can be created to make it possible to follow the fashion. download. or worse when taste comes into play (this image is too sharp. 2010 version: 1.4 Inspired by William van der Sterren Embedded Systems Institute page: 79 .5 mm Taste Perception Technical IQ Figure 5. for instance by enabling personalization. Fashionable Personalization Themes Specific Functionality Format Download Import Scale Figure 5. or eye brain d < 0.17 shows downloadable themes as example. while someone else finds it too smooth).17: Fashionable Gerrit Muller Human Measure and architecting January 22. Figure 5.on synthetic images. A well known example is the exchangeable front of GSM phones. scale et cetera. which enable verification for all technical parameters.16: Image Quality Fashion is also an intangible need of the user... Figure 5. However a perfect technical image quality does not mean a satisfied user. Some of the image quality aspects are even more fuzzy. for instance when perception is taken into account (color blind people!). import.

Confrontation with market and consumers: Good Enthusiasm Instant playing Relaxed usage Buying Bad Critical Stumbling Tension Wait and see Figure 5.5 How to verify? Verification of fuzzy requirements is difficult.18 shows that careful observation can be used to obtain insight in the level of fulfillment of the originating fuzzy requirement. 2010 version: 1.4 Embedded Systems Institute page: 80 . does not mean that the originating fuzzy requirement is also met.5. while SMART requirements are verifiable by definition. Gerrit Muller Human Measure and architecting January 22.18: From SMART to Fuzzy Figure 5. However the fact that a smartened requirements is fulfilled.

Only readers with sufficient a priori knowhow are able to reconstruct the richer understanding again. 2010 version: 1.19: Complementing views Gerrit Muller Human Measure and architecting January 22. The smartening process of requirements often significantly increases the understanding of the requirements.6 Conclusion ”Fuzzy” understanding of requirements and smartened descriptions of requirements are complementary. any description always flattens the rich understanding into a limited set of words and definition.5. Smart Fuzzy Figure 5. Unfortunately understanding itself is a non transferable concept.4 Embedded Systems Institute page: 81 . mostly due to the need to articulate everything explicit. where the author hopes to enable the readers to obtain the original understanding. The essential insights obtained in the requirements analysis are often captured in a few non-SMART statements.

and the need to understand the less tangible aspects at the other hand.7 Acknowledgements A long time ago Dieter Hammer send me a presentation explaining the SMART acronym. Tom Gilb and Lindsey Brodie helped me to trace back the origin of SMART. I thank them for their inspiration. Gerrit Muller Human Measure and architecting January 22.1 Embedded Systems Institute page: 82 . because I kept struggling with the need for being specific and measurable at the one hand. A vivid discussion with Thomas Gilb triggered this presentation.5. 2010 version: 0.

The product can be used to watch movies or other content anywhere anytime. but security is . Of course many more aspects are important for this type of product..1: Example product: mobile infotainment To make the example even more specific. the focus will be on security aspects.1 Introduction The communication aspect of architecting is discussed by means of an example product: mobile infotainment.Chapter 6 Communicating via CAFCR. Home Server Network Providers Service Providers Content Providers users infotainment appliance watch video browse photo's calendar and much more. Figure 6. or to browse and update a calender and many more applications.. illustrated by security example 6. This product is much more than only the tangible appliance: portable infotainment device. see figure 6. a long food chain to connect the appliance with the outside world is needed.1.

Gerrit Muller Human Measure and architecting January 22.especially interesting for communication due to the wide range of (often conflicting) concerns with respect to security. 2010 version: 0.1 Embedded Systems Institute page: 84 .

d. Meulen Clinton Boonstra Jones Schijvens Prodi Pinochet Peper Koch Kleisterlee Cruijf Kok El Khatabi Leonardo Peters Chirac v.3: Stakeholders and concerns Many stakeholders are involved in the creation of mobile infotainment. Although they use the Gerrit Muller Human Measure and architecting January 22.2. Sony. Hamer v. such as Philips Consumer Electronics. The food chain starts at the suppliers of components and platforms.d. Spijker Jansen de Gruijter de Vries Schweitzer d'Oliviera Muller Goedkoop Schroder Nistelrooij consumers Canal+ Fry's It's retailers infrastructure providers AT&T AOL EMI Virgin K3 Helmut Lotti content providers MGM Vivendi Sony content creators Rolling Abba Stones Steven Spielberg Dixon UPC Philips CE-TV Loewe Sony Nokia Philips CE-DN Ericsson system integrators Intel Microsoft Philips Components ST Micron Philips Semiconductors component and TI platform suppliersSamsung Liberate LG Figure 6.d. Nokia or Samsung.2: Value chain The producer of the appliance for mobile infotainment is part of a much larger value chain. Via a distribution chain of retailers and providers the appliance is delivered to a wide variety of consumers. These components are integrated by the appliance makers. see figure 6.2 Stakeholders Gore Waterreus Heijn Hoessein Gandhi Sharon Smith Rooyakkers van Oranje Reinders van Bommel Bakker Pietersen der Kinderen Obbink Neeskens van Hanegem Meulengraaf Bush Charite Blair v.6. All kinds of players in these chains are mutually dependent: without content no appliance. see figure 6. such as Philips Semiconductors. All of these stakeholders have multiple concerns.3.1 Embedded Systems Institute page: 85 . Symbian and many more. Intel. stakeholders culture government preservation liability security network providers content providers content creators maximize use pay for use concerns management economics logistics retailer operator accessibility infrastructure reliability maintenance crew entertainment ease of use consumers privacy Figure 6. 2010 version: 0. Complementary to this part of the value chain are an infrastructure value chain and content value chain. but also without appliances no content.

production. 2010 version: 0. customer (purchaser. logistics) PCP (project leader. marketing. operator. operational managers) customer oriented process (sales. suppliers) people and technology management process (capability managers. product manager. user. decision maker. Gerrit Muller Human Measure and architecting January 22. service. technology suppliers) Figure 6.3 shows predominantly the external stakeholders. every stakeholder has its own specific interest and view on such a concern. The internal stakeholders are supportive for the overall business goal. as modeled in figure 6. engineers.4: Internal stakeholders Figure 6. their organization to support such a new product is part of the creation of a new product.) company policy and planning (business..4..1 Embedded Systems Institute page: 86 . maintainer.same label for a given concern. but many (company) internal stakeholders are involved as well.

which includes (despite the name) also the non functional requirements. ”The customer” is a tremendous abstraction. looking at the problem from many different viewpoints. Figure 6. many subsequent models and methods don’t fit entirely in one single view. based on intention and context understanding) in combination with bottom up (constraint aware. where the justification and the needs are expressed in the customer side. Although the 5 views are presented here as sharp disjunct views. where the conceptual view is changing less in time than the fast changing realization (Moore’s law!). as shown in figure 6. Note that most of these people have different interests with respect to the system.6. know how based). while the technical solution side enables and support the customer side. drives. However in the end.5. justifies. Architects do this job by frequent viewpoint hopping. the model is a means to build up understanding.5. One of the starting points is the use of the Gerrit Muller Human Measure and architecting January 22. This in itself not a problem. supports What does Customer need in Product and Why? Customer What Customer How Product What Product How Customer objectives Application Functional Conceptual Realization Figure 6. sampling the problem and solution space in order to build up an understanding of the business. The model is used to provide a next level of reference models and methods [12]. In other words the views must be used concurrently. a consistent story must be available.7 shows an example of the people involved in a small company. identifying opportunities. 2010 version: 0. The how of the product is described in the conceptual and realization view.5: The ”CAFCR” model The job of the architect is to integrate these views in a consistent and balanced way. The 5 CAFCR views become more useful when the information in one view is used in relation with neighboring views.3 The ”CAFCR” model and qualities A useful top level decomposition of an architecture is provided by the so-called ”CAFCR” model. where multiple people are involved. The functional view describes the what of the product. The customer objectives view and the application view provide the why from the customer. while in many cases a player is a small company. not top down like the waterfall model. Top down (objective driven.1 Embedded Systems Institute page: 87 . it is not a goal in itself. see figure 7. needs enables. Many players are involved in the value chain.

The green (upper) issues are the desired characteristics. The task of the architect is to integrate all these viewpoints. An excellent illustration of the security example can be found in [5]. 2010 version: 0. The other people (non trusted) should not be able to see (or worse to alter) this information. in other words only a limited set of trusted people has access.What does Customer need in Product and Why? Customer Customer What How Customer Application objectives understanding Product What Functional intention Product How Conceptual objective driven Realisation context opportunities constraint know how awareness based Figure 6. 6.9 shows security issues for all the views. in order to get a valuable. stakeholder concerns. Customer objectives view One of the typical customer objective with respect to security is to keep sensitive information secure.8 shows the qualities as cross cutting needles through the CAFCR views. Many stakeholder concerns are abstracted in a large set of more generic qualities. These qualities are meaningful in every view in their own way.1 Embedded Systems Institute page: 88 .4 Zooming in on security As an example figure 6. Such a policy will involve classification of people with respect to need of information and trustfulness and classification of information with respect to the Gerrit Muller Human Measure and architecting January 22. The red issues are the threats with respect to security.6: Five viewpoints for an architecture. usable and feasible product. specifications and mechanisms. Application view The customer will perform many activities to obtain security: from selecting trustful people to appointing special guards and administrators who deploy a security policy. Figure 6.

A frequent threat for security is formed by unworkable procedures. Gerrit Muller Human Measure and architecting January 22.7: The abstracted customer Customer objectives Application Functional Conceptual Realization usability safety evolvability Figure 6. while the competition is listening at the next table. passwords and in the future additional biometrics. from burglary to fraud.8: The quality needles are generic integrating concepts through the 5 CAFCR views level of security. but also from simple issues like people forgetting their password and writing it on a yellow sticker. resulting in many people writing down the password. locks et cetera is also part of the customers security policy. Physical security by means of buildings. 2010 version: 0. For instance the forced change of passwords every month. for instance two managers discussing business in a business lounge. gates. To recognize trusted people authentication is required by means of badges.1 Embedded Systems Institute page: 89 . Social contacts of trusted people can unwillingly expose sensitive information. The security is threatened in many ways.CFO CMO CIO purchaser CEO CTO decision maker(s) Who is the customer? department head user CEO: Chief Executive Officer CFO: Chief Financial Officer CIO: Chief Information Officer CMO: Chief Marketing Officer CTO: Chief Technology Officer chain of retailers content provider maintainer network provider system integrator operator Figure 6.

for example cryptography. for instance the required confidence level of encryption or the speed of authentication. registry. where poor design easily threatens the security. For instance cryptography requires keys.Customer objectives sensitive information trusted Application selection classification people information badges passwords Functional functions for administration authentication intrusion detection logging Conceptual cryptography firewall security zones authentication registry logging Realization specific algorithms interfaces libraries servers storage protocols authentication locks / walls guards administrators quantification desired characteristics. specifications & mechanisms holes between concepts bugs buffer overflow non encrypted storage poor exception handling not trusted social contacts missing open passwords functionality blackmail wrong burglary quantification fraud unworkable procedures threats Figure 6. This threat will surface in the actual use. in this case for passenger screening at airports. where the users will find work around compromising the security with the work around. Every concept covers a limited set of aspects of security.1 Embedded Systems Institute page: 90 . Gerrit Muller Human Measure and architecting January 22. It describes a method for terrorists how to reverse engineer the procedures empirically. which shows how secret security procedures. Conceptual view Many techological concepts have been invented to make systems secure. Security threats are mostly caused by missing functionality or wrong quantification. Another risky issue is the transfer of keys. For instance cryptography makes stored or transmitted data non-interpretable for non trusted people. is more vulnerable. which turns the effectiveness of the system from valuable to dangerous.9: Example security through all views An interesting article is [2]. authentication. Problems in the conceptual view are mostly due to the non ideal combination of concepts. The interface between cryptography and authentication is a risky issue. The performance of the system needs to be expressed explicitly. 2010 version: 0. Functions for authentication and adminstration are required. Realization view The concepts are realized in hardware and software with specific algorithms. and logging. Functional view The system under consideration will have to fit in the customers security. All interfaces between the concepts are suspicious areas. Authentication is used to access and validate keys. firewalls. security zones.

10: Role of views Figure 6. running at specific clients and servers et cetera. Well known security related bugs are buffer overflow bugs.interfaces in specific libraries. Another example is storage of very critical security data. Only if sufficient understanding of the context is combined with good process and design competences an acceptable result can be obtained.1 Embedded Systems Institute page: 91 . in non encrypted form. A secure realization is far from trivial. Security conclusion Security is a quality which is heavily determined by the customers way of working (application view). Gerrit Muller Human Measure and architecting January 22. Customer objectives sensitive information trusted Application selection classification people information badges Functional functions for Conceptual cryptography firewall security zones authentication registry logging Realisation specific algorithms interfaces libraries servers storage protocols right decisions quantification administration authentication authentication passwords contextwalls locks / guards understanding administrators insight contacts social not trusted missing open passwords functionality blackmail wrong burglary quantification fraud unworkable procedures process and design bugs holes competence between concepts right questions buffer overflow non encrypted storage poor exception handling Figure 6. In general exception handling is a source of security threats in security. with the main purpose of illustration. A real security view will be more extensive than described here. Nearly all systems have bugs. which are exploited by hackers to gain access. Note that a very much simplified view on security is presented. Another common source of security problems is poor design and implementation. Every specific hardware and software element involved in the security concepts in itself must be secure. To enable a security policy of the customer a well designed and implemented system is required with security functionality fitting in this policy. such as passwords and encryption keys. causing a fair policy to be corrupted by the non secure system. In practice the security policy of customers is a large source of problems.10 visualize the reasoning with respect to security over the different views. 2010 version: 0. in order to have a secure system. Heavy security features in the system will never solve such a shortcoming.

to calibrate: repeat many times with different examples. illustrations and explanations B's context language B's incentives A's context language A's incentives - idea1 idea2' idea1" idea2" encoder decoder encoder decoder idea1' idea2 person A person B Figure 6.5 The wonder of communication idea to be expressed encoding based on emotional state relation with the other the objective the situation age. From technical point of view a pure miracle is happening in communication: sender and receiver use entirely different configured encoders and decoders and nevertheless we are able to convey messages to others. also based on many personal aspects of the receiver. 2010 version: 0. see figure 6.6.11: Active listening: the art of the receiver to decode the message If someone wants to transfer an idea to another person. gestures and voice modulation.1 Embedded Systems Institute page: 92 . then this idea is encoded in a message. The encoding of this message depends on many personal aspects of the speaker. The receiver of this message has to decode this message and makes his own interpretation.12: Intense interaction needed for mutual understanding The mechanism behind this miracle can be understood by extending the model Gerrit Muller Human Measure and architecting January 22. This message is encoded by a variety of means. status education cultural background own interpretation of idea decoding based on emotional state relation with the other the objective the situation age.11. status education cultural background rbal non-ve ge messa verbal ge messa from: "Listening and communicating" by Lia Muller and Willemien Figure 6. ranging from the verbal message to the non verbal message such as facial expression(s).

unified notations and all these kind of measures do not fundamentally address the communication difficulties explained here. as visualized in figure 6.13. The mutual understanding is built up in an interactive calibration process. 1 Gerrit Muller Human Measure and architecting January 22. Note that glossaries of terms. During interaction the mutual understanding improves.12. part of the coding depends on volatile issues. illustrations and explantions the coding and decoding information is calibrated. Problems or viewpoints which are more easily expressed in other terms are disallowed due to the unification obsession. Dogmatic applied unification of terms and notations work in my experience often counterproductive.1 Embedded Systems Institute page: 93 . while it degrades as long as no interaction takes place.of sender and receiver as in figure 6. such as mood. 2010 version: 0. level of mutual understanding time no interaction intense interaction intense interaction Figure 6. and context. In fact standardized terminology and notations are minor1 in comparison with the human differences which have to be bridged continuously. where active participation is required to obtain understanding that exceeds terms and notations.13: Mutual understanding as function of time The calibration information is very dynamic. By phrasing and rephrasing examples.

A story is a short single page story.14: Story telling method Figure 6. The story is used to get case data in the functional view. A good story combines a clear market vision with a priori realization know how. Gerrit Muller Human Measure and architecting January 22. The story itself must be expressed entirely in customer terms. All functions. The strength of the method is early focus on concrete actual problems and solutions.14 positions the story in the customer objectives view and application view.6.1 Embedded Systems Institute page: 94 . 2010 version: 0. What does Customer need in Product and Why? Product How Customer What Customer How Product What Customer objectives Application Functional Conceptual Realization market vision story a priori solution know how analyse design case analyse design design Figure 6. This case data is used to make a design exploration. for instance the appliance being used. it becomes time to determine useful generic concepts. performance figures and quality attributes are extracted from the story. no solution jargon is allowed. preferably illustrated with sketches of the most relevant elements of the story. Once sufficient factual specification and design depth is obtained.6 Story telling Story telling is a method to enable communication between people with different points of view. The method is a means to get discussions quickly a concrete and factual.

2010 version: 0. problems and solutions + Checklists per view + Reasoning top down and bottom up Figure 6. as shared reference.16: Summary Gerrit Muller Human Measure and architecting January 22. one of their most primary thoughts and the bad consequences if this thought is followed without taking other concerns into account. Figure 6.15: How do these stakeholders communicate? Figure 6.15 summarizes this by showing a small subset of stakeholders. enables: + Positioning of concerns. such as the mobile infotainment.7 Summary The previous chapters have shown that many stakeholders with many different concerns are involved.2 Embedded Systems Institute page: 95 . accessibility PHP only supports alphanumerical password 128 bit keys threat kill usability kill usability kill market kill usability security poor password protection no attention for key handling process Figure 6. consumer == pirate how to stay in control result in time. stakeholder consumer content provider Chief Financial Officer operational manager web engineer crypto engineer primary thought privacy DRM. is to communicate with many different stakeholders over many different subjects.16 summarizes the contribution of the ”CAFCR” model in the communication. Also is shown how difficult a bilateral communication is. The challenge of developing a complex product.6. What does Customer need in Product and Why? Product How Customer What Customer How Product What Customer objectives Application Functional Conceptual Realization CAFCR.

6.8

Acknowledgements

Henk Koning helped by providing inputs in the initial setup of the presentation. The definition of active listening and the diagram of bilateral communication are reused from a presentation given by my wife Lia Muller for her psycho-social study. Peter van den Hamer proposed several textual improvements.

Gerrit Muller Human Measure and architecting
January 22, 2010 version: 0.2

Embedded Systems Institute

page: 96

Chapter 7

Architect and Human Measure; the integration role
Factory Retailer or Provider

Product

User

Architect

Product manager

Project Leader product documentation

Engineers

design

7.1

Introduction

This article is written as part of a collective effort to write a book about ”ICT and the Human Measure”. It will become one chapter of this book, describing ”the role of the architect”. For that reason the problem statement is short and illustrative only.

7.2

Illustration of the problem
A

depressed

B

desparate hysteric

C

Figure 7.1: Did you ever program a VCR?

Many products have characteristics which are determined by technology push rather than user need. Take for instance most video recorders, which are often way too difficult to program for ordinary (non-technical) people. This is illustrated by figure 7.1.
Factory Retailer or Provider

Product

User

Architect

Product manager

Project Leader product documentation

Engineers

design

Figure 7.2: Product Creation Cycle One cause of this problem is the long chain of activities which results in a product, as shown in figure 7.2. This long chain of activities also involves many different stakeholders, ranging from potential customers, and product managers to development engineers and production personnel. A lot of the stakeholders ”live” in the engineering world, which addresses a lot technology concerns. The other end of the stakeholder chain, the human users, live in the real world, with many human concerns, such as emotions, feelings, perceptions et cetera. Figure 7.3 visualizes the gap between those stakeholders. Both figures 7.2 and 7.3 already hint at the crucial role played by the architect by architecting the solution.

Gerrit Muller Human Measure and architecting
January 22, 2010 version: 0.2

Embedded Systems Institute

page: 98

smell. Opinions Experience From Fuzzy to SMART Appliances Architecting Analysis. 2010 version: 0. feel Humans use Devices have Emotions. Definition Technology requires Verification Engineering Figure 7.2 Embedded Systems Institute page: 99 .Sense.3: Bridging the gap between Human Experience and Engineering Gerrit Muller Human Measure and architecting January 22.

identifying opportunities. sampling the problem and solution space in order to build up an understanding of the business. based on intention and context understanding) in combination with bottom up (constraint aware.5. Top down (objective driven. Gerrit Muller Human Measure and architecting January 22.7. as shown in figure 7. The job of the architect is to integrate these views in a consistent and balanced way. The functional view describes the what of the product. where the conceptual view is changing less in time than the fast changing realization (Moore’s law!). however the architect is responsible for the consistency and balance of why.2 Embedded Systems Institute page: 100 . looking at the problem from many different viewpoints. 2010 version: 0. The how is guided by the architecture. The customer objectives view and the application view provide the why from the customer. as shown in figure 7.3 What is architecting? Architecting in product creation spans from understanding the why. Or in even more popular terms: do the right things and do the things right Understanding Describing Guiding Why What How Do the right things Do the things right Figure 7.6 visualizes these 5 how views.4: Architecting visualized Architecting is a job which is done by all members of the product creation team. Architects do this job by frequent viewpoint hopping. what and how A useful top level decomposition of an architecture is provided by the socalled ”CAFCR” model. know how based). via describing the what to guiding the how. The how of the product is described in the conceptual and realization view.4. The how of the product is created by many specialists. At least 5 views are required for guidance: • • • • • functional decomposition construction decomposition allocation of functions to construction elements infrastructure integrating concepts Figure 7. which includes (despite the name) also the non functional requirements.

usable and feasible product. Infrastructure view audio play video TXT etc. 2. browse networking OS CPU Resource usage RAM etc Exception handling filesystem Device abstraction drivers frametuner buffer Performance scheduler MPEG DSP Construction Decomposition 5.5: Five viewpoints for an architecture. Choice of integrating concepts Figure 7. The task of the architect is to integrate all these viewpoints.2 Embedded Systems Institute page: 101 .What does Customer need in Product and Why? Customer Customer What How Customer Application objectives understanding Product What Functional intention Product How Conceptual objective driven Realisation context opportunities constraint know how awareness based Figure 7. Allocation acquisition compress decompress encoding storage display decoding Pipeline 4.6: Guiding how by providing five how-viewpoints Gerrit Muller Human Measure and architecting January 22. 2010 version: 0. Functional Decomposition 3. 1. in order to get a valuable.

2010 version: 0. Potential architects grow by stepwise broadening their scope. specification and design is owned by the architect. However the primary responsibility for the balance and consistency of requirements. it prevents the need for an impossible broad and heavy superarchitect. Most current architects have a dominant technical view on the world and should acquire more know-how from the customer world. The role of the architect is to (proactively) integrate the work of all the specialists.7 shows the architect meddling with the work performed by all teammembers. in order to obtain the balance and maintain the consistency. The intermediate roles are quite important in complex systems. This broad profile of the architect does not evolve automatically.8: Required architect know-how per view. This role requires sufficient know-how in the five views. see figure 7.9. Figure 7.2 Embedded Systems Institute specialist optics page: 102 .8.4 The architect meddling architect manufacturing application mechanics electronics marketing software service specialist specialist specialist specialist specialist specialist specialist team full of heroes Figure 7.7: The architect integrating all specialist teamplayers The architecting function is ideally performed by every teammember. see figure 7. Current Architects Required Architects l l n n er io ua na tio m s at pt tio to tive lica c s c lis ce n a p n cu je fu re ap co ob Figure 7.7. Gerrit Muller Human Measure and architecting January 22. typical for current architects and the preferred profile.

9: The architect maintains technical roots Gerrit Muller Human Measure and architecting January 22. 2010 version: 0.2 Embedded Systems Institute page: 103 .breadth of knowledge all-round specialist system architect aspect architect depth of knowledge specialist root knowledge Figure 7.

see also figure 8. 8.2 The Product: Building WDC Figure 8.2: • Understanding why • Defining what • Guiding how 1 Information and Software Technology .1 Introduction The formal opening of the new IST1 building of Philips Research provided an opportunity to compare architecting buildings and architecting electronic products.1 shows the new IST building. the building as a product WDC 8. Architecting a product involves 3 major phases. which is the product of a significant architecting effort. Many IST people are involved in architecting electronic products.Chapter 8 Architecture.

WDC

Figure 8.1: The product The why and the what of a product are directly derived from the needs and the constraints of the stakeholders. The what is consolidated in a requirement specification. To determine thewhat sufficient understanding of the how is needed to ensure the feasibility. Understanding the how requires a significant amount of technology and construction know-how. The authentic objectives of the Philips management with respect to the Campus can be read (in dutch) in figure 8.3. These objectives and subgoals are translated in English, see tables 8.1 and 8.2. • Stimulating working environment for synergy and innovation • Enduring development of the organization • Efficient accomodation Table 8.1: Objectives of the Philips management w.r.t. the Campus The objectives make it clear that the Philips management is aware of influence of the housing on the organization and may other human factors. The objectives address mostly human factors, within an economic efficiency constraint.

Gerrit Muller Human Measure and architecting
January 22, 2010 version: 0.2

Embedded Systems Institute

page: 105

Understanding

Describing

Guiding

Why

What

How

Do the right things Do the things right

Spec

Spec Spec

Stakeholders with Needs and Concerns

Requirements

Construction Constraints and Opportunities

Figure 8.2: What is Architecting?
Campus Doelstellingen * Stimulerende werkomgeving voor synergie en innovatie * Duurzame ontwikkeling van de organisatie * Efficiënte huisvesting Sub-doelen : + Open relatie met omgeving + Innovatieve werkomgeving + Bevorderen van synergie d.m.v. gemeenschappelijke faciliteiten + Integratie van werken en privé + Blijvende positie van Philips onder de eerste elektronica concerns + Versnelling van innovatie-processen + Aantrekkingskracht toptalent + Opheffen versnippering + Versterken imago

Figure 8.3: Philips management objectives w.r.t. Campus The vision of the architects, see figure 8.4 is to create a very open and transparant building. Open and transparant stimulates communication, sharing and cooperation. An modern outlook and embedding the building in the high-tech campus creates a stimulating and innovative environment. Somewhat late in the process the final inhabitants were involved in the internal design of the building. Table 8.3 show some of the wishes of the inhabitants. especially the concentration requirement was undervalued by the architects and some raging debates took place about this subject. Figure 8.5 shows the internal design after taking into account the concentration requirement. The open space is mostly filled with (small) two person rooms, to provide the required quiet atmosphere. The informal communication is now foreseen near the two coffee pantries.

Gerrit Muller Human Measure and architecting
January 22, 2010 version: 0.2

Embedded Systems Institute

page: 106

• • • • •

Open relation with environment Innovative working environment Encouraging synergy by sharing facilities Integration of professional and private life Consolidation of position of Philips as one of the leading electronic companies • Acceleration of innovative processes • Remove fragmentation • Improve image Table 8.2: Subgoals w.r.t. the Campus

open spacious flexible

mind mapping rooms

Figure 8.4: The architects vision The openess is reduced to open staircases and the atrium at the south side of the building. Figure 8.6 shows an impression of the space near the staircase. The work of the architect is to bridge the stakeholder world and the construction world. This construction world is much more technical, many technical aspects must be taken into account by the architect. Figure 8.7 shows a number of the more technical aspects: • • • • Facilities Infrastructure Design aspects Construction aspects

Note that most technical aspects have a counterpart in terms of stakeholder

Gerrit Muller Human Measure and architecting
January 22, 2010 version: 0.2

Embedded Systems Institute

page: 107

• Comfortable • Concentration • Communication • Practical Table 8. Figure 8. This model provides a spectrum of 5 viewpoints. Gerrit Muller Human Measure and architecting January 22.2 Embedded Systems Institute page: 108 . 2010 version: 0.5: After user amendation concerns. ranging from the customer objectives (customer what) to the realization (product how). which results in many procedures.3: Wishes and concerns of the inhabitants Open Spacious Room for 2 persons Concentration Figure 8. In technical architecting we promote the ”CAFCR”-model[13].8 shows the architecting aspects mapped on this model. provisions and hence also in requirements for the new building. For instance safety is a major concern of a plant manager. guidelines.

2010 version: 0.Figure 8.7: The technical side of the architecture Gerrit Muller Human Measure and architecting January 22.6: Space impression infrastructure + power + telecom and computer network + climate control + light + fire detection and prevention design aspects + maintenance + safety + security + flexibility + campus style construction aspects + legislation + material properties + weight.2 Embedded Systems Institute page: 109 . strength + cost. effort + tools facilities + sanitary + catering + meeting Figure 8. size.

2010 version: 0.What does Customer need in Product and Why? Product How Customer What Customer How Product What C ustomer objectives A pplication F unctional C onceptual R ealization Philips Management objectives Philips Research way-of-working Facilities Infrastructure Quality requirements Design aspects Construction aspects Figure 8.2 Embedded Systems Institute page: 110 .8: WDC architecting mapped on ”CAFCR” Gerrit Muller Human Measure and architecting January 22.

2 Embedded Systems Institute page: 111 . • Time independent entertainment and other video content • Convenience.8.4.4: Consumer Objectives The product requirements are translated in a design in an iterative fashion. 20:00 start movie 21:00 broadcast record view play 22:00 end movie 23:00 talk view phone rings pause viewing finish conversation resume viewing Figure 8. no hassle • Fits in family environment Table 8. see figure 8. Figure 8. Gerrit Muller Human Measure and architecting January 22.10 shows some of the relevant technical side of a DVR. providing a consumer freedom in time. Figure 8. Finally all these issues are mapped on the ”CAFCR”-model.3 The Product: Digital Video Recorder A Digital Video Recorder (DVR) is described in the same perspective as the building WDC to compare building architecting and electronic product architecting. One of the main functions of a DVR is time shifting.11 Many similarities of the WDC and the DVR ”CAFCR”-model are evident.9: Example product: Digital Video Recorder Some objectives of the consumer are summed up in table 8. 2010 version: 0.9 shows a simple example of the application of time shifting.

11: Product architecting mapped on ”CAFCR” Gerrit Muller Human Measure and architecting January 22.10: The technical side of the architecture What does Customer need in Product and Why? Product How Customer What Customer How Product What C ustomer objectives A pplication F unctional C onceptual R ealization Time independence Home environment Features Infrastructure Quality requirements Design aspects Construction aspects Figure 8. 2010 version: 0. effort + tools Figure 8.features + recording + play + programming (EPG?) + navigation design aspects + reliability + safety + security + content protection + brand style infrastructure + power + analog and digital network construction aspects + performance + physical properties + weight. size + cost.2 Embedded Systems Institute page: 112 .

The product architect must be involved in the later stages of the project. The (electronics) product architecting is a very immature discipline. If the architect is not available in that phase the integrity of the architecture is in severe danger. to solve unforeseen requirements and implementation hurdles. where the construction technology is changing rapidly. showing that the building architect stops after delivering the design.12: Architecting dynamics The maturity influences the way of working of the architect. The building architect is sometimes involved in the acceptance of the building. with millenia of experience. the phase transition between building and using. Due to the immaturity of the involved disciplines both unforeseen requirements and implementation hurdles are a fact of life. work at the beginning of a project. or the actual use of the building. The strict phasing of the building world is in my opinion too strong. Also many unforeseen requirements and implementation hurdles are also a fact of life Gerrit Muller Human Measure and architecting January 22.2 integration and test product architect Embedded Systems Institute page: 113 . if not all.8. Figure 8. Many building architects don’t get practical feedback from builders and users. The maturity of both disciplines is quite different. The building architect does most.12 shows the relative effort as function of time.4 Discussion Many similarities exist between the building architect and the (electronics) product architect. At the other hand electronics and software are very young disciplines. The building architect is not involved in building. relative effort building architect ideal building architect time bu ild p e fit u rst us i f use lor exp n n n atio finitio desig e d Figure 8. Architecting buildings is a very mature discipline. 2010 version: 0. preparing the use.

This requires substantial know how and understanding of both worlds. which had a significant impact on the architecture. Stakeholders WDC Architect DVR Construction Figure 8.2 Embedded Systems Institute page: 114 . 2010 version: 0.13: Bridging 2 worlds Gerrit Muller Human Measure and architecting January 22.5 Conclusion The main function of an architect is to bridge the stakeholder world and the construction world. Examples of implementation hurdles are the climate control and the light controls.in buildings. As example of an unforeseen requirement we can look at the concentration wish of the users.13. The function of the building architect and the electronic product architect is quite similar from that perspective. see figure 8. 8. researchers.

pages 81– 102. [3] Hay Management Consultants.pdf.A. gaudisite. [9] Gerrit Muller. Mann. 2002.nl/MedicalImagingPaper. http://swissnet. Addison Wesley.html. Volume 290.edu/6805/student-papers/ spring02-papers/caps. November 1981. Case study: Medical imaging. . http://www. [4] George T. September 2002. Hay Managament Consultants showed me this model in 1997/1998.T. The Atlantic Monthly. Technology management cycle.mit. Homeland insecurity. Carnival booth: An algorithm for defeating the computer-assisted passenger screening system. 2000. 1995. 2000. ca.gaudisite. pdf. 1975. [2] Samidh Chakrabarti and Aaron Strauss. The original title of the Japanese article is unknown. pages 35–36.nl/ProcessDecompositionOfBusinessPaper. [6] Gerrit Muller.htm. pdf.Bibliography [1] Frederick P. Shows that security systems based on secret designs are more vulnerable and less secure. Process decomposition of a business. way to write management’s goals and objectives.R. 1999. There’s a S.nl/index. [8] Gerrit Muller.M. http://www. gaudisite.nl/MaturityPaper. 1999. Management Review (AMA Forum). Very nice interview with Bruce Schneier about security and the human factor. http://www. Brooks. No. [7] Gerrit Muller. gaudisite. 2T. [5] Charles C. Doran. The arisal of the system architect.ai. http://www. The Mythical Man-Month. from toolbox to product to platform. taken from an article by a Japanese author. The system architecture homepage.

Pierre America. date: October 18. hitech-projects. 2006 changed by: Gerrit Muller • Added ”Decomposing the Architect. What are Critical Success Factors?” Version: 0.pdf. The Art of Systems Architecting. http://www. 2002 changed by: Gerrit Muller • Added ”Communicating via CAFCR. gaudisite. gaudisite. CRC Press. COPA.nl/FromFuzzyToSmartPaper. 2001.2.pdf. the sheep with 7 legs. 2002 changed by: Gerrit Muller • Created very preliminary bookstructure. date: June 12. 1997.nl/FunctionProfilesPaper. [13] Henk Obbink. Florida. illustrated by security example” Version: 0. Function profiles. Jürgen Müller.[10] Gerrit Muller. http://www. and Rob van Ommering. http://www. [12] Gerrit Muller. a component-oriented platform architecting method for families of software-intensive electronic products. date: June 16. 2002. Maier.pdf.gaudisite.2 Embedded Systems Institute page: 116 .pdf.nl/ArchitecturalReasoningBook. 2010 version: 0. Architectural reasoning explained. From the soft and fuzzy context to SMART engineering. [11] Gerrit Muller. 2001.com/SAE/COPA/COPA_Tutorial. History Version: 0. no changelog yet Gerrit Muller Human Measure and architecting January 22. [14] Eberhardt Rechtin and Mark W. 2000.1. Boca Raton. http://www.

Sign up to vote on this title
UsefulNot useful