ARCHITECTURE FRAMEWORKS

This page is published under the terms of the licence summarized in the footnote.

This paper introduces methods designed to help people create architecture descriptions and use them to good effect.

ARCHITECTURE FRAMEWORKS.......................................................................... 1

Architecture frameworks.......................................................................................... 1

Architecture process frameworks............................................................................. 1

Architecture descriptions.......................................................................................... 4

Architecture models and abstractions....................................................................... 5

Architecture description frameworks..................................................................... 12

Architecture frameworks

An architecture framework provides a structure and guidance that architects can use in their work. The overall structure is a high-level picture that helps you scope work to be done. Each section guides you as to what to do and to document. The framework connects activities and deliverables into a coherent whole. Architects should customize any given framework to suit the work at hand. However, the framework should remain reasonably stable for one pass through the architecture development process.

A comprehensive framework contains both

• a development process (a process framework) and
• one or more classifications of architecture descriptions (a description framework).

Architecture process frameworks

Terms: Architecture process framework, Architecture State, The Open Group Architecture Framework (TOGAF), Architecture Development Method (ADM), Avancier Methodology (AM).

· Architecture process framework: A description of a process that develops a target architecture to meet some requirements, under some constraints, plans the move from the baseline state to the target state, and governs that change.

· Architecture State: A baseline architecture describes a system in a state to be reviewed and/or revised. A target architecture describes a system in a state that is to be created and implemented in the future. An intermediate or transitional architecture defines a state of a system between baseline and target.

Enterprise Architecture Planning Process (EAP, Spewak)

This was perhaps the first well-known process for enterprise architecture. It covers defining baseline and target enterprise architectures, and planning and managing the migration from baseline to target. It stops short of implementation and change management.

• Planning Initiation
• Principles
• Business Modelling
• Current Systems & Technology
• Data Architecture
• Applications Architecture
• Technology Architecture
• Implementation/Migration Plans
• Planning Conclusion

Here is a link to a summary of the book and some places where you can get it.... http://www3.sympatico.ca/cypher/architecture.htm

The Open Group Architecture Framework (TOGAF)

TOGAF is a framework for enterprise architecture, with a focus on improving how IT supports the business. At its core is a process called Architecture Development Method. ADM is a process to develop and then deploy an enterprise architecture. So it extends beyond EAP into implementation and change management. It is presented as a cycle of 8 phases labelled A to H.

TOGAF presents phases A to H as a clockwise cycle with Requirements Management in the centre. The table below shows the cycle of ADM in anti-clockwise cycle that separates the first development half of the cycle from the second management half.

Development phases	Continuous phase	Management phases
Preliminary phase: Architecture framework and principles	← ↓ Requirements Management ↑ →
A Architecture Vision		H Architecture Change Management
B Business Architecture		G Implementation Governance
C Information System Architecture		F Migration Planning
D Technology Architecture		E Opportunities and Solutions

If ADM is the core of TOGAF, then the core of ADM is definition of the three architecture domains in phases B, C and D. Each domain is defined at two states - the baseline (as is) and target (to be) states. ADM starts with a preliminary phase in which architecture processes and deliverables are customised to fit the circumstances.

In practice, architects tend to customize ADM in various ways. They may define baseline architectures before target architectures, run change management as a continuous process, and define a workable architecture migration path before identifying projects. The result of adapting ADM might be a cycle presented like this.

Development phases	Continuous phases	Management phases
Preliminary phase: Architecture framework and principles	← Requirements Management ↓ H Architecture Change Management ↑ →
A Architecture Vision		G Implementation Governance
B, C & D Baseline Architecture		E & F Project Planning
B, C & D Target Architecture		E & F Architecture Migration Path Planning

Enterprise Architecture as Strategy (Ross, Weill and Robertson)

Moving out of IT into the business world, this is mostly a book of case study stories and ideas for Business and IT strategy. But it does contain a kind of very high level process, which can be summarised thus:

• Analyse your foundation for execution
• Define Your Operating Model
• Select one of Diversification, Coordination, Replication, Unification
• Design your Enterprise Architecture
• Encapsulate the EA in a Core Diagram of the chosen Operating Model)
• Navigate the Stages of Enterprise Architecture Maturity (Business Silos, Standardized Technology, Optimise Core, Business Modularity)
• Set Priorities
• Navigate the Stages of Enterprise Architecture Maturity
• Cash In on the Learning
• Design and implement an IT Engagement Model
• Link IT Governance at senior levels to disciplined project management
• Build the Foundation one Project at Time

· Exploit your foundation for execution for growth

• Fund training and development
• Incentivise use of the foundation
• Encourage and reward creativity.

The Avancier Methodology (AM)

Moving a little down the scale from business to IT, AM features an architecture process framework designed more for solution architects than enterprise architects. The process is presented in 9 steps, though iteration and parallelism is expected. AM was developed independently of TOGAF, but is represented in the table below in a form that enables comparison with ADM.

Development steps	Continuous activities	Management steps
1. Define precursors	Manage requirements change ↓ Govern architecture ↑ →
2. Scope the work		9. Govern the migration.
3. Understand the baseline		8. Hand over
4. Review non-functional criteria		7. Plan the migration
5. Outline the target		6. Select and manage suppliers

Architecture descriptions

Terms: Architecture description, ANSI 1471, ISO/IEC 42010, View, View point, Building block (aka brick).

Architecture description: A high-level description of the structure and behaviour of an enterprise or system.

ANSI 1471: A former identity of the standard now known as ISO/IEC 42010. The common name used in this reference model for ISO/IEC 42010: Recommended Practice for Architecture Description of Software-Intensive Systems. A standard for software architecture or system architecture. It focuses on the description of an architecture as the concrete artifact representing the abstraction that is software architecture or system architecture.

View: “a representation of a whole system from the perspective of a related set of concerns, to demonstrate to one or more stakeholders that their concerns are addressed in the design of the system.” (extract from ANSI 1471) A description that hides irrelevant details or facets of the system described. An instance of a view point. E.g. A specific logical data model shows the scope and structure of data stored by an application, but shows nothing of processes or technologies. Views are represented in many forms, including flat lists, hierarchical lists, and tables that map one list of things to another. Various graphical notations are used as alternatives to lists and tables. Views are decomposable. Views can share content. Views can contain parts of other views.

View point “what views of the same kind look like… a schema or template… describing the purpose and intended audience of the view” (extract from ANSI 1471). A type of view. A meta view. Defines a view’s scope (the concerns addressed) and style (documentation conventions). Should be stored for reuse by architects in the same organisation. E.g. Generally speaking, a logical data model drawn using the IDEF1X standard can address concerns shared by systems analysts and database designers.

See papers at ref. 1 for detailed discussion of ANSI 1471 and the concepts of views and view points.

Building blocks

Building block is a term used in TOGAF (cf. brick, used by Gartner in their framework). It can mean:

1. An object in an architecture model or repository

Or 2: A component of a larger system, definable by its interface.

Or 3: Any item that can be reused in different structures or models.

A building block can be documented as an object in its own right, using a standard template. The names of building blocks appear in structures, models, and in mappings between them.

The typical building blocks of architecture models can be classified by architecture domain as follows:

• PRECURSORS: Business goal/objective, Principle, Stakeholder.
• BUSINESS: Business function, Business process, Organisation unit, Location, Role (actor or user), Business service (external or internal), Time period.
• DATA: Data entity, Data event, Data flow, Data quality, Data source, Data store.
• APPLICATIONS: Application, Use case, Automated service (business service or data service), Data flow (interface), Component (data component or user component).
• INFRASTRUCTURE: Computer, Network, Technical standard, Standard or strategic technology.

See the paper “AM deliverables” for templates for these and other objects that appear in architecture models and descriptions, along with some advice on the structures those objects appear in. Always, document only as much as you need to for the task at hand. You’ll find you cannot successfully maintain documentation that is not used.

Architecture models and abstractions

Terms: Model, Mapping, Abstraction, Composition, Decomposition, Generalisation, Specialisation, Idealisation, Realisation, Idealisation hierarchy, Conceptual (or domain) model, Logical model, Physical model, Model-Driven Architecture (MDA), Reference model, Unified Modelling Language (UML), ArchiMate.

Model

Model: A description that hides some details the things described. A limited representation of entities and events in the real world. A kind of view, usually a narrow view that is drawn in the form of a diagram.

Most models used in architecture descriptions be assigned to an architecture domain. For example:

• PRECURSORS: Goal or requirements hierarchy, Goal or requirements traceability, Process map, Context diagram (business or IS).
• BUSINESS: Business function structure, Business process model, Organisation structure, Location structure, Business function dependency matrix (business services), Business data model.
• DATA: Data model, Data lifecycle, Data structure, Business function-Data CRUD matrix, Application-Data CRUD matrix, Data dissemination matrix.
• APPLICATIONS: Application or component portfolio, IS context diagram, Business-Applications matrix, Applications architecture diagram, Application decomposition diagram, Software layering diagram.
• INFRASTRUCTURE: Technical Reference Model, Standards Information Base, Technical environments outline, Logical platform configuration diagram, Physical hardware configuration diagram.

The enterprise IT department is responsible for data processing. It looks after the business data. It looks after the applications that gather data, process data and supply data to people following business processes. So naturally, many of the models that architects draw are based on some kind of data model, data flow model or process model.

The table below lists some diagram types you’ll find architects reading and drawing.

To be described	Common diagram types	UML variants
GENERAL STRUCTURES
One-to-many cascade	Hierarchy chart
Many-to-many mapping	Matrix	Package dependency diagram
IS/IT ARCHITECTURE STRUCTURES
Application integration	Data flow diagram
Application composition	Module hierarchy/network	Component diagram
Hardware/network configuration	Various box-line diagrams	Deployment diagram
DATA STRUCTURES
Data store structure	Data model. Entity-relationship diagram (IDEF1X or CACI), perhaps w attributes.	Class diagram without operations
Data flow structure	Regular expression (XML schema or Jackson structure).
PROCESS STRUCTURES
Process flow	Flow chart (Business Dynamics or BPMN). State chart.	Activity diagram, state chart and interaction diagram
Structured procedure	Regular expression (action diagram or pseudo code).

The table above is not meant to be a scientific classification. And there is a notable omission – the UML class diagram. Many software architects draw class diagrams to represent the modularisation of OO software systems. Some solution architects use class diagrams to represent data models and component structures. But it is debatable how well an enterprise or solution architect needs to able to read a class diagram of the complexity that software architects deal with.

Besides the models mentioned above, don’t forget documentation of such things as technical reference models, strategic technology recommendations, technical environments, IT capacity plans. And test strategies, test condition lists, test plans, test run indexes.

Mapping

Mapping: A trace between items in different structures. An architecture is a structure in which objects are related. Mappings show where and how things are related.

The concept of a mapping can embrace relationships between objects of one kind within one structure (e.g. between entities in a data model, or steps in a process flow). But the term is usually reserved for mapping between objects in distinct structures.

• Between objects of different kinds (e.g. data entity to process step)
• Between objects in distinct configurations (e.g. requirement item to solution item.)

Architectural models that take the form of mappings include:

• Organisation Unit to Business Function
• Data Entity or Data Store to Business Function
• Data Entity to Data Store
• Data Entity or Data Store to Data Quality
• Application to Platform Technology.

Mappings are made for the purposes of gap analysis, impact analysis, requirements traceability or cluster/affinity analysis.

Mappings for gap analysis

Gap analysis means looking for items with no relationship, for loose ends, black holes and gaps that may require attention.

Perspective (inter-domain) mappings

You can compare architecture perspectives: business with IS and/or IT architecture. E.g. you may do this to check the target IS architecture matches the target IT architecture.

Technologies Applications	DBMS	Messaging	GIS	Applications with no technology
CRM	Supported by	Supported by
Broker Application		Supported by
Employee Portal				Employee Portal
Technologies not used			GIS

Inter-state mappings

The paper on migration planning shows how baseline/target gap analysis may be done using in a matrix. You may want also to compare a vision (or specification) with reality (an implemented solution).

Mappings for traceability analysis

Traceability analysis means following mappings to check deliverables meet goals and solutions solve problems.

Requirement to solution mappings

You can map requirement items to solution items.

Solution items Requirements	A	B	D	Requirements that have no solution
A	Satisfied by
B		Satisfied by
C				No solution
Solution items that have no requirement			No requirement

Logical to physical mappings

You can map logical business functions to physical organisation units, or map logical entities (in a data model) to physical data stores. You can use the latter to analyse data distribution, by defining which data store is the master for each entity.

Physical data store Logical entity	Marketing	Sales	Warehouse	Accounts
Customer	Copy	Master		Copy
Order		Master (until Order Closed)	Copy	Master (after Order Closed)
Invoice				Master

You may note where different attributes of a logical entity are mastered in different physical data stores. You can look for gaps that indicate areas where further analysis is needed.

Mappings for impact/dependency analysis

Items of one kind may depend on items of several other kinds. Impact analysis implies recording dependencies, so you can follow mappings to check if a change to one item causes a change to related items.

Process-to-data mappings

Many varieties of process to data mappings are used. To analyse or validate a model, you might map at two or three different levels of granularity.

• Business process steps to data stores
• Use cases to aggregate entities (perhaps encapsulated in business components).
• Business/data services to individual entities.

Application/process/technology mappings

Enterprise architects commonly map applications, processes and technologies to each other and to other things like organisation unit, business function and location. E.g. To analyse a distributed business process, you might map business process steps to the locations or the organisation units of an enterprise.

Mappings for cluster/affinity analysis

Cluster/affinity analysis means grouping closely-coupled items into separable components. This is not addressed in this guide – rather in guides to component-based development and related topics.

Abstraction

Abstraction: 1: A process of composition, generalisation or idealisation by which shorter and more general descriptions are produced from longer, more detailed and more specific descriptions. Or 2: A simplified description of a system that is made by the process at definition 1.

See papers at ref. 1 detailed discussion of abstraction. What follows is only a summary definitions of the terms used in three scales of abstraction..

Abstraction of a composite from elements

• Composition: 1: the assembly of parts into a whole; 2: the organisation of units under a manager or owner; 3: the encapsulation of content inside a shell. The result is some kind of aggregate or composite component or process. A composite contains its components in some sense. A description made with reference to a whole, manager or shell is more abstract than one that refers to its parts, units or content.
• Decomposition: The opposite of composition. Division of one composite or aggregate component or process into several components or processes. The conventional advice is that it is difficult to maintain the integrity of a hierarchical structure that is decomposed more the three or four levels (or more than a thousand elements) from the top.

Abstraction of a generalisation from specialisations

• Generalisation: Abstraction from several specific components or processes into a more generic component or process. The generalisation contains only the common features of its specialisations.
• Specialisation: The opposite of generalization; the elaboration or division of a general component or process into one or more specific components or processes. A specialisation contains its generalisation in some sense.

Abstraction of an ideal from the real

• Idealisation: A kind of generalization; abstraction from one specific component or process into a higher-level description or requirement statement. It can be viewed as a kind of reverse engineering. It creates a description that can be communicated as the requirement for the real thing.
• Realisation: The opposite of idealization; leads to the instantiation of physical materials. It can be viewed as forward engineering, as a progression from requirement to solution.

The following sections focus on the last scale..

Idealisation hierarchy

Idealisation hierarchy: The idealisation hierarchy of conceptual model, logical model and physical model.

Many analysis and design methods are based on the idea that we should build idealised logical models of problems and requirements then elaborate the models in a step-by-step fashion until they can be realised as working systems. Most authors speak of three levels of model:

• Conceptual (or domain) model: A logical model that defines terms and concepts in a business or problem domain without reference to any computer application. Aka a domain model or computation-independent model (CIM).
• Logical model: A model that excludes details of physical implementation. Aka platform-independent model (PIM) that is unrelated to a specific technology or supplier (though may be related to a Standard).
• Physical model: A model that includes details of physical implementation. Aka platform-specific model (PSM) related to a specific technology or supplier.

Berrisford’s law of model maintenance: people are lazy. In practice, I have yet to see people systematically maintain three levels of model from conceptual to physical. In practice, people usually combine (or confuse) adjacent levels. Perhaps the majority document only one abstract model outside of the implemented system. Some maintain no abstract model at all. The trouble is:

• If logical and physical models are very similar, then people see no point in the logical model, they’ll drop it and maintain only the physical.
• If logical and physical models are very different, then the transformation between them is difficult, and people will maintain only the physical unless the logical is also implemented in a real form.

In practice, to maintain models at several levels of abstraction, you need automated support for forward and reverse engineering between the models.

Model-Driven Architecture

Model-driven design is a process that elaborates a model through levels of abstraction to create a working solution. It is based on the notion that we define a logical model of the system that is to meet given requirements, then transform that into a physical model that is implementable on a specific platform.

Model-driven design can be applied to all kinds of system. For example, it can be applied to embedded systems, process control systems. And a lot of the interest in domain-specific language is not associated directly with database system. However, our focus here is on enterprise applications in general and database systems in particular.

There are two different ways to use the ideas of model-driven design in database systems. These two ways lead to different understandings of what a logical model is. The table below draws a comparison you may find useful.

Model-driven database design	Model-driven software design: as in MDA
CDM: Conceptual data model	CIM: Computation-independent model
LDM: Logical data model	PIM: Platform-independent model
PDM: Physical data model	PSM: Platform-specific model

These two different ideas or techniques are entangled and confused in popular usage.

Model-driven software design is a broad church. The most well known branch, called MDA, was launched in 2001 by its sponsor, the Object Management Group (OMG).

Model-Driven Architecture (MDA): A vision of the Object Management Group (OMG) that encourages vendors to develop tools that help people transform a conceptual model to a logical model, and a logical model to a physical model, and the reverse. A transformation may be called forward engineering or reverse engineering.

The OMG adapted the general ideas of model-driven development. They defined an approach to IT system specification that separates the specification of system functionality from the specification of the implementation of that functionality on a specific technology platform. They defined an architecture for models, guidelines for structuring specifications.

MDA divides models of software systems into three levels, and divides meta models into two. Curiously, one of the meta models is more about data than software.

MDA concepts are highlighted in this table
Level of model	Model-driven database design	Model-driven software design
Conceptual model	CDM: conceptual data model	CIM: Computation-independent model
Logical model	LDM: logical data model	PIM: Platform-independent model
Physical model	PDM: physical data model	PSM: Platform-specific model
Meta model	CWM: Common warehouse model	UML: Unified modelling language

MDA is a vision, a banner or theme under which CASE tool vendors market modelling tools, and strive to automate transformations between CIM, PIM and PSM models. This means that a logical model should contain hooks for the details to be added when the logical model is transformed into a physical model.

MDA as a methodology

System functions are defined in a platform-independent model (PIM) using UML, or a DSL (Domain Specific Language) which is based on UML and/or the MOF. “Importantly, this is where MDA differs from other applications of the DSL approach, which are more, well, domain-specific.” Kevlin Henney

The platform is defined in a Platform Definition Model (PDM). This corresponds to CORBA, .Net, the Web, etc.

The PIM is translated to one or more platform-specific models (PSMs) for implementation using different Domain Specific Languages, or a General Purpose Language like Java, C#, Python, etc.

Translations are performed using automated model transformation tools, e.g. tools compliant to the new OMG standard named QVT.

(See document produced and regularly maintained by the OMG and called the MDA Guide.)

Transformations between models

MDA involves transformation, potentially both forward and reverse engineering, between three levels of model. It can be summarised in diagram that places these models in the system development life cycle.

Most of the energy in MDA surrounds tools to automate the forward engineering transformation from PIM to PSM. In practice, to develop a PIM to the point where it can be automatically transformed into a PSM you must develop business-specific details to about the same level of detail as you would in developing a PSM.

A PIM saves effort by enabling you to omit some platform-specific details (say transaction commit and rollback functions). The idea of MDA is that a transformation engine helps you by plugging infrastructure into the PIM at defined points. In fact, enterprise application development has long proceeded in this way. The enterprise buys and/or builds commonly useful infrastructure in the form of enterprise frameworks and component libraries.

Reference model

Reference model: A relatively abstract model people use as a guide in creating their own more specific model. Typically, a structure of components, services, data entities or processes.

Notations for architecture models

The Integrated Definition Language (IDEF) was created by the US Air Force for the process of airplane design and other logistics.

• IDEF0 is a process and data flow modelling notation, not much used now.
• IDEF1X is a data modelling notation, still popular.

Unified Modelling Language (UML) is a standard maintained by the Object Management Group (OMG) for diagrams that describe object-oriented software designs, though often used outside of that domain. The diagram types most commonly used by architects are:

• Use case diagram – for the scope of a system.
• Activity diagram – for process flow charts (and sometimes data flow diagrams).
• Class diagram – for data models (and sometimes class models).
• Sequence diagram – for interactions between applications and/or other components.
• Deployment diagrams – for hardware configurations (though rarely in the plain fashion of UML).

ArchiMate: A notation or modelling language for architecture description that shares some symbols with UML. Used for model diagrams in which components, interfaces and services are shown in distinct boxes.

It is assumed all readers have access to documented guidance on how to draw models using UML or another notation.

Architecture description frameworks

Terms: Architecture description framework, Architecture repository, Zachman framework, Enterprise continuum, Architecture continuum, Solutions continuum.

Architecture description framework: A classification of and guidance for architecture documentation, which may be stored in a repository. E.g. the Zachman Framework and the Enterprise Continuum.

Architecture repository: An information base used by architects. A system that holds and manages all the meta data that describes an enterprise and its information systems. The meta data comprises specifications of components, services, reference models and other items architects may want to reuse. This meta data can be categorised inside the repository using classifications such as the Zachman Framework and the Enterprise Continuum.

Zachman framework

Rudyard Kipling wrote “I keep six honest serving-men (They taught me all I knew); their names are What and Why and When And How and Where and Who.”. The Zachman Framework encourages architects to ask each of these questions of different stakeholders, at different levels of abstraction.

According to the Zachman International web site, “the Zachman Framework™ is a schema - the intersection between two historical classifications:

• [6 columns show] the primitive interrogatives: What, How, When, Who, Where, and Why.
• [6 rows show] reification, the transformation of an abstract idea into an instantiation… Identification, Definition, Representation, Specification, Configuration and Instantiation.”

The framework is “A logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to managers and to developers of Enterprise systems.” Drawn as table or grid:

• The rows are primarily levels of idealisation-realisation. But they are also interpreted as stakeholder groups and architecture viewpoints. Zachman says the rows should not be interpreted as levels of decomposition.
• The columns are primarily analysis questions. But they are also interpreted as architecture domains (data, process, network etc.)

The Zachman Framework			Columns
Rows			What	How	Where	Who	When	Why
Level of Idealisation	Architecture Viewpoint	Stakeholder Perspective	Data	Function	Network	People	Time	Motivation
	Scope	Planner
Conceptual	Enterprise	Owner
Logical	System	Designer
Physical	Technology	Builder
	Detailed	Subcontractor
Real	Actual systems	Operations

The framework was originally described with a view to holding information system descriptions. The 1992 paper by Zachman and Sowa notes the framework was popular with systems analysts and database designers. It hasn’t proved so engaging to business people and infrastructure/technical architects. Users have tended to focus on modeling data and processes for software system development.

Zachman’s idea was to populate the cell with a “views” that answer different questions from different stakeholders. The completion of the cells is determined by users of the framework. Any appropriate approach, standard, role, method, technique, or tool may be placed in it. The framework can contain global plans as well as technical details, lists, and charts as well as natural language statements. This freedom appeals to creative enterprise architects.

The framework is today promoted by the Zachman Institute for Framework Advancement (www.zifa.com). Details are only available on a commercial basis. See also papers at ref. 1 for discussion of "What’s wrong with the Zachman Framework?”

Enterprise continuum

Enterprise continuum: A structure for architecture description artifacts used in TOGAF. An 8 cell classification for the contents of an architecture repository.

Drawn as a table or grid: the 2 rows represent levels of idealisation-realisation: the architecture (logical) and solutions (physical) continuums:

• Architecture continuum: The higher-level spectrum in the enterprise continuum, which contains logical or vendor-neutral specifications. It corresponds to the conceptual and logical model levels of the idealisation hierarchy.
• Solutions continuum: The lower-level spectrum in the enterprise continuum, which contains specifications of products and services that implement the logical specifications. It corresponds to the physical model level of the idealisation hierarchy.

Architecture precursors (requirements and context) can be considered as above the Architecture Continuum.

Architecture implementations (deployed solutions) can be considered as below the Solution Continuum.

The 4 columns represent generalisation-specialisation, ranging from universal to bespoke or uniquely configured.

• Foundation: Items that are generic and widely used.
• Common systems: Structures (composed of foundation items) that are used across most business domains.
• Industry: Structures and items used by enterprises in one business domain (say, Telecoms or Banking).
• Organisation: Structures and items specific or bespoke to a single enterprise.

See papers at ref. 1 for further description of TOGAF and the Enterprise Continuum.

Ref 1: other papers in the library at http://avancier.co.uk

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see http://creativecommons.org