Enterprise Architecture Framework
Title:
Version:
Status:
Date:
Author:
Enterprise Architecture Framework
2.0
ISSUED
22/06/12
David Deighton, IT Services
OPEN
Enterprise Architecture Framework
Contents
1
2
Executive Summary .............................................................................................................................. 3
Introduction ........................................................................................................................................... 4
2.1
Revision History ............................................................................................................................. 4
2.2
Background .................................................................................................................................... 4
2.3
Scope ............................................................................................................................................. 4
2.4
Purpose .......................................................................................................................................... 5
2.5
Glossary ......................................................................................................................................... 5
2.6
References ..................................................................................................................................... 5
2.7
Time Line ....................................................................................................................................... 6
3
Enterprise Architecture Framework ....................................................................................................... 7
3.1
Architecture Process ...................................................................................................................... 7
3.2
Governance.................................................................................................................................... 9
3.3
Architecture Principles .................................................................................................................... 9
3.4
Process Comparison .................................................................................................................... 13
3.5
Design Objectives ........................................................................................................................ 14
3.6
Architecture Compliance Review .................................................................................................. 14
3.7
Operational Testing ...................................................................................................................... 15
3.8
Architecture Team ........................................................................................................................ 15
4
Reference Models ............................................................................................................................... 16
4.1
Technical Reference Model (TRM) ............................................................................................... 16
4.2
Standards Information Base (SIB) ................................................................................................ 16
4.3
Target Architecture Model (TAM).................................................................................................. 18
4.4
Patterns ........................................................................................................................................ 18
Appendix A – Basic Concepts for Architectural Description ........................................................................ 19
Appendix B – Archimate Diagram Notation ................................................................................................. 20
Appendix C – Standard Agenda for Architecture Compliance Review ........................................................ 21
Figures
Figure 1 Enterprise Architecture ....................................................................................................................................... 4
Figure 2 Architecture Process ........................................................................................................................................... 7
Figure 3 Enterprise Architecture Principles ...................................................................................................................... 9
Figure 4 Process Comparison ......................................................................................................................................... 13
Figure 5 Verification Diagram ........................................................................................................................................ 15
Figure 6 Relationships between Models ......................................................................................................................... 16
Figure 7 TOGAF Technical Reference Model................................................................................................................ 16
Figure 8 Basic Ontology for Systems Architecture ........................................................................................................ 19
Figure 9 Archimate Diagram Key ................................................................................................................................... 20
IT Services / Document1 / ISSUED / v 2.0
Page 2 of 21
OPEN
Enterprise Architecture Framework
1 Executive Summary
This document proposes an Enterprise Architecture Framework consisting of a methodology, a conceptual framework
and a process that will build on the foundations laid down in the University’s IT Strategy. The advantages of this
approach are:
 Close alignment of technology utilisation with the needs of the business.
 The establishment of a rational basis for technical decision making.
The conceptual framework and methodology are based on The Open Group Architecture Framework (TOGAF)
version 9 and use the semantic model for systems architecture defined in IEEE 1471-2000 standard ‘Recommended
Practice for Software-Intensive Systems’ and the INCOSE Systems Engineering Handbook.
The Architecture Process provides for the creation of a vision and for the development of an architecture vision that
realises the IT Strategy. The vision will include business, application, data and technology architecture layers
followed by migration planning, implementation governance and change management that works in conjunction with
the Prince II project management process defined in the University’s Project Management handbook. The
Architecture Process emphasises requirements management at every stage and includes governance via existing
oversight bodies overseen by the IT Strategic Planning Group.
A repository will be created that will contain architecture models, standards, policies, procedures, guidelines and road
maps. Though initially made available as a web site or shared folder, the repository will be hosted on the University’s
chosen collaboration and content management system and will make extensive use of collaboration tools such as wiki,
bulletin boards etc.
All projects will be required to complete an Architecture Compliance Form (ACF), or Architecture Description (AD
for major projects and programmes), early in the project lifecycle whose purpose is to ensure alignment with the IT
Strategy. The ACF documents how the project will conform to the Architecture Principles and Requirements.
New emphasis will be placed on non-functional requirements and on the obligation to demonstrate compliance
through operational testing.
Toward the end of the Implementation Phase of a project, an Architecture Compliance Review will be held to verify
that the project has delivered according to the agreed architecture. Significant deviation, or failure to complete
operational testing, will result in the raising of new project risks and issues in the appropriate logs for the attention of
the Project Board. Unresolved concerns, such as major security vulnerabilities, may delay the launch of a system.
The Enterprise Architecture Framework will deliver the following benefits:
 Alignment of projects and technology selection with the IT Strategy
 Increased agility through greater flexibility, standardisation and rationalisation
 Economies of scale through standardisation and focus on total cost of ownership.
IT Services / Document1 / ISSUED / v 2.0
Page 3 of 21
OPEN
Enterprise Architecture Framework
2 Introduction
2.1 Revision History
Issue
1.0
2.0
Author
David Deighton
David Deighton
Issue Status
Issue 1
Revised and updated
Date
17/09/11
22/06/12
2.2 Background
Enterprise Architecture (EA) is a discipline that defines and maintains the architecture models, governance and
transition initiatives needed to effectively co-ordinate disparate groups towards common business and IT goals. It
translates business vision and strategy into effective enterprise change by creating, communicating and improving the
key requirements, principles and models that describe the enterprise's future state and enable its evolution. The scope
of the enterprise architecture includes: the people, processes, information and technology of the enterprise, and their
relationships to one another and to the external environment.
Figure 1 Enterprise Architecture
There is no shortage of EA frameworks in the IT industry, Zachman was the first to formalize the concept and publish
a framework. Since then, many other EA frameworks have been published and are used by many organisations like:
 FEAF – US Federal Enterprise Architecture Framework
 DoDAF/MoDAF – US Department of Defence / Ministry of Defence Architecture Framework
 TOGAF – The Open Group Architecture Framework
 IAF – Capgemini Integrated Architecture Framework
The adoption of an architecture driven approach and architecture group was identified as one of the enablers needed to
realise the University’s IT Strategy.
2.3 Scope
This document presents an enterprise architecture framework for the University – the ‘Birmingham Enterprise
Architecture Framework’ – based on TOGAF version 9. However the focus is not on frameworks but on delivering
business value and on standards and artefacts that contribute directly to it.
IT Services / Document1 / ISSUED / v 2.0
Page 4 of 21
OPEN
Enterprise Architecture Framework
The orientation of the University’s EA programme is toward the future state, or ‘vision’, and ways of realising it
through coordinated IT and business projects while allowing for future growth and change in response to the needs of
the University.
2.4 Purpose
This document represents a starting point for the introduction of an Enterprise Architecture based approach. It is
intended to show how the IT Strategy flows down into the enterprise architecture and how enterprise architecture will
contribute to the realisation of the IT Strategy.
2.5 Glossary
Term
ACF
ADM
EA
EAF
IEC
IEEE
INCOSE
ISO
ITS
MTBF
NFR
PID
SIB
SOA
TAM
TOGAF
TRM
XML
Description
Architecture Compliance Form.
Architecture Development Method – TOGAF.
Enterprise Architecture.
Enterprise Architecture Framework
International Electrotechnical Commission.
Institute of Electrical and Electronics Engineers, IEEE Standards Association
International Council on Systems Engineering.
International Standards Organisation.
IT Services department.
Mean Time Between Failures.
Non-functional requirement(s).
Project Initiation Document.
Standards Information Base – TOGAF.
Service Oriented Architecture
Target Architecture Model.
The Open Group Architecture Framework.
Technical Reference Model – TOGAF.
Extensible Markup Language.
2.6 References
Reference
IT Strategy
INCOSE Systems Engineering
Handbook
Architecture Principles
Archimate
Document
IT Strategy 2010-2015 v1.13 2011
INCOSE Systems Engineering Handbook v3.2.1 2011
Enterprise Architecture Principles v0.1 2011
Archimate 1.0 Specification – The Open Group 2009
IT Services / Document1 / ISSUED / v 2.0
Page 5 of 21
OPEN
Enterprise Architecture Framework
2.7 Time Line
The EAF management structures, process and artefacts will be introduced gradually as part of the ongoing IT Strategy
communication and realisation process:
1. August/September 2011 – communication of the framework within IT Services and the issue of Architecture
Principles and Standards for internal review. At the end of the review process, these artefacts will be formally
adopted and published via the repository.
2. October 2011 – creation of Architecture Compliance Forms for new projects from a date to be determined and
the start of the Implementation Governance.
3. October 2011 – go live with the EA framework and processes.
4. October 2012 – review and revise as necessary.
IT Services / Document1 / ISSUED / v 2.0
Page 6 of 21
OPEN
Enterprise Architecture Framework
3 Enterprise Architecture Framework
3.1 Architecture Process
The following diagram illustrates the architecture process, based on the TOGAF Architecture Development Method
(ADM), the activities within it and the major inputs and outputs:
Figure 2 Architecture Process1
Business
Process
Define application architecture including services, major functions, components
and interfaces and show how these map to the Business Architecture. Develop
logical data models and map to the information models in the Business
Architecture.
Business
Architecture
Compliance Review Process
A critical stage in Implementation Governance consists of a formal Architecture
Compliance Review to be held toward the end of the Implementation Phase of a
project. The principal input to the review will be the Architecture Compliance
Form or Architecture Description.
Application
Architecture
Architecture
Principles
Representation Enterprise Architecture Principles based on the IT Strategy and industry best
practice. The principles apply to all IT projects and architecture-related work.
Architecture
Process
Business
Process
Architecture Vision Business
Process
1
Generic architecture process based on TOGAF 9
Set the scope, constraints and expectations for a project or initiative. Create the
architecture vision, based on the Architecture Principles, which realises the IT
Strategy, aspirations and needs of the University. Initiated by a Request for
architecture work or via completion of a previous iteration, this activity begins
an iteration of the architecture development cycle. For projects, this usually
See Appendix B – Archimate Diagram Notation for key to diagram symbols.
IT Services / Document1 / ISSUED / v 2.0
Page 7 of 21
OPEN
Enterprise Architecture Framework
begins in the project Start Up phase and continues into the project Initiation
phase with the delivery of the Architecture Compliance Form (ACF) that
summarises the proposed solution. Development of the vision usually involves a
rapid iteration through high-level business, application and technology
architecture activities and results in one or more architecture models to be added
to the repository.
Business
Architecture
Business
Process
Elaborate business architecture based on the identified business processes,
stakeholders, services and capabilities. The principal technique will be Business
capability Modelling (BCM) used in combination with business process models
(using Triaster Process Navigator). Develop high-level information models that
reflect the underlying enterprise-level informational structures and entities.
Change
Management
Business
Process
Changes to the architecture should be managed in the same way as any other
system or infrastructure change – using the established IT Services change
control mechanisms and subject to approval by the Change Board. Architecture
Change Management is part of the ITIL Change Management process.
Enterprise
Architecture
Framework
Representation The overarching Enterprise Architecture document that describes the structure
and scope of the Enterprise Architecture programme at the University.
Implementation
Assurance
Business
Process
The Architects will provide ongoing guidance and governance throughout the
implementation phase of a project or programme. The basis for governance
activities will be the Architectural Principles, Standards and Reference Models
that constitute the architecture framework and the compliance of projects as
documented in the project Architecture Compliance Form (ACF).
IT Strategy
Business
Object
University IT Strategy
ITIL Change
Management
Business
Process
Migration Planning Business
Process
Analyse cost, benefits and risk. Develop detailed implementation and migration
plan. The architects will support the project team as necessary.
Opportunities and Business
Process
Solutions
Perform implementation planning and identify delivery vehicles for the building
blocks derived from the preceding phases.
Preliminary
Business
Process
Prepare the organisation to undertake successful architecture projects through
the introduction of an architecture framework and process based on the
University’s approved IT Strategy. This activity includes the creation of a set of
Architecture Principles and the setting-up of a shared architecture repository.
Requirements
Management
Business
Process
The process is based on requirements management. Requirements are identified,
stored and input to all activities in the architecture process. This activity is of
fundamental importance and needs a rigorous approach, preferably tool-based.
Specific and testable non-functional requirements must be defined for every
system. These constitute design objectives and effectively determine the type of
system that will be delivered.
Technical
Standards
Business
Object
Standards Information Base (SIB) containing technical and related standards.
Technology
Architecture
Business
Process
Define the infrastructure including computing platforms, storage, networks,
operating system, middleware, database systems, other system software and
deployable artefacts. Map them to the Application architecture to show how the
components, data stores and so-on will be realised. This layer of architecture
also encompasses the physical data models and XML schemas that are directly
implemented though these will normally be created by the project team
IT Services / Document1 / ISSUED / v 2.0
Page 8 of 21
OPEN
Enterprise Architecture Framework
3.2 Governance
Enterprise Architecture governance is performed via the three IT Services governance bodies – Information Security
Steering Group (ISSG), Business Systems Steering Group (BSSG) and IT Infrastructure Group (ITIG) under the
overall purview of the IT Strategy Planning Group.
3.3 Architecture Principles
The principles constitute a basic reference point for every IT project and initiative and are drivers for architecture
governance. Each new project will be expected to explain how they will conform to the principles and where not, why
not. Conformity with the principles will be evaluated before a new application or product is launched and may result
in new risks or issues being raised.
Figure 3 Enterprise Architecture Principles
The principles have been allocated to IT Strategy themes and coloured according to where their main benefits lie.
Principle
Rationale
Business
BUS1
Promote Innovation
Innovate for competitive advantage and
productivity.
BUS2
Business Priority
Support and promote the University’s enterprise
vision, business strategies and plans.
BUS3
Optimise Benefit
Maximize the overall benefit to the University by
balancing business and technology factors.
BUS4
Partnership
Every IT investment will have a business owner
and an IT steward
Helps realise competitive advantage and drives
improvements in efficiency and productivity.
Architecture gives most benefit when closely aligned with
business strategy and goals.
The optimal solution for a given project may not yield the
highest overall benefit for the University as a whole.
Business and IT must work cooperatively to realise the
benefits of IT investments.
IT Services / Document1 / ISSUED / v 2.0
Page 9 of 21
OPEN
Enterprise Architecture Framework
BUS5
Principle
Deliver Information via Multiple Channels
Make information available over multiple
channels such as personal or laptop computers,
smart phones, tablet computers and other devices.
Rationale
Allows the University to work smarter and improves
general productivity.
Information
INF1
Business Authority
Ensure there is a designated business owner for
all business information with authority over its
creation, change, access and deletion.
INF2
Ensure Data Integrity
Capture business data once at the point of creation
and manage it actively throughout its life cycle up
to and including eventual disposal.
INF3
Treat Data as an Asset
Organize and manage data to maximise its value
to the University.
INF4
Classify Data
Apply a coherent classification scheme and
manage data accordingly.
INF5
Promote Data Independence
Decouple data from applications and, where
feasible, make it available over standardised
interfaces.
Those with the most knowledge of the data have the best
chance of and most interest in getting it right. Integrity is
improved and maintenance is simplified.
Promotes the accuracy and consistency of data and the
efficiency of data management processes.
Organizing and managing the key data assets of the
University drive the business processes needed to run the
enterprise.
Different classes of data need to be managed, stored,
protected and disposed of appropriately. The classification
scheme should be fine-grained enough to deliver tangible
benefits.
Insulating consumers of enterprise data from its structure
and origin reduces complexity and lowers the maintenance
overhead of changes.
Application
APP1
Focus on Services
Prefer loosely-coupled, modular components that
implement services.
APP2
Maximise Reuse
Design and implement reusable components.
APP3
Rationalise and Simplify
Eliminate duplication and reduce complexity.
APP4
Use Proven and Manageable Components
Select market-leading products and reuse proven
bespoke components where appropriate
Resilience, flexibility, performance and scalability are
improved by minimising interdependencies.
Reduces development costs and time; leverages investments
in existing systems and improves the ability to adapt to
changing requirements.
Lowers costs through economies of scale and reduces
overhead of managing complexity.
Reduces risk and frees-up development resources to focus
on areas where competitive advantage is available.
Service Oriented Architecture (SOA)
Applies to SOA with appropriate middleware and infrastructure; embodies good practice for application component design.
SOA1
Design for Reuse
Define services that are internally consistent, selfcontained and independent from other services.
SOA2
Assemble with Other Services
Design ‘plug and play’ services that are useful to
the largest number of potential consumers.
SOA3
Design for Interoperability
Provides the largest unit of functionality that may be useful
in different contexts.
Services may be assembled to create new services and
applications – sometimes in unforeseen ways.
Permits reuse across different environments.
Use common standards for the exposure and use
of services.
SOA4
Design for Understandability
Ensure the service is comprehensible in its own
right without reference to other services.
SOA5
Hide Internal Details
Potential consumers are more like to use a service if it
performs a clearly defined and understandable function.
Avoids implicit dependencies in service consumers and
Design interfaces separately from the service
IT Services / Document1 / ISSUED / v 2.0
Page 10 of 21
OPEN
Enterprise Architecture Framework
Principle
implementation – both functionality and data.
SOA6
Keep Error Conditions Private
Discreetly inform consumers of business error
conditions. Ensure services always maintain data
integrity. Keep error conditions within the
service.
SOA7
Address a Distinct Problem
Rationale
cooperating services.
Limits the direct impact of errors and decouples the service
consumers; thus avoiding the ‘cascading errors’ syndrome.
Ensures that the service is self-contained and independent.
Restrict the scope of the service to a distinct and
well-defined problem domain.
Security
SEC1
Accountability
All user and system interactions and access to
information must be attributable to authenticated
(reliably identified) people, organisations or
systems.
SEC2
Least Privilege
When allowing access to a resource, assign the
minimum necessary privileges to complete the job
in hand.
SEC3
Defend in Depth
Do not rely on a single control but erect a
succession of barriers that an intruder must
overcome before gaining access.
SEC4
Assume Insecure Communications
Data is vulnerable while in transit and must be
adequately protected to preserve its
confidentiality, integrity and availability..
SEC5
No Security by Obscurity
Security must be designed-in and not rely on
hiding information.
SEC6
Transparency
Controls should not impair the ability of the
University to function or unnecessarily restrict the
availability of information.
The University must maintain traceability and nonrepudiation of responsibility for access and changes for
legal and moral reasons.
Reduce the possibility that users or systems will abuse the
privileges granted them to make unforeseen changes or gain
unauthorised access.
No single security mechanism can be guaranteed
unbreakable, therefore good practice is to implement
multiple overlapping controls where feasible.
Internal networks should be considered hostile
environments for data and mitigated by authentication,
encryption and other controls.
Security should not be compromised by the release of
network diagrams, system specifications or CMDB
information.
Security controls should promote the availability of
information subject to protection of its confidentiality and
integrity.
Environment / Green IT
ENV1
Virtualise Infrastructure
Remove the dependencies that link systems to
specific hardware devices – includes server
virtualisation, network addressing etc.
ENV2
Promote Thin Client
Prefer web-browser based applications that do not
rely on specific components or applications that
must be deployed to the user work station.
ENV3
Apply Capacity Planning
Ensure infrastructure is sized appropriately to
meet the non-functional requirements and allow
for predictable growth. Do not over-specify.
Virtualisation promotes flexibility, allows more efficient
use of hardware resources and reduces energy consumption.
Browser-based applications are easier to deploy and
manage. Thin client reduces the need for client-side
hardware resources.
Oversized infrastructure wastes money and increases
energy consumption.
Technology
TEC1
Adopt and Enforce Standards
Formally adopt technical standards and select
preferred products. Non-compliance needs to be
justified and explained.
Standardisation helps achieve economies of scale, reduces
complexity and improves flexibility.
IT Services / Document1 / ISSUED / v 2.0
Page 11 of 21
OPEN
Enterprise Architecture Framework
TEC2
Principle
Monitor Services and Infrastructure
Deploy automatic monitoring tools that cover
application and data services as well as the
underlying infrastructure.
TEC3
Tiered Architecture
Separate concerns through tiered architecture.
TEC4
Plan for System Life Cycle
Consider complete life cycle through Retirement.
Rationale
Reduce down time and the unavailability of services due to
failures or exceptions – hardware and software.
Improves security, scalability, resilience and promotes more
efficient platform utilisation.
Total cost of ownership should include the impact of
Retirement or Closedown and allow for any intervening
upgrades and changes.
IT Services / Document1 / ISSUED / v 2.0
Page 12 of 21
OPEN
Enterprise Architecture Framework
3.4 Process Comparison
The Architecture Process covers architecture work at the enterprise level as well as at the project or solution level. The following diagram maps it to the Prince II Project
Management Process, the ISO/IEC 15288 standard for Systems Lifecycle Processes and ITIL Version 3.
Figure 4 Process Comparison1
While the project life cycle, of course, ends with system go-live, the other processes shown in the diagram must continue for the entire life cycle of the system. ISO/TEC
15288 is a generic system life cycle model used in many industries and is not limited to IT. It provides explicitly for system Retirement which is covered by Architecture
Change Management (TOGAF) and Service Operation (ITIL).
TOGAF and ITIL also cover the initial strategy phase while ISO 15288 is repeated for every system.
IT Services / Document1 / ISSUED / v 2.0
Page 13 of 21
OPEN
Enterprise Architecture Framework
3.5 Design Objectives
Architecturally significant requirements mainly fall into the non-functional category but may also include functional
requirements in some cases. Non-functional requirements for systems should be based on the following design
objectives:
Objective
Definition
Measurement
L = latency – response time
The speed at which the system performs a function
J = jitter - % variation in L
that meets business requirements and user
Performance
H = headroom - % available spare
expectations.
capacity.
SF = scalability factor in the range 0..1
– ratio of total load capacity and
available hardware resources.
The ability of the system to handle increasing or
decreasing volumes of transactions, services and
Scalability
SL = scalability limit – the maximum
data.
loading capacity of the system that is
inherent in, or a consequence of, its
design.
The readiness of the system to perform its functions % of target availability e.g. 99.98% of
Availability
when needed in spite of errors and exceptions.
24 x 7 and / or MTBF.
The ability of the system to fit smoothly into its
High – Medium – Low
Operability
environment and behave predictably.
Users’ perceptions of an application’s usefulness,
usability, and desirability based on the sum of all
High – Medium – Low
Usability
direct and indirect interactions.
The ability to control, or prevent, unauthorised
High – Medium – Low
Security
access to information.
Degree of conformity with laws and regulations.
High – Medium – Low
Regulation
Ease of change to meet changing business
High – Medium – Low
Flexibility
requirements.
The ability of the organisation to deliver the system
subject to constraints of available expertise,
High – Medium – Low
Feasibility
technology, time and resources.
3.6 Architecture Compliance Review
The Architects will be responsible for architectural governance throughout the project life cycle and will organise a
formal Architecture Compliance Review (ACR) meeting toward the end of the Implementation phase of a project –
preferably when the results of the operational testing are known.
The purpose of the ACR is to verify that the project has not deviated from the agreed architecture described in the
SAD and that the system is fit for purpose, conforms to standards and adheres to the Architectural Principles.
Compliance Reviews will be based on a standard agenda and standard terms of reference, which will be published in
the Architecture Repository. The attendees should include:
1. Chief Architect / Security Manager – organises and chairs the meeting and is responsible for the minutes.
2. Quality Manager – or nominated representative.
3. Technical Lead – for the project (can be more than one person) and/or
4. Project Manager – if appropriate.
5. Experts – from within IT services (e.g. infrastructure or development specialist) as appropriate to the project.
Preferably from outside the project team.
The Architect will prepare a slide pack and circulate it to the attendees in advance of the meeting, together with any
supporting documentation including the ACF. If the meeting runs out of time to cover the full agenda, a follow-up
meeting will be scheduled.
IT Services / Document1 / ISSUED / v 2.0
Page 14 of 21
OPEN
Enterprise Architecture Framework
After the meeting, minutes will be circulated to the attendees to give them the opportunity to correct any errors or
misunderstandings. The minutes will include the results of the meeting:
1. Recommendation – to proceed or stop.
2. Risks and Issues – to be recorded in the project Risk Log and Issues Log. These will need to be raised to the
ITPCG and may cause delay to the system go-live date or result in an agreed work-off list of actions to be
completed before the project can be officially closed. Important issues such as major security vulnerabilities
may prevent the system from going live at all.
3.7 Operational Testing
Successful completion of operational testing is a requirement for conducting an Architecture Compliance Review. If
lacking then the Architects should update the project risk or issues log to the effect that the system may not meet its
operating criteria, and this should also be reflected in the ACR minutes.
If possible, operational testing should take place directly in the live environment, or in a controlled environment that
closely resembles it. If the testing environment is not full-sized, then it should be appropriately sized so that the
results can be extrapolated by applying a simple multiplier (however threshold effects may invalidate this approach in
some cases). Server virtualisation will make the process of testing in the live environment easier by providing the
ability to dynamically relocate and duplicate (clone) virtual machines.
Figure 5 Verification Diagram1
3.8 Architecture Team
The Architects within IT Services are primarily responsible for the enterprise architecture of the University and for
managing the Architecture Process (Figure 2 Architecture Process). There will eventually be a team of architects,
including the following roles:
1. Chief Enterprise Architect - enterprise architecture vision, business, application and technology; architecture
management; information security.
2. Information Architect – enterprise information modelling, ontology, classification, perception.
3. Data Architect – enterprise and application data modelling, data management and utilisation.
4. Solution Architects – solution design over multiple architecture domains.
IT Services / Document1 / ISSUED / v 2.0
Page 15 of 21
OPEN
Enterprise Architecture Framework
4 Reference Models
Figure 6 Relationships between Models1
4.1 Technical Reference Model (TRM)
The purpose of the TRM is to be a classification scheme for standards, selected products and components The
following diagram shows the default TRM from TOGAF but it is likely that this will expand and change to fit the
needs of the University.
Figure 7 TOGAF Technical Reference Model
4.2 Standards Information Base (SIB)
A Standards Information Base (SIB) will be established that lists the industry standards, products and components that
have been selected and approved for use by IT Services. The SIB will be a part of the Architecture Repository that is
published to the University as a whole.
A formal standards approval process will be implemented in IT Services.
The SIB will be organised into categories based on the Technical Reference Model (TRM), described in section 4.1.
The following example shows entries from a typical SIB implementation.
IT Services / Document1 / ISSUED / v 2.0
Page 16 of 21
OPEN
Enterprise Architecture Framework
Standard
Description
REST
Proposed: 2011
Representional State Transfer
REST-style architectures consist of clients and servers. Clients
initiate requests to servers; servers process requests and return
appropriate responses. Requests and responses are built around the
transfer of representations of resources. A resource can be
essentially any coherent and meaningful concept that may be
addressed. A representation of a resource is typically a document
that captures the current or intended state of a resource.
The client begins sending requests when it is ready to make the
transition to a new state. While one or more requests are
outstanding, the client is considered to be in transition. The
representation of each application state contains links that may be
used next time the client chooses to initiate a new state transition
SOAP
Proposed: 2011
Simple Object Access Protocol
SOAP, originally defined as Simple Object Access Protocol, is a
protocol specification for exchanging structured information in the
implementation of Web Services in computer networks. It relies
on Extensible Markup Language (XML) for its message format,
and usually relies on other Application Layer protocols, most
notably Hypertext Transfer Protocol (HTTP) and Simple Mail
Transfer Protocol (SMTP), for message negotiation and
transmission. SOAP can form the foundation layer of a web
services protocol stack, providing a basic messaging framework
upon which web services can be built. Usually considered an
alternative to REST, but may be used for different parts of the
same architecture.
Version
Usage
References
N/A
Web Services
https://www.ibm.com/developerworks/we
bservices/library/ws-restful/
N/A
Web Services
IT Services / Document1 / ISSUED / v 2.0
Page 17 of 21
OPEN
Enterprise Architecture Framework
4.3 Target Architecture Model (TAM)
The TAM will show the preferred ‘to be’ architecture for the University. It will show not only technology choices but
also the full panoply of application functionality, components and data stores mapped to the University’s business
processes and enterprise information model. The TAM will show traceability from the business needs through the
architectural layers.
4.4 Patterns
An ongoing activity of the Architects will be to document architectural patterns of various kinds and publish them in
the Architecture Repository so that they can be reused in the future. Many patterns already exist and only need
collecting together.
Patterns represent high-level reuse as opposed to low-level reuse in the form of directly reusable components.
Types of patterns:
1) Business Services and Collaborations – combining business processes, business services, collaborations and
products.
2) Information and Data – common patterns in data models and in the management and organisation of data.
3) Application – common application design structures and relationships such as layering, web presentation,
concurrency, distributed components.
4) Technology – common software stacks, hardware, standard builds, architectural tiering etc.
5) Process – reusable processes and activity definitions.
IT Services / Document1 / ISSUED / v 2.0
Page 18 of 21
OPEN
Enterprise Architecture Framework
Appendix A – Basic Concepts for Architectural Description
Figure 8 Basic Ontology for Systems Architecture1
Architectural Description
Architecture
Concern
Environment
Library Viewpoint
Mission
Model
Rationale
Stakeholder
System
View
Viewpoint
A collection of artefacts that document the architecture of a system.
The organisation of a System in terms of components, their relationships to each other
and the environment.
Stakeholders’ interest in the development, operation or key characteristic such as
performance, reliability, security etc.
The environment, or context, of the system including the business and technical
aspects.
A reusable template for a Viewpoint that is stored in a library or repository.
The purpose of the system, such as the realisation of a defined service.
A diagram or other type of model that constitutes or is part of a View.
The justification, or reasoning behind, the Architecture, from the Architectural
Description.
A person who has a key role in, or Concerns about, a System.
A collection of components organised to accomplish the defined Mission. The term is
recursive and may also refer to a component or a ‘system of systems’.
A representation of a System from the perspective of a related set of Concerns.
The perspective from which a View is taken, the template for a View.
IT Services / Document1 / ISSUED / v 2.0
Page 19 of 21
OPEN
Enterprise Architecture Framework
Appendix B – Archimate Diagram Notation
Figure 9 Archimate Diagram Key
IT Services / Document1 / ISSUED / v 2.0
Page 20 of 21
OPEN
Enterprise Architecture Framework
Appendix C – Standard Agenda for Architecture Compliance Review
Introduction
General welcome and terms of reference for the meeting.
Project Summary
A description of the changes implemented by this project.
Architecture
Walk through the Architecture Compliance Form (ACF) or Architecture Description, including:
 Mission or purpose of the system.
 Architecture Principles – relevance and how realised.
 System Quality Attributes / Design Objectives.
 Data Utilisation – CRUD matrix.
 Interfaces.
 Security Architecture.
 Technology Stack.
 Environments
 Road Map.
Road Map
The time line for implementation and launch with any dependencies on other projects, infrastructure or business
events.
Concerns
Architectural, security or other concerns that may spawn risks, issues and remedial work.
Exceptions
Documented exceptions to the Principles, Standards etc.
Questions
Discussion and Q & A.
Decisions
Recommendation to proceed or not with any agreements on remedial work or other actions to be taken before or
after the launch. Risks and issues to be added to the project registers.
 Architecture sign-off.
 Security sign-off.
IT Services / Document1 / ISSUED / v 2.0
Page 21 of 21