Dispersion
and Interconnection: Approaches to Distributed Systems Architecture
Final Report June 1986
from PRISM.
This page is published under the
terms of the licence summarized in the footnote.
Abstract
Enterprise architecture frameworks like FEAF
and TOGAF were developed to help architects work in a future that (after the
PRISM report) can be characterised as:
·
the
information age
·
increasingly
distributed systems
·
increasing
integration and standardisation of systems.
This future was recognised in the famous PRISM report in 1986.
It does not include the term EA, but the quotes below show the PRISM report fits neatly into the EA history you can read at avancier.website.
Contents
What
the report says about the state of the art
What
the report says about architecture “domains”
What
the report says about architecture “types”
What
the report says about architecture levels
What
the report says about architecture time-scales
Where
does the report appear in EA history?.
Traditional evaluation techniques fail for a variety of reasons:
• Applications and their requirements are not yet known
• Future vendor offerings and developments are unknown
• Evaluative criteria are unclear and undefined
• Often the alternatives being evaluated are sufficiently different in nature as to be impossible to compare.
The factors listed above lead us to the conclusion that uncertainty and ambiguity are part of the current environment for I/S organizations, and cannot be utterly defeated by even the most masterful architectural stroke.
HAVE THINGS CHANGED?
Not much.
There are four domains:
• Infrastructure - The underlying technological platform which supports data and applications, including hardware, systems software, and communications networks.
• Application software - The code which processes data for the organization, including acquired as well as internally developed programs.
• Data - The information assets of the organization.
• Organization - The people and structures that make it all work.
HAVE THINGS CHANGED?
The four domain have appeared in most EA frameworks ever since.:
• Infrastructure – much the same today - sometimes called platform or technology
• Application software - much the same today
• Data - much the same today – focused on digitised data
• Organization - now usually called business architecture - and focused business processes and roles (rather than individual people).
Four types of Architecture
• Inventory: A snapshot of the current state showing the architectural items in place today and their relationships.
• Principles: A statement of the organization's philosophy of information systems expressed in terms of objectives and goals in each domain area.
• Models: Pictures of the desired state, with emphasis on what goes where, and how it is all connected.
• Standards: Specific rules or guidelines for implementing the models [including technology standards]
HAVE THINGS CHANGED?
• Principles: a principle is seen as part of the context for architecture, more a requirement or constraint than an architecture type.
• Standards: ditto.
• Inventory: now called baseline architecture.
• Models: now called target architecture.
The level at which architecture should be done in the organization will vary.
In general, architecture should be done at the highest level for which there is consensus on principles.
If all divisional managers cannot agree on principles, there should not be a corporate architecture (unless the CEO can convince them to agree!)
Overly generic principles are a sign that the organizational level of the architectural effort needs to be lowered.
If the business units of a corporation are in different businesses, with different value chains and bases for competition, there is no reason why they should have the same architecture.
HAVE THINGS CHANGED?
Hmm…. the report doesn’t really address scoping and levelling issues, or assignment of
time, cost, resources to scopes and levels.
Nowadays, large enterprises usually distinguish:
· broad and strategic enterprise architecture
· narrower project-level solution architecture - sometimes on tactical or silo solution
And there is an
issue with enterprise-level “road maps” that was obscure in the PRISM paper
(and remains obscure in TOGAF today).
The report took
an enterprise/executive level view, encouraging the setting of enterprise-wide
principles and standards.
An aim of enterprise level thinking is to define long-term targets for an
enterprise's business processes, applications, and platform technologies.
Enterprise-level road maps are needed to reach these targets.
At the same time, many architects are employed to work on specific solutions
and silo systems, which have their own road maps.
In practice,
enterprise-level road maps can and often do cut across solution-level road
maps.
The challenge is to progress the former while many solution architects are
working to shape and steer specific systems and projects.
Compliance of a solution with EA standards and road maps can add to the time,
cost or resources needed.
So even where EA standards and road maps are in place, some SA may occur
outside of, or conflict with, the EA.
Few projects should take more than one year, and most should be done in less than six months.
HAVE THINGS CHANGED?
It isn’t clear where the starting point of this project is.
We may now distinguish the "architecture project" (phases A to F of TOGAF’s ADM) from the "implementation project" (phase G).
And assume there will be a higher level of enterprise architecture work, independent of specific projects.
The PRISM paper
was speculative, but much, including the division of architecture into four
primary domains, has stood the test of time.
But the report did not mention EA; and its discussion of architecture scoping
and levelling is weak.
All sources above place information system architecture at the heart of EA, and emphasise the breadth of scope.
Today, EA is supposed to take a holistic view of the whole enterprise – all its core business processes and information needs.
EA is not anything that a business management consultant might do to implement a business decision.
EA is more than business analysis to address a given problem or requirement.
EA is
cross-organisational business system planning, with a view to standardisation
and integration of systems.
Systemisation
involves defining core
business processes and the resources needed to perform
them.
Resources include the roles and information needed
to support and enable
business processes.
You can't integrate business processes without passing business data between roles and activities.
And you can't standardise business processes unless the actors in those processes are monitored and/or directed by systems.
The PRISM report says: “No one, to our knowledge, has ever explicitly and formally employed this complete approach to architecture.”
Today, has anybody standardised and integrated their systems to the extent that might be envisaged by an EA team?
Probably not, but tidying up the mess of business systems remains an ambition.
Published
under the Creative Commons Attribution-No Derivative Works Licence 2.0 04/12/2014
20:04
Attribution: You
may copy, distribute and display this copyrighted work only if you clearly
credit “Avancier Limited: http://avancier.co.uk” at the start and
include this footnote on each page.
No Derivative
Works: You may copy, distribute, display only complete and verbatim copies of
this paper, not derivative works based upon it – unless you have permission from the author.
For more about
the licence, see http://creativecommons.org.