Flexibility Tim Daniels, Bart Venckeleer. Flexibility – UA 01/03/2010 2 Agenda Part 1: Example – Definition – Link with IT Architecture Part 2: How to

FlexibilityTim Daniels, Bart Venckeleer

2Flexibility – UA 01/03/2010

Agenda

Part 1: Example – Definition – Link with IT Architecture

Part 2: How to assess for software flexibility?


Definition

Flexible:1. Capable of being bent or flexed; pliable.2. Susceptible to influence or persuasion; tractable.3. Responsive to change; adaptable: a flexible schedule.


IT Example – Context

Web Application

Mainframe

Integration Layer

Broker

Employee

Sales… Accounting …

… Tariff Engine …

• Keywords: insurance, premium calculation

• Mainly a mainframe/COBOL environment

• The premium calculation done by the tariff engine plays a role in 14 business processes.

• Under accounting the calculation and allocation of taxes and commissions is understood

• Don’t underestimate the complexity of an aged IT system.

• Don’t expect too much active and accurate knowledge about the inner details of the system.

Mainframe




Tariff Engine

IT Example – Problem

BasicPremium

SegmentationCommission

&Taxes

500 €

Input(Power, Age, …)

Output(Total Premium,

Taxes,Commissions)

Mainframe




Tariff Engine Customer Part

Tariff Engine Accounting Part

IT Example - Solution

Formula DrivenPremium Calculation

Input(Free)

Output(Total Premium)

Input(Total Premium)

Formula DrivenTaxes and Commission

Calculation

Output(Taxes,

Commissions)

Mainframe




IT Example - Observations

The cost for change was lowered:• Formula driven instead of limited parameterization• Loose coupling between the customers premium and its

accounting

The cost for change remained the same for:• Changes at the level of a business process• Changes at the level of the channels

Tariff Engine Customer Part

Formula DrivenPremium Calculation

Input(Free)

Output(Total Premium)

Tariff Engine Accounting Part

Input(Total Premium)

Formula DrivenTaxes and Commission

Calculation

Output(Taxes,

Commissions)


Broker Employee

Mainframe




Definition Revisited

Generally speaking the flexibility of an IT system is a measure for the cost (time, effort, competences, …) for changing a system within well specified boundaries that are understood by both business and IT.

The higher the flexibility, the lower the cost for change.


Tip

Focus also on what will not change


Flexibility and Solutions

Context: looking for a solution that allows to create and publish documents. Support for as many document types and output devices is requested.

.NET/JAVASetup: very highFlexibility: high

PostscriptSetup: moderate to highFlexibility: moderate

WordSetup: very lowFlexibility: low

Setup: all that needs to be done to create a working system on top of the chosen technology


System Thinking

Vochtverlies

Dorst

BierConsumptie

Gambling Money


Watch Out (Fixes that Fail)

ChangeBudget

IT SystemFlexibility

Earnings

RunBudget

IT SystemComplexity

EmployeeEffort

Set up


Agenda

Part 1: Example – Definition – Link with IT Architecture

Part 2: How to assess for software flexibility?


How much flexibility should you build into a software architecture?

If you build in too much flexibility, your architecture, although highly flexible and easy to modify, will likely take a long time to create and suffer runtime performance problems.

This is because flexibility is typically achieved by separating functions from each other with layers of abstraction, and these layers incur a runtime performance penalty.

If you don’t build in enough flexibility, your architecture will be rigid, with lots of hard-wired dependencies or, worse still, will be a “spaghetti” architecture in which everything is tangled together with everything else

You will likely have a quick time to market, but you might suffer in the long run when you need to modify the architecture.


How do you know whether a system has the right flexibility level?

To answer this question we need:

A measure

An understanding of the architecture

The know how

Source: http://www.sei.cmu.edu/library/abstracts/presentations/10sep2009webinar.cfm


To Measure We Need a Yardstick

Principle 1: Quality Attributes determine the architecture.

Principle 2: Business Goals determine quality attribute requirements.

Principle 3: Business Goals represent what’s important to its stakeholder communities.

Principle 4: Quality attributes requirements need to be specified with good measures.

Creating the yardstick means:Eliciting the needs from the stakeholders and translating them into quality attribute requirements in a precise and measurable way.


What do flexibility scenario’s look like?

Scenario A new feature requiring a change to the insurance product representation is added. Implementation of the new representation can be performed in 3 days.

Stimulus Add new feature to impacting the representation of insurance products

Stimulus source Product manager

Artifact InsuranceProductFactory

Environment Design time

Response The new feature is designed, implemented, tested, and deployed

Response measure One person can realize the new feature in less than 3 days.


The Architecture Understanding

Principle 5: To understand an architecture you must understand its quality attribute properties.

Principle 6: The most important quality attribute requirements determine the parts of the system to focus the analysis on.

Principle 7: The distribution of functionality in the architecture contributes to the quality attribute properties.

Understanding the architecture means:Understand the approaches the architect used, understand the functional distribution and understand where to find the trouble spots.


What patterns, styles, mechanisms are we looking for? The Adaptation View deals with how the system adapts itself

during evolution.

• MICROKERNEL• REFLECTION• INTERCEPTOR

The Language Extension View is concerned with how systems offer an abstraction layer to the computation infrastructure.

• INTERPRETER• VIRTUAL MACHINE• RULE-BASED SYSTEM


One step back: Parameters to Control Modifiability Based on Coupling and Cohesion

The average cost of modifying a responsibility is the average cost of directly modifying that responsibility plus the average cost of modifying all responsibilities that have additional modifications propagated to them.

Reducing the average cost of modifying a single responsibility ‘A’ and making no other changes will decrease the average cost of any modification that affects ‘A’.

Reducing the strength of the coupling between two responsibilities ‘A’ and ‘B’ and making no other changes will decrease the average cost of any modification that affects ‘A’.

The cost of changing responsibility ‘A’, that has a high strength of coupling with responsibility ‘B’, is less if ‘A’ and ‘B’ are collocated in the same module than would it be if they were located in different modules.


Modifiability tactics

At design time:• Reducing the cost of a single

responsibility Split a responsibility

• Increase cohesion Maintain semantic coherence Abstract common services

• Reduce coupling Use encapsulation Use a wrapper Raise the abstraction level Use an intermediary Restrict communication paths

At coding time• Use aspect oriented

programming• Use polymorphism• Parameterize modules

At build time• Use component replacement

At deployment time• Use configuration time binding

At initialization time• Use resource files

At runtime• Use runtime registration• Interpret parameters• Use start-up time binding• Use runtime binding• Use name servers• Use plug ins• Use publisher-subscriber


Performing the Evaluation

Principle 8: “Guilty until proven innocent.”

Principle 9: Proper analysis disallows assumptions. Only facts count.

Principle 10: Evaluated organizations must own the evaluation results.

Performing an evaluation means:Do not blindly trust anything that is provided. Ask for convincing evidence. Failure to provide this evidence results in risks.


Conclusions

Flexibility is a developer oriented quality attribute • Be aware for over engineering

Best practices often have a negative impact on performance latency requirements

Multiple best practices promote building flexible software• E.g. Spring dependency injection

Specific quality attribute requirements with regard to flexibility are sparse

Proper analysis disallows assumptions.Only facts count.

Documents

Flexibility Tim Daniels, Bart Venckeleer. Flexibility – UA 01/03/2010 2 Agenda Part 1: Example – Definition – Link with IT Architecture Part 2: How to