10 things to
know about enterprise and solution architecture
This page is published under the terms of the licence
summarized in the footnote.
All
free-to-read materials on the Avancier web site are paid for out of income from
Avancier’s training courses and methods licences.
If you find
them helpful, please spread the word and link to the site in whichever social
media you use.
ArchiMate™ and TOGAF™ are
registered trademarks of The Open Group.
MDA®, Model Driven
Architecture®, and UML® are registered trademarks of the Object Management
Group.
BPMN™, Business Process Modeling Notation™, and Unified Modeling
Language™ are trademarks of the Object Management Group.
Abstract and sources
What is enterprise architecture?
Cognitive dissonance is the term in psychology for the mental discomfort caused by maintaining contradictory beliefs, ideas, or values.
Most enterprise architects have to live with some cognitive dissonance about what enterprise architecture is and should be.
The extracts below are summary tables and lists that Avancier’s customers find useful as reference models.
The paper includes references to background research on EA roles, SA roles and related matters.
“As you've so clearly stated, EA and SA are two different and distinct roles.
I commend you on [answering] the question in a manner that clearly and firmly states the role of an EA. Brava!”
Contents
1
Enterprise architecture differs from solution architecture
2
Architects’ higher level designs constrain lower level designs
3
The architecture work space is divisible by level and by domain
4 The architecture work space covers a
wide range of responsibilities and deliverables
5
The resourcing of architects needs management
6
Enterprise architecture requires an enterprise-wide agenda
7
The systems of interest are purposeful man-made activity systems
8
Architecture is centred on system description
9
Architects convert mental models into documented models (and vice-versa)
10 Agile
development projects must maintain architecture-level documentation
Appendix:
six design dimensions in TOGAF and other architecture sources
Architects support and enable a business by
· Focusing on business roles and processes that are systemisable (repeatable and deterministic) and digitisable (create or use digitised data)
· Shaping and steering the portfolio of systems that enable and support, monitor and direct business roles and processes
· Ensuring a robust IT platform.
The digitisation of business processes, using computers, has enabled business to:
· standardise and integrate business processes and business data to a degree that was impossible before
· perform new information-related processes, and
· gather new kinds of business intelligence about entities and events of interest to business managers.
Many architect job titles appear adverts; and many are ambiguous; there are inconsistent names and definitions
Two surveys
include the top three architect role titles were:
Technical architects: technical subject matter domain experts, software, networks, security etc.
Solution(s) architects solve business problems by addressing the design of business processes and information systems at a high level, then directing lower level designers and builders.
Covers the process of system development or change from business need to
delivery - coordinating all domain specialists as need be.
Enterprise architecture (EA) grew out of thinking at an enterprise-wide level about the information system (IS) architecture of a business.
An enterprise architect covers the breadth of an enterprise – though often specialises in one architecture domain.
An enterprise architecture team is often divided between people who address each of the four primary domains: business, data, applications and infrastructure
The Skills
Framework for the Information Age (SFIA) maps its many roles to 7 levels of
responsibility, for example.
|
Role |
Responsibility level |
||||||
|
Enterprise architecture |
|
|
|
|
5 |
6 |
7 |
|
Solution architecture |
|
|
|
|
5 |
6 |
|
|
Project management |
|
|
|
4 |
5 |
6 |
7 |
|
Business analysis |
|
|
3 |
4 |
5 |
6 |
|
|
Business modelling |
|
2 |
3 |
4 |
5 |
6 |
|
|
Requirements definition and management |
|
2 |
3 |
4 |
5 |
6 |
|
|
System design |
|
2 |
3 |
4 |
5 |
6 |
|
|
Database design |
|
2 |
3 |
4 |
5 |
6 |
|
|
Software development |
|
2 |
3 |
4 |
5 |
|
|
|
Database admin |
|
2 |
3 |
4 |
5 |
|
|
SA is more tactical, local, concrete.
It can be done, often is done,
without EA.
EA is more strategic, cross-organisational, abstract.
EA is supposed to be about architecting the enterprise, rather than one process or one system.
The term is best used for strategic, cross-organisational, enterprise-level, enterprise-wide business system planning.
In contrast to more tactical and localised business process and information system planning.
This table further contrasts enterprise and
solution architect roles.
|
Enterprise Architect |
Solution Architect |
|
Often works for an enterprise, is a manager or member of a central EA function, superintends work done by service providers. Optimises the enterprise systems by integration or standardisation. Aims for enterprise-wide integrity and quality. Responsible for the quality and completeness of strategic road maps. May specialise in one architecture domain. Looks to increase business agility and technical agility. |
Often works for a service provider in the bid and/or delivery phase. Shapes and steers a solution, usually at a project level. Aims for delivery quality: focused on critical success factors, esp. non-functional qualities. Responsible for the completeness of solution outlines and high-level designs. Understands all facets of system design well enough to join up a coherent solution architecture Shares responsibility for time and cost of solution delivery. |
|
Leadership and governance Engages with senior executives and their strategies. Acts as highest-level design authority. May lead architects in a programme, and guide them on standardisation and integration opportunities. May assign other architects to work on discrete developments. Defines general principles, standards, and reusable components. Governs that solution architects comply with relevant overarching EA. |
Leadership and governance Joins up business analysts, software architects and technicians Submits solution architectures for approval to higher/other authorities. Joins lower-level technical specialists to each other and the overall architectural landscape. Identifies and mitigate technical risks, with delivery time and cost in mind. Adopts general principles, standards, and reusable components. Governs solution delivery, may be asked to heed relevant overarching EA. |
|
Planning level and time frame Considers the whole enterprise as a system. Sets out strategic cross-organisational road maps Addresses the politics of cross-organisational concerns and goals, setting strategic and cross-organisational directions. Governs diverse programmes over the long term. |
Planning level and time frame Considers selected business roles and processes. Relatively tactical: the migration path for a programme or project. Does what has to be done to address specific problems and requirements, and shape and steer system changes with an eye on risks and costs. Shapes specific solutions over a shorter time frame. |
|
Design and documentation Designs and documents the enterprise system estate (aka landscape) and reference models. Works at the highest level with coarse-grained and logical outlines Documents the architecture of the enterprise enough to enable impact analysis. |
Design and documentation Designs and documents solutions to specific business problems. Works at a middle level, elaborates from the abstract to the concrete, selects physical components. Describes the architecture of a system that is the outcome of one endeavour, at a level sufficient for detailed design and building to proceed. |
Properly-speaking, enterprise architecture is about architecting the enterprise, not architecting a tactical solution.
It is a strategic approach to cross-departmental integration and interoperability, with focus on “holistic enterprise change”, as the quotes from TOGAF 9 below indicate.
Chapter 1: the [enterprise]
architecture crosses multiple systems,
and multiple functional groups within the enterprise.
Chapter 1: The purpose of
enterprise architecture is to optimize
across the enterprise the often fragmented legacy of processes (both manual
and automated) into an integrated environment that is responsive to change and
supportive of the delivery of the business strategy.
Chapter 1: An enterprise architecture [provides] a strategic context for the evolution of the IT system in response
to the constantly changing needs of the business environment.
Chapter 2: [an advantage is]
process, concept, and component re-use
across all organizational business units
Chapter 6: The enterprise
architecture provides a strategic,
top-down view of an organization to enable executives, planners,
architects, and engineers to coherently
co-ordinate, integrate, and conduct their activities.
Chapter 16: The main purpose
for the development of the enterprise architecture has been strategic direction and top-down
architecture and project generation to achieve corporate capabilities.
Chapter 32: Enterprise
architecture is … a horizontal function that looks at enterprise-level (as well as line of business-level) optimization
and service delivery.
Chapter 42: [TOGAF’s]
purpose … is to ensure that the various architecture descriptions… support the comparison and integration of
architectures within and across architecture domains (business, data,
application, technology), and relating
to different business area scopes within the enterprise.
However, TOGAF
blurs the distinction by hitching EA to use of its process (ADM) for
shorter-term business-driven work, so many of its readers now use the term EA
for SA.
Architects work at a higher level of design than detailed designers, technical specialists and builders.
As higher level designers, they direct and constrain lower level designers.
· They set targets that lower level designers must aim to reach.
· They describe designs in abstract and idealised forms that lower level designers must elaborate and realise.
· They set out generic standards, principles, patterns and reference models that lower level designers should apply in specific cases.
Higher level can mean more abstract in various ways shown in the table below.
Architects tend to start to the left in some or all ways below, though they may go on to address things on the right as well.
|
Higher level
design |
Directs and constrains |
Lower level design |
|
Strategies and road maps |
Longer time -> Shorter time |
Shorter term sprints and deadlines |
|
Broader goals, longer processes and coarser-grained subsystems |
Composition -> Decomposition |
Narrower requirements, shorter processes and finer-grained components |
|
Standards, principles, patterns and reference models |
Generalisation -> Specialisation |
Application of standards, principles, patterns and reference models |
|
Business needs and idealised system descriptions |
Idealisation -> Realisation |
Physical technology solutions |
|
Encapsulation by services in interfaces |
External -> Internal |
Realisation by internal roles and process |
|
Required services and processes |
Behaviour -> Structure |
Designed roles and interfaces |
By documenting and governing some or all of the things on the left:
· Enterprise architects direct and constrain solution architects.
· Solution architects direct and constrain software architects and other technical specialists.
· Software architects direct and constrain software developers.
To see how these six design dimensions appear in various architecture sources, read the appendix.
Enterprise architecture grew out of IS and IT architecture partly because high level IS and IT strategies can, do or are intended to last longer than many business strategies do.
IS and IT people are always seeking a business strategy that is long enough and broad enough for them to pin their plans to.
Enterprise architecture views an enterprise as a system, composed of coarser-grained systems, which are composed of finer-grained systems and so on.
Wherever system scopes are nested, the corresponding architecture descriptions must be nested.
TOGAF proposes a hierarchical, recursive approach to architecture development, suggesting two levels of decomposition.
· "Strategic Architecture: A summary formal description of the enterprise, providing an organizing framework for operational and change activity, and an executive-level, long-term view…."
· "Segment Architecture: A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity."
· "Capability Architecture: A highly detailed description of the architectural approach to realize a particular solution or solution aspect..."
At the lower levels, where the scope is narrower, the architecture description can be more detailed.
At every level, the architecture definition ought to start with required behaviour (services and processes) and logical (technology independent) specification.
IT is now more pervasive than it was, and more central to some businesses.
There are still business processes that make little or no reference to digital information, and many business strategies are little hindered or helped by IT considerations.
But our era has been known as “The Information Age” since the 1970s, and since the 1980s, EA has been about considering business, IS and IT together.
The BCS divide architecture into three levels and four domains or views.
The four primary architecture domains have appeared in most if not all popular architecture frameworks since the PRISM paper of 1986.
TOGAF inserts fourth level (segment) between enterprise and solution.
|
Architecture Work Space |
||||
|
Domain/view Level |
Business |
Information/Data |
Applications |
Infrastructure Platform |
|
Enterprise |
|
|
|
|
|
Solution |
|
|
|
|
|
Software/technical |
|
|
|
|
|
Operations |
|
|
|
|
For deeper discussion of this tabular work space, read this paper: Mapping roles to the architecture work space.
“perfect. I like the
introduction of "software" - which is missing today in our company.
Also nice in this paper is the fact that it
clarifies exactly what I want to do - and what I don't ;-). I'll use it.”
The idea is not to assign row/column titles to people, or to pigeon-hole a person in one cell.
The purpose of the table is to help in assignment of concerns and activities to people - filling gaps - minimising overlaps.
You can choose which cells you want any specific “architect" to cover, and give that cell group any title you like.
EA views the
enterprise as a system, and to change any part of that enterprise system
requires one or more projects.
A purpose of any
high-level strategy or road map is to shape and direct change projects.
Whatever the
strategy, road map or project, it seems fair to say the
·
architects should be accountable
for the quality of results/deliverables.
·
managers are accountable
for the time and cost of results/deliverables.
But architects
share responsibility for all three
facets of the results: quality, time and cost.
They must inform
managers about the qualities, time and cost of system/solution options, and
must be willing to accept leadership from managers on time and cost.
Not every change to business roles and processes is well called EA (to modify a business process performed by a few people in a sales department is more SA than EA).
Not every strategic IT plan is well called EA (to define a technology road map (e.g. for the use of Windows OS versions) is more IT planning than business system planning).
But the architecture work space covers all these things, this table positions processes and deliverables across the levels and breadth of the architecture work space.
|
An example of how responsibilities and
deliverables may be assigned to the work space – for you to extend or modify |
|||
|
Business view |
Information/data view |
Applications view |
Infrastructure Platform view |
|
Enterprise/Business Standardisation & integration of business roles & processes Business function/capability hierarchy Business products & services catalogue Business processes and roles Etc. |
Enterprise/Data Data standardisation & integration Data store & data flow catalogues Maps data to business functions Business data model & views of it Canonical data model(s) Core business data entity life cycles Etc. |
Enterprise/Apps Business app standardisation & integration Business app portfolio/catalogue Maps business apps to business functions Business app life cycles and road maps Etc. |
Enterprise/Platform Platform standardisation & integration Platform technology portfolio/catalogue Platform services portfolio/catalogue (TRM) Platform technology life cycles and road maps Etc. |
|
Solution/Business For a required system/solution: Business services Business processes and roles Mappings to goals & locations Requirements catalogues Use case diagrams and definitions Outline UI (or other I/O) designs Etc. |
Solution/Data For a required system/solution: Maps data to processes and roles Logical data models CIA requirements Data qualities/meta data Etc. |
Solution/Apps For a required system/solution: Maps use cases to processes and roles Maps business apps to use cases Design for NFRs Coarse-grained app components Coarse-grained sequence diagrams Etc. |
Solution/Platform For a required system/solution: Maps platform to business apps Platform technology definitions Client & server node definitions Design for NFRs Outline deployment diagrams Outline network diagrams Etc. |
|
Software/Business Detailed use case definitions Detailed UI designs Governs UI implementation Etc. |
Software/Data Detailed database design Detailed message design Governs database administration Etc. |
Software/Apps Detailed (fine-grained) software design Governs software development Etc.
|
Software/Platform Detailed deployment diagrams Detailed network diagrams. Governs platform and network configuration Etc. |
Few can afford to employ enterprise architects who work only at an abstract level on standards, principles, patterns, reference models and road maps.
It is normal for most architects to be engaged, at least part-time, in a governance or leadership role in one more solution delivery projects.
Managers have to determine the appropriate modus operandi for EA and SA:
· Do EAs lead and direct the SAs by defining projects in a top-down command and control style (the style assumed in TOGAF until recently)?
· Do EAs act more as a design authority - defining generic standards, principles, patterns, reference models and cross-project road maps - and governing their application to independently-generated solution delivery projects?
It helps if an architect’s role on a project is:
· expected, is naturally assigned when resourcing the project
· paid for by agreed mechanisms - be it project budget or central budget
· understood by people on the project - starting with the project manager
· held responsible for the quality of architecture description artefacts.
An architect team manager has to balance how each architect divides their time between:
· common good work – enterprise-wide standards, principles, patterns, reference models and other collateral
· advice and guidance - regarding specific visions and change requests
· shaping, leading or supporting specific delivery projects - perhaps several in parallel.
Enterprise architecture is likely to be more formally established in an organisation with some or all of the following:
· a need to standardise or integrate business processes and data across the enterprise
· a need to manage a substantial enterprise application portfolio
· a need to improve business applications or data quality
· a need to optimise, simplify or rationalise the IT estate.
Enterprise-wide standardisation and integration may not naturally excite business managers; they need to be persuaded of its benefits.
Typically, a business manager is aware of only a narrow slice of the enterprise architecture.
So, it helps if managers appreciate:
· the breadth of the business - typically shown in a business function/capability hierarchy,
· the application portfolio that supports the business - with costs, issues and opportunities,
· how far integration and standardisation are important to a business.
Ross, Weill and Robertson (in "EA as Strategy") prompt EAs to position an enterprise’s “operating model” in a quadrant of this grid.
|
An “operating model” for business processes and systems |
||
|
Low standardisation |
High standardisation |
|
|
High integration
|
Coordinated processes and systems |
Unified processes
and systems |
|
Low integration |
Diversified processes and systems |
Replicated processes
and systems |
Establishing the EA
agenda
The EA team is concerned with the enterprise-wide optimisation of business systems.
· To improve business system integrity - improve business data quality, relevance and use
· To help management understanding and impact analysis - maintain an abstract description of business roles and processes and the systems they use.
· To minimise business risks and maximise opportunities - keep an eye on system & technology evolution, and produce road maps where needed.
· To reduce TCO and complexity through reuse - tidy up the mess of systems by standardisation and integration.
· To increase agility and reduce time to market.
With the above aims in mind, EA values:
· Taking a cross-organisational view - over many local views
· Taking a strategic view – over tactical-only views
· Enabling business via IS and IT (alignment of the domains) – over single-domain thinking
· Abstract system descriptions - over very detailed or no documentation.
While there can be value in the items on the right, EA values the items on the left more.
EA always leans to the left, though not always strongly on every point.
Establishing EA governance
The job of the EA
is not necessarily to define solutions in the normal sense of that term.
EAs commonly act as design authorities for solutions outlined by SAs.
The EA role is much concerned with the definition and governance of generic
standards, principles, patterns and reference models - and with cross-organisational integration.
Of course, it is no use publishing standards, principles, patterns and references models with no way to see they are implemented.
Architecture frameworks like TOGAF recommend setting up an architecture board with executive-level representation, to give authority.
Then agreeing a contract/document at the start of each programme or project (signed by the relevant manager) that gives architects to right to govern that programme or project.
The contract defines the who, how, when and where of how that governance will happen.
The word “architect” comes from the Greek “master builder”.
In enterprise and solution architecture frameworks, the buildings are “systems”
“Enterprise architecture regards the enterprise as a system, or system of systems” (TOGAF)
“Architecture descriptions are formal descriptions of a system.” (ArchiMate®
2.1 Specification, The Open Group.)
Not just any old systems, but purposeful man-made activity systems, especially human and computer activity systems.
We don’t design people or computers; we specify activities to be performed, then organise actors (people and computers) to perform that behaviour.
Commonly, the structural elements of a system are called components or roles and the behavioural elements are called processes or services.
Enterprise and solution architects describe activity systems, maps describe only passive structures.
So an architecture framework is not much like cartography, but the analogy works up to a point.
Cartography is the study and practice of making maps; it combines science, aesthetics and technique.
It builds on the premise that reality can be modelled in ways that communicate spatial information effectively.
Similarly, architecture frameworks grew out of the study and practice of designing and building human and computer activity systems.
They combine information system science, graphical models and analysis and design techniques.
They build on the premise that activity systems can be modelled in ways that communicate system descriptions effectively.
The map is not the territory; a system description is not an operational system.
An architecture description is a subtype of system description that meets whatever criteria architects and stakeholders accept as definitive of “architecture description”.
The properties that qualify a system description as being an architecture description depend on which standard or method you choose to follow.
Zachman defines his architecture framework as
“A logical structure for classifying and organising the descriptive representations of an Enterprise that are significant to managers and to developers of Enterprise systems.”
The Open Group Architecture Framework (TOGAF) includes many definitions that align architecture with system description, including these:
· "Enterprise: The highest level (typically) of description of an organization and typically covers all missions and functions."
· "Architecture: 1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation..."
· "Solution Architecture: A description of a discrete and focused business operation or activity and how IS/IT supports that operation, typically applies to a single project or project release..."
· "Application Architecture: A description of the structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets."
Different sources use different terms for things, descriptions and processes for describing things.
|
Source |
Thing to be described |
Description / model of thing |
Description / modelling
process |
|
Cartography |
A territory |
Map |
Cartography |
|
OMG: Unified Modelling Language |
An event-driven system of actions |
Architecture |
Model-driven development |
|
ArchiMate Modelling Language |
A system of structural and behavioural elements |
Architecture |
|
|
The Open Group Architecture Framework |
An enterprise as a system |
Architecture / Architecture Definition Document |
Architecting / Architecture Development Method |
|
BCS Reference model for Enterprise and Solution Architecture |
An enterprise or solution as a system |
Architecture as description product |
Architecture as architecting process |
For
more on this theme, with reference to Zachman and TOGAF, read “Architecture
as system description”
Cartographers usually observe, classify, measure and document the properties of an existing territory.
They might instead envision a territory, and transfer envisioned properties from a mental model into a documented model.
Similarly, architects observe, classify, measure and document the properties of a current/baseline system.
And for a target system, they transfer required properties from mental models into documented models.
Different stakeholders have different concepts of a system to be built; their mental models are fragile, shifting over time, and inconsistent.
No one person has a concept or mental model that is consistent, coherent and persistent enough to merit being called the “architecture”.
Architects have to collate inconsistent and incoherent mental models to form one consistent and coherent set of documented models – in an architecture description.
The models documented in an architecture description are usually more abstract than models found in the most detailed system description.
The term “agile” means willing and able to speedily respond to change.
The term “architecture” is applied to higher level design in contrast to lower level design.
Higher level means more abstract - more coarse-grained, more generic, more logical.
Such a higher level abstraction is supposed to be more stable.
So the term “agile architecture” can be seen as an oxymoron.
An architecture should not need to be changed as much as or as often as a lower level design.
If it has to change a lot - then it may be regarded as a poor architecture.
Agility means different things at different levels of design, and requires different approaches.
Agility is not necessarily increased by widening the architecture remit.
EA is much about cross-organisational standardisation, integration and reuse.
· Standardisation widens the impact of a change to the standardised thing.
· Integration widens the scope and complexity of the system to be changed.
· Reuse of shared component/services ditto.
All of these things can hinder agility in some way, though perhaps increase it in another.
Agile software development projects must be constrained in some ways by enterprise architects.
One of those constraints is that the project should not conclude without producing architecture-level documentation.
Enterprise architecture is disabled if projects leave no descriptive artefacts behind them, or else leave different and incomparable artefacts.
Enterprise architecture needs the description of an enterprise application to be standardised, using artefacts such as:
· a solution outline document
· business process models
· a use case diagram, supported by use case definitions
· a logical data model.
· a deployment diagram
This documentation can be finalised alongside agile development, rather than before it starts.
Avancier methods include a library of architecture catalogues, matrices and diagram types.
For more about agile development, read papers at Complexity and Agility.
In the tables below, the left-hand side tends to be more abstract than the right-hand side.
The first table shows how the six design dimensions appear in TOGAF 9.1.
|
Higher level
design |
Design dimension in TOGAF |
Lower level design |
|
Enterprise / strategic architecture Segment architecture |
Longer
time --> Shorter time (Time dimension of architecture in TOGAF
Fig. 20-1) |
Segment
architecture Capability
architecture |
|
Enterprise / strategic architecture Segment architecture |
Composition
--> Decomposition (Level dimension of architecture in TOGAF
Fig. 20-1, 20-4) |
Segment
architecture Capability
architecture |
|
Foundation architecture Common systems architecture Industry architecture |
Generalisation
--> Specialisation (Enterprise Continuum TOGAF Fig. 20-2 &
40-3) |
Common systems
architecture Industry
architecture Organisation
architecture |
|
Requirements and context Architecture continuum Solutions continuum |
Idealisation
--> Realisation (Enterprise Continuum TOGAF
Fig. 39-1) |
Architecture continuum Solutions
continuum Deployed solutions |
|
Business services Information services Platform services (TRM) |
External
--> Internal (Content meta model TOGAF Fig. 34-8) |
Business
functions/capabilities Application
components Technology
components |
|
Business processes Business scenarios |
Behaviour
--> Structure (Architecture definition TOGAF Fig. 19-1) |
Application
components Technology
components |
The second table shows how three of the design dimensions appear in ArchiMate, the Zachman Framework and Model Driven Architecture (MDA).
|
Higher level
design |
Design dimension in OTHER FRAMEWORKS |
Lower level design |
|
Scope Contexts Business Concepts System Logic Technology physics |
Idealisation
--> Realisation (Rows of the Zachman
Framework) |
Business Concepts System logic Technology physics Tool components |
|
Platform-independent model (classes in
executable UML) |
Idealisation
--> Realisation (Model-Driven Architecture from the OMG) |
Platform-specific
model (implemented system) |
|
External services presented via interfaces |
External
--> Internal (Realisation
in ArchiMate) |
Internal processes
and components |
|
Transient services and processes |
Behaviour
--> Structure (Construction in ArchiMate) |
Persistent components, roles and interfaces |
|
Computation-independent model (use cases) |
Behaviour
--> Structure (Model-Driven Architecture from
the OMG) |
Platform-independent
model (classes in executable UML) |
Footnote: Creative Commons Attribution-No Derivative Works Licence
2.0 12/04/2015 21:40
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