Light Weight Architecture: the way of the future? · Light Weight Architecture: the way of the future? June 21, 2020 version: 2.3 University of South-Eastern Norway-NISE page: 6

Light Weight Architecture: the way of the future?-

Effe

ctiv

enes

s

architecture weight

(for dynamic markets and fast changing technologies)

very low low medium high

overall

effectiveness

Manageability

Flexibility

= Flexibility * Manageability

Gerrit MullerUniversity of South-Eastern Norway-NISE

Hasbergsvei 36 P.O. Box 235, NO-3603 Kongsberg Norway

[email protected]

Abstract

The question : ”What is an architecture” is addressed. Trends in the customerworld and in the technology are used to obtain an outline of the product require-ments. The customer world itself is a value chain consisting of quite heterogeneousstakeholders.To satisfy the needs of these customers an integral approach is required. Architec-tures play a key role in such an integral approach.Architecture lessons from practice are given to illustrate criteria for a good archi-tecture are discussed. The concept of architecture-weight is introduced.

DistributionThis article or presentation is written as part of the Gaudí project. The Gaudí project philosophy is to improveby obtaining frequent feedback. Frequent feedback is pursued by an open creation process. This document ispublished as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as thedocument remains complete and unchanged.

All Gaudí documents are available at:http://www.gaudisite.nl/

version: 2.3 status: finished June 21, 2020

1 Introduction

Architecture is the combination of the know how of the solution (technology)with understanding of the problem (customer/application). The architect must playan independent role in considering all stakeholders interests and searching for aneffective solution. The fundamental architecting activities are depicted in figure 1.

Do the right things

Do the things right

HowGuiding

WhyUnderstanding

WhatDescribing

Figure 1: What is Architecture?

Do the right things is addressed in section 2. Do the things right is addressedin section 3. The weight of an architecture is discussed in section 4. This structureof the presentation is visualized in figure 2.

1A. Do the right things; The Dynamic Market

1B. Do the things right; Lessons from Practice

25 Kg

Why What How

Understanding Describing Guiding

2. The Weight of an Architecture;

Architectural Chaos or Bureaucratic Control?

On/Off

This appliance may only be used for non commercial use

accuracy +/- 200 g

Figure 2: Table of Contents

Gerrit MullerLight Weight Architecture: the way of the future?June 21, 2020 version: 2.3

University of South-Eastern Norway-NISE

page: 1

2 Do the right things; The Dynamic Market

Philips Semiconductors (PS) plays a part in a longer value chain as depicted infigure 3. Typical the components of PS, such as single chip TV’s, are used bysystem integrators, which build CE appliances, such as televisions. These appli-ances can be distributed via retail channels or via service providers to end consumers.

ProvidersUPC

Canal+ AOL

AT&T

RetailersFry's

Dixon

Consumers Boonstra

PeperKok

Chirac

Blair

PietersenSmith

Jones

Jansen

Muller

Kleisterlee

Clinton

v.d. Spijker

Meulengraafder Kinderen

Reinders

Bush

Rooyakkers

de Vries

Koch

d'Oliviera

van Oranje

Obbink

v.d. HamerCharite

Cruijf

Neeskensvan Hanegem

Goedkoop

Sharon

El Khatabi

de Gruijter

Heijn

Schijvens

Waterreus

Leonardo

van Bommel

Nistelrooij

Gandhi

Pinochet

Bakker

v.d. Meulen

Hoessein

Schroder

Schweitzer

Peters

Gore

System IntegratorsSony Philips CE-DN

Loewe

NokiaPhilips CE-TV

Philips CE-PCC

Component and

Platform SuppliersPhilips Semiconductors

Philips Components ST

TI

Samsung

Microsoft

Intel

Liberate

Micron

LG

It's

Prodi

Figure 3: Value chain

One of the major trends in this industry is the magic buzzword convergence.Three more or less independent worlds of computers, consumer electronics andtelecom are merging, see figure 4; functions from one domain can also be done inthe other domain.

The name convergence and the visualisation in figure 4 suggest a more uniformset of products, a simplification. However the opposite is happening. The conver-gence enables integration of functions, which were separate sofar for technicalreasons. The technical capabilities have increased to a level, that required function-ality, performance, form factor and environment together determine the productsto be made. Figure 5 shows at the left hand side many of today’s appliances, in themiddle many form factors are shown and the right hand side shows some environ-ments.

Note that making all kind of combination products, with many different form



page: 2

Telecom

Consumer

Computer

Figure 4: Convergence

mp3

dvd

set top box

flat display

pen

speech

cable

modem

firewall

Ambient Intelligence

living room

car

car navigation

pda

surveillance

camera

camera

GSM phone

computerCommunicator

television

games

sailboat

audio

microset

headphone

garment

watch

Figure 5: Integration and Diversity

factors for different environments and different price performance points creates avery large diversity of products!



page: 3

AOL

Amazon.com

source: BigChart.com

dd march 19, 2001

1997 1998 1999 2000 2001

Figure 6: Uncertainty (Dot.Com effect)

Another market factor to take into account is the uncertainty of all players inthe value chain. One of the symptoms of this uncertainty is the strong fluctuationof the stock prices, see figure 6.

1965 1979

2000 1990

1 kB

64 kB2 MB

Moore's law

Fro

m: C

OP

A tu

toria

l, R

ob

va

n O

mm

erin

g

Figure 7: Moore’s law

An historical trend is that the amount of software is increasing proportionalwith Moore’s law, see figure 7.



page: 4

time to

marketeffort

10 100

digital TV

GSM

application

infrastructure

1 10

100

manyearmonths

volume

units

106

103

personalized

(skins, themes)

TV

1000

1

GSM

Figure 8: System Integrator Problem Space - Business

From business point of view the products and/or markets of the system integratorscan be characterized by time to market, volume, effort to create. In these 3 dimen-sions a huge dynamic range need to be covered. Infrastructure (for instance thelast mile to the home) takes a large amount of time to change, due to economicalconstraints, while new applications and functions need to be introduced quickly (tofollow the fashion or to respond to a new killer application from the competitor).The volume is preferably large from manufacturing point of view (economy ofscale), while the consumer wants to personalize, to express his identity or community(which means small scale). As mentioned before the effort to create is increasingexponentially, which means that the effort is changing order of magnitudes overdecades. Figure 9 summarizes these characteristics.

106

109

1012

performance power

10-3

1

home

server

digital TVhome

server

digital TV

GSM

GSM

storage

106

109

1012

digital TV

home

server

GSM

Operations/s Watt Byte

103

Figure 9: System Integrator Problem Space - Technology

Main technology concerns of the system integrators are performance, power



page: 5

and storage. Again a huge dynamic range need to be covered in these dimensions.Video based applications have much higher processing demands than GSM speechaudio. While for power portable appliances like a GSM have severe constraintsand should use orders of magnitude less power than TV’s or set top boxes. Theamount of storage is again highly function dependent, for instance a home serverwhich must be able to store many hours of video needs a huge amount of storage,while the address book of a GSM phone is very limited in its storage needs. Thetechnology parameters and dynamic range are visualized in figure 9.

Problem space

106

109

1012

home

server

digital TV

GSM

Operations/s

10-3

1

home

server

digital TV

GSM

103

106

109

1012

digital TV

home

server

GSM

Byte

10

application

infrastructure

1

100

monthsunits

106

103

TV

1

GSM

personalized

(skins, themes)

100

digital TV

GSM

10

manyear

1000

pe

rform

an

ce

po

we

r

sto

rag

e

time

to

ma

rke

t

vo

lum

e

effo

rt

Watt

Figure 10: System profile

Combining the figures in one picture enables the visualization of a systemprofile. Figure 10 shows the profiles for a digital TV and for a GSM cell phone.The profile is not extended to the time to market measure, because several differenttime constants play a role for both GSM phones and televisions. The device itself,the applications running on the devices, the services offered on device plus infras-tructure, and the infrastructure itself all have different time constants.



page: 6

106

109

1012

performance power

10-3

1

home

server

digital TVhome

server

digital TV

GSM

GSM

Operations/s Watt

103

Motion

detector MPEG

decoder

MP3

WAP

TCP/IP

Bluetooth

1394

USB

802.11

TriMedia

MIPS

ARM

Real

GSM

GPS

pSOS

WinCE

RF

amp

Figure 11: PS Technology solutions

The Philips product division Semiconductors has many hardware and softwaresolutions available in IP-blocks. For a single problem many solutions are available.These solutions differ in their characteristics, such as performance, power andstorage. The choice of the solution is driven by the specific product require-ments. Figure 11 shows a subset of the available solutions and shows for 3 specificsolutions their performance and power characterization.

watch

digital TV

set top box

communicator

pda

MP

EG

de

co

de

r

MP

3

TC

P/IP

Blu

eto

oth

13

94

TriM

ed

ia

MIP

S

AR

M

Re

al

GS

M

GP

S

pS

OS

Win

CE

RF

am

p

camcorder

required

optional

Technologies

Systems

Figure 12: Partial Solution: Configurable Component Platform

The convergence problem (diversity and integration) can be tackled by a platformapproach, where all the solutions must be available to be combined in one integratedsolution. Figure 12 shows how appliances could be composed from availablesolutions.

Figure 13 summarizes the exploration of the problem and solution space. Theuncertainty and diversity is addressed by programmability, flexibility, composablearchitecture, product family approach and configurability. The increased effortis addressed by shifting development effort to suppliers. The dynamic range of



page: 7

Increase

supplier

content

Programmability,

flexibility

Family of

products

Configurability

Competitive

Performance /

cost / power

Solution

ingredients

Composable

Architecture

Problem space

106

109

1012

home

server

digital TV

GSM

Operations/s

10-3

1

home

server

digital TV

GSM

103

106

109

1012

digital TV

home

server

GSM

Byte

10

application

infrastructure

1

100

monthsunits

106

103

TV

1

GSM

personalized

(skins, themes)

100

digital TV

GSM

10

manyear

1000

pe

rform

an

ce

po

we

r

sto

rag

e

time

to

ma

rke

t

vo

lum

e

effo

rt

Watt

watch

digital TV

set top box

communicator

pda

MP

EG

de

co

de

r

MP

3

TC

P/IP

Blu

eto

oth

13

94

TriM

ed

ia

MIP

S

AR

M

Re

al

GS

M

GP

S

pS

OS

Win

CE

RF

am

p

camcorder

required

optional

Technologies

Systems

Figure 13: Exploring problem space and solution ingredients

requirements is addressed by supplying the right solutions at different competitiveperformance/cost/power points.

From: COPA tutorial;

Philips SW conference 2001.

Architecture only works if the complementary

viewpoints are addressed consistently

BBusiness

OOrganization

PProcess

AArchitecture

Figure 14: More than Architecture

This presentation focuses on architecture. Being good in architecting is notsufficient to be successfull in the market. Addressing the Business, Process andOrganization (People) issues also is essential for success, see figure 14

Figure 15 summarizes the conclusions of the first part of the article.



page: 8

What

Describing

WhyUnderstanding

Dynamic MarketConvergence Integration

Diversity

Configurable Component Platform

Portfolio and Family architecture

Figure 15: Conclusions Part 1A



page: 9

3 Do the things right; Lessons from Practice

Creating the solution is a collective effort of many designers and engineers. Thearchitect is mostly guiding the implementation, the actual work is done by thedesigners and engineers. Guiding the implementation is done by providing guide-lines and high level designs for many different viewpoints. Figure 16 shows someof the frequently occurring viewpoints for guiding the implementation. Note thatmany people think that the major task of the architect is to define the decompo-sition and to define and manage the interfaces of this decomposition. Figure 16shows that architecting involves many more aspects and especially the integratingconcepts are crucial to get working products.

4. Infra-

structure

2. Construction

Decomposition

3. Allocation

5. Choice of

integrating

concepts

1. Functional

Decomposition

tunerframe-

bufferMPEG

DS

PCPU RAM

drivers scheduler OS

etc

audio video TXTfile-

systemnetworkingetc.

view play browse

storage

acquisition compress encoding

displayde-

compressdecoding

Resource

usagePerformance

Exception

handling

Device

abstraction

Pipeline

Figure 16: ”Guiding How” by providing rules for:

Architecting involves amongst others analyzing, assessing, balancing, makingtrade-offs and taking decisions. This is based on architecture information and facts,following the needs and addressing the expectations of the stakeholders. A lot ofthe architecting is performed by the architect, which is frequently using intuition.As part of the architecting vision, overview, insight and understanding are createdand used.

The strength of a good architect is to do this job in the real world situation,where the facts, expectations and intuition sometimes turn out to be false orchanged! Figure 17 visualizes this art of architecting.

Many people expect the architect to decompose, as mentioned in the expla-nation of ”guiding how”, while integration is severely underestimated, see figure 18.In most development projects the integration is a traumatic experience. It is achallenge for the architect to make a design which enables a smooth integration.

A common pitfall is that managers as well as engineers expect a platform to bestable; once the platform is created only a limited maintenance is needed. Figure 19



page: 10

Intuition, assumptions, beliefs, bias

Expectations

Facts

Architecture(s)

Architecture

Architect(s)

Stakeholders

analyze

assess

balance

trade-off

decide

vision

overview

insight

understanding

Architecting

problems, legacy

uncertainties

unknowns

Facts, Expectations and

Intuition may be false

Integration requires a

critical mindset that is alert

for unknowns

Figure 17: The Art of Architecting

explains why this is a myth. A platform is build using technology that itself ischanging very fast (Moore’s law again). At the other hand a platform served adynamic fast changing market, see section 2. In other words it is a miracle if aplatform is stable, when both the supplying as well as the consuming side are notstable at all.

The more academical oriented methods propose a ”first time right approach”.This sounds plausible, why waste time on wrong implementations first? The practicalproblem with this type of approach is that it does only work in very specific circum-stances:

• well defined problem

• few people (few background, few misunderstandings)

• appropriate skill set (the so-called ”100%” instead of ”80/20” oriented people)

The first clause for our type of products is nearly always false, remember thedynamic market. The second clause is in practical cases not met (100+ manyearprojects), although it might be validly pointed out that the size of the projects is thecause of many problems. The third clause is very difficult to meet, I do know onlya handful of people fitting this category, none of them making out type of products(for instance professors).

Figure 20 shows the relationship between team size and the chance of success-fully following the first time right approach.

Understanding of the problem as well as the solution is key to being effective.Learning via feedback is a quick way of building up this understanding. Waterfallmethods all suffer from late feedback, see figure 21 for a visualization of theinfluence of feedback frequency on project elapsed time.



page: 11

Decomposition

is "easy"

Integration is

difficult

Figure 18: Architecting is much more than Decomposition

Architecture

Platform

Dynamic Market

Fast changing Technology

How stable

is a platform

or an architecture?

Components

Figure 19: Myth: Platforms are Stable

The evolution of a platform is illustrated in figure 22 by showing the change inthe Easyvision [2] platform in the period 1991-1996. It is clearly visible that everygeneration doubles the amount of code, while at the same time half of the existingcode base is touched by changes.



page: 12

1

maybe

10

unlikely

100

miracle

1000

impossible

person years

First time right?

Figure 20: The first time right?

3 months

25 months

2 months

12 months

1 month

8 months

Start Start Start

Target Target Target

stepsize:

elapsed time

Small feedback cycles result in Faster Time to Market

Figure 21: Example with diffrent feedback cycles (3, 2, and 1 months) showing thetime to market decrease with shorter feedback cycles

1991

1992

1994

1991

1994

Last changed in:

Growth

Change

3rd

generation components are mature, active maintenance needed.

Growth and change continues, some "old" components become obsolete

1992

1996

Figure 22: Platform Evolution (Easyvision 1991-1996)



page: 13

4 The Weight of an Architecture; Architectural Chaos orBureaucratic Control?

Does an architecture help to be successfull in the business or does it harm thesuccess? As always the answer from the architect is: it depends. The crucialsuccess factor is the weight of the architecture.

scope (impact) ,

level of enforcement ,

size,level of coupling or

number of dependencies

= f (

)

weight (rule) guideline

portfolio

weight

multi-page

builds on

many rulesstand-alone

productcomponent

weight(architecture) = weight(rule)

all rules

conditional

rule

mandatory

rule

single-line multi-line

low high

Rule

1

25 KgOn/Off

Rule

1Rule

2

Rule

1Rule

1

Rule

1 Rule

n

Figure 23: Architecture Weight

Figure 23 gives a definition for the weight of the architecture. The simpledefinition is that the overall weight of an architecture is the sum of the weight ofall rules which together form the architecture.

The weight of a single rule is determined by level of enforcement, scope (impact),size, level of coupling or number of dependencies. Figure 23 gives for each of theseparameters a scale from low weight to high weight.

Business or Portfolio

Product Family

Product

Subsystem

Component

n

m

n

m

n

m

n

m

Heavy-weight

High impact

Large scope

Small scope

Low impact

Light-weight

Figure 24: Scope and Impact

Figure 24 zooms in on the scope parameter to make clear the relation betweenthe scope of the rule and the consequence for the weight.

For instance a rule like: all the functions in all the products of the portfoliomust (manadatory) return an complete predefined status object as defined in the



page: 14

system design specification, chapter exception handling, making use of the templateas described in the coding standards and using the prescribed class and includefiles as present in the appropriate version of the code repository is a heavy rule(mandatory, portfolio scope, 4 lines of text (without the appropriate references)and depending on other entities (system design spec, template and code standard,prescribed classes and includes, repository).

Business

manager

Engineers

bottomline

future growth

guidance

understandability

accessibility

product feasibility

implementation

decoupling

solution freedom

being informed

functionality

performance

timely available

acceptable cost

Customer

Suppliers

Architecture

Feedback

Responsiveness

Solution Freedom

Communicable

EvolutionOpen

Figure 25: Criteria for an Architecture

So far no judgement is provided for having a good or bad architecture. Inorder to make a judgement we need to understand the objectives and concerns ofthe stakeholders. Figure 25 shows a number of the stakeholders and their mainconcerns. Note that the stakeholders have different and sometimes conflictingrequirements, such is life.

Effe

ctiv

enes

s

architecture weight

for dynamic markets and fast changing technologies


ManageabilityIntegration

Interoperability

Providing control

FlexibilityEvolution

Responsiveness

Maintenance

Figure 26: Weight versus Effectiveness

The next step in reaching a judgement is to look at the relation between effec-tiveness and weight. Figure 26 show this relationship for flexibility (evolution,



page: 15

responsiveness, maintenance) and manageability (integration, interoperability, providingcontrol). Flexibility decreases when the weight increases, while the manageabilityis proportional with the weight.

Effe

ctiv

enes

s

architecture weight

(for dynamic markets and fast changing technologies)


overall

effectiveness

Manageability

Flexibility

= Flexibility * Manageability

Figure 27: Conclusion Part 2

The question of good of bad depends on the relative importance of flexibilityand manageability. For our dynamic markets and fast moving technology flexibilityis very important, but for customer satisfaction the manageability is also important.The combination of these 2 requirements is shown in figure 27, where the curveshows that an optimum is achieved when both concerns are sufficiently met.

For different product/market/technology combinations different curves will result.Mature (stable, certain) markets with slow changing technologies, the optimum isdetermined by manageability and hence a heavy architecture. At the other extremevery dynamic markets and technologies, with forgiving customers or low economicrisks will benefit from extreme flexibility and a very light architecture.



page: 16

5 Light weight how-to

With both the definition of the weight of the architecture and the insight that thisweight should be low it becomes possible to look for ways to minimize the weight.

An high impact way of minimizing the weight is to minimize the number ofthe rules. This can be achieved by providing as much as focus to the architectureas possible. Focus is derived from the market and customer needs. Understandingof the customer helps to understand and therefore to sharpen the requirements, seefigure 28.

weight(architecture) =

all rules

weight(rule)

2. Minimize the weight per rule

1. Reduce the rule set to the (business) essential

Understand

· your customer

· your customer's customer

etcetera

Figure 28: Light Weight How -To

The next step is to minimize the weight of every individual rule. Every parameterinfluencing the weight of a rule must be minimalized. The level of enforcement canbe minimized by making as few as possible rules manadatory, work with guidelinesas much as possible. The scope can be minimized by empowering and delegatingas much as possible, in other words let component or subsystem architects makelocal rules (or better guidelines) for their specific scope. The size of a rule isminimized by leaving out details in the rule itself, short conceptual rules are verypowerful. The level of coupling is minimized by ”designing” the architecture rules.Especially multi-view architecting helps to cope with the highly complex reality.One dimensional decompositions result in highly coupled rules to capture aspectsfrom other dimensions.

Figure 29 visualizes the way to minimize the individual weight of a rule.



page: 17

scope (impact) ,

level of enforcement ,

size,

level of coupling or

number of dependencies

f (

)

weight(rule)= minimize number of mandatory rules

empower, delegate

minimize implementation details

focus on essential concepts

Apply design principles on architecture

Multi-view architecting

Figure 29: Minimize Rule Weight



page: 18

6 Summary

Figure 30 summarizes the full presentation. The market to be served is highlydynamic. Lessons from practice show that changes are normal, stability of thesolution is the exception. In this dynamic market with a changing solution spacethe architecture must be light weight.

Problem space

106

109

1012

home

server

digital TV

GSM

Operations/s

10-3

1

home

server

digital TV

GSM

103

106

109

1012

digital TV

home

server

GSM

Byte

10

application

infrastructure

1

100

monthsunits

106

103

TV

1

GSM

personalized

(skins, themes)

100

digital TV

GSM

10

manyear

1000

pe

rform

an

ce

po

we

r

sto

rag

e

time

to

ma

rke

t

vo

lum

e

effo

rt

Watt

2. Optimal architecture: Light weight !

1B. Architecting in Practice:

Change is normal,

Stability is the exception

1A. Dynamic Market: Understand Your

Customer

GrowthChange

Effe

ctiv

enes

s

architecture weight


overall

effectiveness

Figure 30: Summary

7 Acknowledgements

This presentation has been enabled by the inspiring and critical comments of:

• Jürgen Müller

• Peter van den Hamer

• Lex Heerink

• William van der Sterren

Remarks and textual improvements were made by Pierre van de Laar.

References

[1] Gerrit Muller. The system architecture homepage. http://www.gaudisite.nl/index.html, 1999.

[2] Gerrit Muller. Case study: Medical imaging; from toolbox to product toplatform. http://www.gaudisite.nl/MedicalImagingPaper.pdf, 2000.



page: 19

http://www.gaudisite.nl/index.html

http://www.gaudisite.nl/index.html

http://www.gaudisite.nl/MedicalImagingPaper.pdf

http://www.gaudisite.nl/MedicalImagingPaper.pdf

HistoryVersion: 2.3, date: June 17,2010 changed by: Gerrit Muller

• minor textual improvementVersion: 2.2, date: June 5, 2008 changed by: Gerrit Muller

• textual improvements• Explanation added why profile does not extend to time to market

Version: 2.1, date: May 31 2002 changed by: Gerrit Muller• Updated figure ”Criteria for an architecture”• Updated figure ”The art of architecting” and added one sentence to the descriptive text.

Version: 2.0, date: May 29 2002 changed by: Gerrit Muller• Added the annotated text version



page: 20

Documents

Light Weight Architecture: the way of the future? · Light Weight Architecture: the way of the future? June 21, 2020 version: 2.3 University of South-Eastern Norway-NISE page: 6