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.



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.


What the report says about the state of the art 1

What the report says about architecture “domains”. 1

What the report says about architecture “types”. 2

What the report says about architecture levels. 2

What the report says about architecture time-scales. 3

Where does the report appear in EA history?. 3

Remarks. 4


What the report says about the state of the art

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.



Not much.

What the report says about architecture “domains”

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.



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).

What the report says about architecture “types”

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]



• 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.

What the report says about architecture levels

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.



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.

What the report says about architecture time-scales

Few projects should take more than one year, and most should be done in less than six months.



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.

Where does the report appear in EA history?

See EA history references.


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.