© chris britton, 20091 chris britton polyphony it ltd email:...

© Chris Britton, 2009 1

Chris Britton

Polyphony IT LtdEmail: [email protected]

Mobile: +44 (0) 777 623 0266

Polyphony:A Tool for Explaining what IT Applications Do


Who is Chris Britton

• Old timer, worked for Burroughs, ICL and Unisys– Originally

• Database support specialist• System software fixer

– Worked in software engineering in California, designing the implementation for a semantic database product

– Did some project management, business management and (even) some marketing

– Went into IT consultancy• Wrote “IT Architectures and Middleware: Strategies for Building Large,

Integrated Systems”– 2nd edition, with Peter Bye, published in 2004– BCS book of the month for November, 2004

• Designed and programmed WeaverBird – a generic model building program

• Designed and programmed Polyphony


Polyphony – Explaining What IT Applications Do

Is this a problem? If so, does it matter? If it does, how does it work? OK, what difference does it make?


Analogy – Building Designs (1)

Detailed drawingse.g. http://www.library.gatech.edu/gtbuildings/french/drawings.htm

The internal layout The elevation Problems with the above

Must assemble thepicture in your mind

Must ensure consistency


Analogy – Building Designs (2)

• A Model• A Virtual Reality

Simulation• Problems with the above

– Detail is missing– Expensive

• A Computer model cando everything (in theory)


Explaining a Design is Hard

Detailed plans Incomprehensible without context Must ensure consistency

Multiple views (elevations and floor plans)

The reader must build a picture in their mind

Must ensure consistency A Model – A simplified representation

of a real or imaginary system Better idea of look and feel Expensive, unless a computer

model A Virtual Reality Walkthrough

Does it really help you much?

Clients want to understand Usability Aesthetics Costs

Builders want to understand Material requirements Resource requirements Details Practicality to build

Method Audience


Explaining IT Application Designs (1)

Use Cases Wordy Lacks context – the big picture Hard to ensure consistency Often dubious quality

UML diagrams Often Incomprehensible

Business Rules Difficult to understand the

consequence of the rules Difficult to picture how it

actually works


Explaining IT Application Designs (2)

Throw away prototype Single view – the user interface Commercial application's purpose

is to store and provide data, and this must be imagined

Tends to focus reviews on triviality (e.g. the position of the company's logo on the screen)

Partially completed application Difficult to understand what is

happening underneath Hard to understand wider

consequences (e.g. business process integrity)

Reviews may feel restrained in their criticism because of obvious rewrite cost


Does It Matter

Underpins design reviews of future applications by business management

Underpins business reviews of existing applications, or of business functions that uses the application

Contractual problems of inaccurate specification (e.g. Outsourced development)

Understanding the meaning of data – where it's come from and who uses it

One of the reasons why IT developers are so mistrusted

This is one of THE central problems with IT


Polyphony Overview

For describing IT applications Business functional view (i.e. client view, not builder view)

Does not Describe technology Describe the look-and-feel of screens

Stores model data about Tasks and how they relate to each other Data and how it relates to tasks Users and which tasks they use

Generate diagrams from model data Has text front end (rather like a web page) – designed to be used by

non-IT staff


Task Diagram


Task Diagram (after mouse clicks)


Scripts


Data Usage Diagram


User Portal Diagram


Who Needs to Understand IT Applications (1)

Existing end users Polyphony can provide reference documentation Advantage: diagrams and text guaranteed to be in sync

Self learning for end users who need training Need to write introductory text Trainee can “explore” the diagrams (e.g. expand on areas of

interest) Script facility especially relevant

End user managers Need a greater depth of understanding They aren't frequent users, so don't have the familiarity with the

application Both the reference documentation and training material is useful



Planner/researchers/analysts Where does data come from? Who uses the data?

Business process optimizers Understand how the processes really work

Managers understanding and validating proposed changes

Understand what the changes really mean to the business Managers buying a 3rd party application

Understand what the application really means to the business



• IT Staff Programmers (especially ones new to the application) Database designers Security administrators IT managers IT Enterprise Architects IT consultants who will charge large sums of money for

being educated by you about your applications


The Principles Behind Expressing a Design

Users

DataActivities

TaskProcessesRulesScreen flow

Data EntitiesData Items

RolesSecurity privilegesPortalsScreen flow

The relationships between the elements


Activity Dimension

Task is one person doing one thing at one time

A process is a sequence of tasks that starts with an event and ends with one or more deliverable

Aim is to show: Flows between screens All data movement to

Create screen display Update the data entities

Tasks

have screens

have display items andactions

screen actions havescreen flow andoperations

Processes

have tasks


Data Dimension

The purpose of commercial applications is largely to store data and provide data

Data entities represent things like “orders”, “customers” and “products”

Data entities have data items like “code”, “address”, “name” and “quantity”

Data entities can be put into “work pending trays” by one task and taken out by another.This could be implemented many ways (e.g. copy from one database to another, passing a message, or a status field in the data entity)

The collection of all data entities represents a logical database design


User & Security Dimension

SecurityContext

Portals

Portals group the screens andauthenticates the users

Users

Assign roles

Authenticate

Assignprivileges

Privileges –Task and screen restrictionsData access restrictions


Polyphony is a WeaverBird Model

WeaverBird PC application For building and running models Model is one file, can be distributed by

email/web download/etc Generates diagram from model data Has document-like front end Free to use

Advantage for Polyphony Number of lines of code in WeaverBird is >100,000 Number of lines of code in Polyphony is < 8,000


How Polyphony Can be Used

• Send out for review / private study

• Walkthroughs / workshops

• Data Collection


Send out for Review / Private Study

Text front end provides a guide Click on underlined text to

display diagrams Text front end provides detailed

documentation(generated from the model data)

Send by email, web download, etc Script diagrams particularly useful

to show scenarios


Walkthroughs / Workshops

Can go through step by step (equivalent to hundreds of presentation slides)

Can view from different angles – data, task/process, user

Can deviate – not restricted to one narrative stream

Does not get bogged down in: Technology discussions Look and feel of screens


Data Collection(Using the WeaverBird Data

Browser)


Impact on Design

Gathering Requirements

Designing Requirements


How do we Design?Hypothesis: A design is like a

hypothesis

• Before Karl Popper it was believed that science progressed by:– An accumulation of facts, the more the better– A “eureka” moment– Write up – formulation of a new “law of nature”

• Karl Popper taught us that in practice:– Consider a few key facts– Develop a hypothesis– Try to disprove it by considering all the other facts and doing

experiments• Before Popper what was happening was different to what they said was

happening.

I believe this is the current state of IT design today.


What is Design

Understand the requirements - why, what, when, etc

Brainstorm solutions – investigate different ways of tackling the problem

Elaborate – add substance to one possible design and ensure it meets all the requirements

Analyse – try to prove the design is wrong

Understand

Brainstorm Solutions

Elaborate

Analyse

The Design Process

It is a creative process rather like scientific hypothesisbuilding


Large scale design – What happens in other industries?

• Levels of design• Example – aircraft design

Aircraft design

Engine design

Requirements: cost, performance, reliability, etc

Requirements: cost, weight, thrust, fuel consumption, noise, etc

Analysis: Can do calculations to show that if the unit requirements are met, the overall design works.


Levels of Design

Unit A Unit B Unit C

Top level design

Unit AA Unit AB

Unit A design

Unit AA1 Unit AA2

Unit AA design

Unit AA3

Outside requirements

Outside requirements

Layer above requirements

Redesign request

Ideally provably correct, assuming the units fulfil the their requirements


Classic IT Design

Understand = gather requirements

Elaborate = build IT application Analyse = test application

Understand


Elaborate

Analyse

The Design Process

The problem is the enormousgap in time and effort betweenunderstanding and testing.


A Better Plan

The Business Solution Design

The Technical Design

If the technical design is too difficult or too expensive, you may be forced to go back and choose a different business solution.

Understand


Elaborate

Test/Analyse


Elaborate

Test/Analyse


The Role of the Polyphony Model

The Business Solution Design

The Technical Design

Understand


Elaborate

Test/Analyse


Elaborate

Test/AnalysePolyphony model


Which Raises Some Questions

How do we analyse/test a business solutions design? How do application development methodologies

change? What are the advantages & disadvantages of this

approach?


Validating the Design (1)

Process integrity A single event that starts a single task, must start one task, no more and

no less All data needed for a task must be accessible at the point in time when

the task starts All waiting times between tasks must have a time out – something must

be done to stop the process waiting for ever A process must start and stop unless it is deliberately a looped process,

like a process that is monitoring something During the process, data is changed (typically added) and integrity

constraints apply to this data. These must be enforced whatever the path from start to finish

Task integrity Tasks are atomic – they complete in full or not at all (i.e. should follow

transactional ACID constraints) If one message is sent, one message must arrive at the destination



Data Integrity There are data rules – these must be enforced in all tasks in which the data is

created or updated All data is created somewhere and used somewhere else There are reasons for believing the data is accurate when it is entered If the data tracks an external thing, there must be mechanisms to ensure the data

is kept in sync One fact should be held in one place (normalization) There should be a mechanism by which, if data is replicated in several

databases, then it should be kept in sync

Security Roles should have access to all the tasks and data it needs to do its job and no

more There must be a process for allocating and de-allocating all roles

(Note: the technical aspect of security is up to the technical design)



Practicality It must be possible to gather the information to enter into a form speedily and

accurately (it can be measured) You should only need to add information once (e.g. if there is a problem they

should not have to go back to the beginning) Allocating and de-allocating security roles must be fast, painless and accurate

System performance Set the criteria for the trade-off between

Cost of the system

v. Response time and Availability


What Happens to Methodologies

I am not aware of any methodology that attempts to test the requirements In theory:

There should be few problems incorporating requirements design into any methodology,BECAUSE you can always design the requirements before talking to the IT developers

In practice: Heavy-weight methodologies want to express the requirements using

Use Cases – without a proper model of how function impacts data Recommendation: replace Use Cases by Polyphony model

Light-weight methodologies want to keep a continual dialogue with users and learn the requirements piecemeal when needed

Recommendation: replace talking to users with talking to business model designer who maintains the Polyphony model and co-ordinates the views of all stakeholders


Advantages and Disadvantages of Using Polyphony in Design

Advantages: A better design

Less design errors More practical design

A more predictable development (less last minute surprises) A cheaper development (less “just-in-case” development, gold plating of

requirements are more visible) A better trade-off between cost and functionality

Disadvantages: More effort up front Resistance from people, organizations or processes with a vested

interest in the status quo The business will find it more difficult to blame IT (a joke)


Questions ?

More information at www.weaverbird.org/polyphony.htm

© chris britton, 20091 chris britton polyphony it ltd email:...

Documents