Reference Architecture Framework

Reference Architecture Framework
Reference Architecture Guidelines

DOCUMENT NAME:
REFERENCE Architecture Framework.docx
DOCUMENT VERSION:
1.0
DOCUMENT STATUS:
APPROVED
CLASSIFICATION:
INTERNAL
AUTHOR(S):
ARTHUR THEOFILAS
DATE:
1 OCTOBER 2012
READERSHIP:
IT&S ARCHITECTURE & DESIGN PROFESSIONALS
SUMMARY:
THE OBJECTIVE OF THIS DOCUMENT IS TO PROVIDE THE ASSOCIATED INFORMATION AND TO

ACT AS A USEFUL GUIDE AND PROVIDE DIRECTION ON THE DEVELOPMENT AND USE OF
REFERENCE ARCHITECTURES.

Document Control
AMENDMENT HISTORY
Version
0.1
Date
MAY-12
0.2
JUL-12
0.3
JUL-12
0.4
JUL-12
1.0
Aug12
Comment
Initial Draft
Updated with feedback from
segment tags and peers
Minor update to repository
information and Reference
Architecture Template
Reference Architecture
Template updated with
example diagrams
Reference Architecture
Template updated.
Author
A. Theofilas
Role
Enterprise Architect
A. Theofilas
A. Theofilas
A. Theofilas
A. Theofilas
ASSOCIATED DOCUMENTS
Document Name
Version
Author
Date
REVIEW/APPROVAL
Reviewer/Approver
Chris Eaton
James Evans
PAGE: 2/26
Role
Head of Solution Architecture
Strategy & Enterprise Architecture
Director
Strategy & Enterprise Architecture
DOCUMENT: REFERENCE Architecture Framework.docx

BP INTERNAL BP INTERNATIONAL LIMITED 2012
Date
20-Aug-2012
20-Aug-2012
LAST SAVED: 1 OCTOBER 2012

Table of Contents
1
2
Executive Summary ................................................................................................................ 4

Reference Architectures ......................................................................................................... 5
2.1
Introduction ..................................................................................................................... 5
2.2
Why do we need Reference Architectures ...................................................................... 7
2.3
Reference Architecture Linkage ...................................................................................... 8
2.4
Reference Architecture context ....................................................................................... 9
2.5
How Reference Architectures are created ..................................................................... 11
2.6
Reference Architecture Readership ............................................................................... 12
2.7
Reference Architecture Linkage .................................................................................... 12
3
Reference Architecture Hierarchy ......................................................................................... 15
3.1
Reference Architectures ................................................................................................ 16
3.1.1
Conceptual Architecture ........................................................................................ 16
3.1.2
Logical Architecture ............................................................................................... 16
3.1.3
Solution Architecture ............................................................................................. 16
4
Reference Architecture Framework ...................................................................................... 17
4.1
Reference Architecture Development Framework ......................................................... 17
4.2
Reference Architecture Lifecycle ................................................................................... 18
4.2.1
Initiate .................................................................................................................... 18
4.2.2
Research................................................................................................................ 18
4.2.3
Draft ...................................................................................................................... 19
4.2.4
Approve ................................................................................................................. 19
4.2.5
Commission ........................................................................................................... 19
4.2.6
Implement ............................................................................................................. 19
4.2.7
Maintain ................................................................................................................. 19
4.3
RAPID Framework ......................................................................................................... 20
4.4
Reference Architecture Ecosystem ............................................................................... 21
4.5
Development Process ................................................................................................... 23
4.6
Tools.............................................................................................................................. 25
4.6.1
Repository ............................................................................................................. 25
4.6.2
Reference Architecture Document Template ......................................................... 25
5
Appendix A: References........................................................................................................ 26
Figure 1: Objectives of Reference Architecture .............................................................................. 6
Figure 2: Reference Architecture mission, vision, strategy ............................................................. 8
Figure 3: Reference Architecture components ................................................................................ 9
Figure 4: Reference Architecture cycle ......................................................................................... 10
Figure 5: Inputs of Reference Architecture ................................................................................... 11
Figure 6: Reference Architecture Linkage ..................................................................................... 13
Figure 7: Reference Architecture support of business process ..................................................... 14
Figure 8: Reference Architecture Hierarchy .................................................................................. 15
Figure 9: Reference Architecture Development Framework ......................................................... 17
Figure 10: The Reference Architecture Lifecycle........................................................................... 18
Figure 11: RAPID Model ............................................................................................................... 20
Figure 12: Reference Architecture Ecosystem .............................................................................. 21
Figure 13: Reference Architecture Process Flow .......................................................................... 24
PAGE: 3/26


1 Executive Summary
The term Reference Architecture within the IT&S community has various meanings,
multiple purposes and uses, varying levels of detail and abstraction, and very little
common guidance.
A Reference Architecture is a generic and somewhat abstract blueprint-type view of a
system that includes the systems major components, the relationships among them, and
the externally visible properties of those components.
This information will be captured in a document or a series of documents that will act as
implementation guides for practitioners working on developing particular IT solutions.
They will be strongly linked and aligned with the Bill-of-IT and the overarching IT Strategy.
The essence of these Reference Architecture documents is to:
Promote the reuse of common platforms

Drive standardisation
Provide a common practice, patterns and clear perspective guidance
Exploit baseline technical architectures
Help deliver high quality designed to operate solutions.
Provide architectural guidance and best practice information to these practitioners.
The development and use of these Reference Architectures will be encompassed by a

Reference Architecture Framework to ensure that there is an agile, modular, rapid and
repeatable service centric methodology for delivering and managing enterprise and
segment architectures. The framework aims to align and leverage BPs existing
Architecture Common Processes (ACP) and toolset for architecture development.
The following information outlines the detail into the framework and tools required to
manage the lifecycle of Reference Architectures from inception to retirement.
PAGE: 4/26


2 Reference Architectures
2.1 Introduction
The term Reference Architecture, within the IT&S community, has various meanings,
multiple purposes and uses, varying levels of detail and abstraction, and very little
common guidance.
Architects active in the creation of complex systems frequently use the term Reference
Architecture. However, these experienced architects may not have a consistent notion of
what this actually is. These are some of the questions that are posed:
What is a Reference Architecture?

Why do we need Reference Architectures (What is their value, what is the benefit
of creating and maintaining them?)
How do you capture a Reference Architecture? (How do you visualise it, what is
the appropriate level of abstraction, how is it used?)
A reference architecture is a generic and somewhat abstract blueprint-type view of a

system that includes the systems major components, the relationships among them, and
the externally visible properties of those components. It facilitates a shared understanding
across multiple products, organisations and disciplines about the current architecture(s)
and the future directions. It maps capabilities to business requirements in order to deliver
business outcomes.
The reference architecture enables best practice-based design of an IT infrastructure,
which drives standardization across the platform by applying sound architectural principles
around security, manageability and other factors to ensure a consistent approach to the
definition of IT services.
The mission of the reference architecture is to provide an asset base that projects can
draw from at the beginning of the project lifecycle and add to at the end of the project
Across all domains there are a couple of evident trends:
Increasing complexity, scope and size of the system of interest, its context and the
organizations creating the system
Increasing dynamics and integration: shorter time to market, more interoperability,
rapid changes and adaptions in the field.
These trends cause a transition from a simple closed system creation to a distributed
open system creation and evolution.
PAGE: 5/26


Many of todays systems are developed as distributed open systems at multiple locations,
by multiple vendors, across multiple organisations.
The diagram below illustrates the main objectives of how Reference Architectures are
used to address the trends mentioned above.
Managing synergy
Providing guidance (architecture
principles, best practices)
Providing an architecture baseline
and an architecture blueprint
Effectively create new:

Products
Product lines
Product Portfolio
Increased
Complexity
Scope
size
Capturing and sharing architectural

patterns
Providing a common lexicon and

taxonomy
Providing a common architectural
vision
Providing modularization and the
complementary context
Facilitate:
Multi-site
Multi-orginisation
Multi-vendor
Multi - *
System creation and
life-cycle support
Increased
dynamics
integration
Articulation of domain and

realization concepts
Explicit modelling of functions and
qualities above system level
Explicit decisions about
compatibility, upgrade and
interchangeability
Achieve interoperability
between many different
and evolving systems
Figure 1: Objectives of Reference Architecture
PAGE: 6/26


2.2 Why do we need Reference Architectures

Reference Architectures start to appear in organisations where the multiplicity reaches a
critical mass triggering a need to facilitate product creation and life-cycle support.
They provide:
a common lexicon and taxonomy

a common architectural vision & standards
a common practice, patterns and clear prescriptive guidance
better integration, interoperability and life-cycle support
The common lexicon and taxonomy facilitates communication across the multiple
dimensions. The common architectural vision focuses and aligns efforts of multiple people
spanning various teams.
They improve the effectiveness by:
managing synergy
providing guidance (e.g. architecture principles, best practices)
capturing and sharing of architectural patterns
The Reference Architecture effectiveness is also improved by providing an architecture

baseline, a shared starting point to discuss future changes and extensions. The Reference
Architecture serves as an architecture blueprint for future architectures. This hopefully
prevents the re-invention and re-validation of solutions for already solved problems.
References Architectures must improve interoperability by:
Articulation of domain and realisation concepts

Explicit modelling of functions and qualities above system level
Explicit decisions about compatibility, upgrade and interchangeability.
Decreased integration costs and time might also be an objective of Reference

Architectures. Note that all interoperability considerations are also applicable to reduction
of integration cost and time.
PAGE: 7/26


2.3 Reference Architecture Linkage

A Reference Architecture is strongly linked to company mission, vision and strategy. The
strategy determines what multi-dimensions have to be addressed, what the scope of the
Reference Architecture is, what means, such as synergy, are available to realise mission
and vision. In fact, a Reference Architecture is an elaboration of mission, vision and
strategy.
A Reference Architecture facilitates a shared understanding across multiple products,
organisations and disciplines about the current architecture(s) and future directions.
Architectures of the past are transformed in a Reference Architecture. However, the
purpose of the Reference Architecture is future oriented. The mission, vision and strategy
are needed to add the future direction to the wisdom of the past. Note that future
directions are inherently unproven. Hence future directions might be conflicting with the
experience that reference architectures should only contain proven concepts.
mission
Elaborated in
vision
Reference
Architecture
strategy
Guidance for future
Multiple organisations
Figure 2: Reference Architecture mission, vision, strategy
PAGE: 8/26


2.4 Reference Architecture context

With the ever increasing size and complexity of the systems being deployed across the
group, it is recognised that it is necessary to be engineering systems in a consistent
manner to address the growing need for integration, interoperability and shorter time to
market for these systems.
Within the industry it is recognised that practice of Reference Architectures is a key
enabler in large organisations to facilitate system creation and life-cycle support.
As such it is recommended that undertaking a centralised approach to Reference
Architecture will:
Provide a common practice, patterns and clear prescriptive guidance

Provide a common vocabulary and taxonomy
Provide a common vision & standards
Leverage industry best practices and knowledge, and
Provide better integration, interoperability and life-cycle support
Sometimes architectures that are labelled Reference Architectures describe the technical
architecture only.
A Reference Architecture should address:
Technical architecture
Business architecture
Information architecture, and
Customer context
In some practices, customer context, business and Information architecture are often
missing. As a consequence these technical reference architectures represent solutions for
unspecified problems in unspecified contexts.
Customer context
Technical Architecture
Requirements
Black box view
Customer
Users
Design patterns
Technology
Relations
Guidance
Business model
life cycle
Business Architecture
Information life
cycle
Information Architecture
Figure 3: Reference Architecture components
PAGE: 9/26


The figure above shows the business, information and the technical architecture, and the
customer context as partially overlapping. The common denominator is the requirement or
black box specification level, where the features and functions are modelled in a product
independent way. The technical architecture provides solutions in technology, captured as
design patterns. The business models and life cycle considerations in the business
architecture guide decisions in the technical domain. The same holds for customer
context, where processes in the customer enterprise and user considerations will provide
the guidance. Guidance from the Reference Architecture is largely based on the explicit
understanding of the relations between the business architecture, the technical
architecture and the customer context.
The level of abstraction of Reference Architectures makes it more difficult to understand
their role. The figure below (Figure 4) shows the cycles that are needed to transform and
abstract Reference Architecture into actual systems.
Design &
Engineer
Architect
SYSTEM
ARCHITECTURE
REFERENCE ARCHITECTURE
SYSTEM
A
FAMILY ARCHITECTURE
REFERENCE
ARCHITECTURE
SYSTEM
B
PRODUCT FAMILY
SHARED ASSETS
SHARED ASSET
ARCHITECTURE
Extracting
essentials
Build & Test
Field
feedback
Constraints &
opportunities
ARCHITECTURES
TECHNICAL
DOCUMENTATION
ACTUAL
SYSTEMS
Figure 4: Reference Architecture cycle
PAGE: 10/26


2.5 How Reference Architectures are created

A Reference Architecture captures previous experience, for instance by mining, or by
generalising existing architectures. To be of value for future architectures, a Reference
Architecture is based on proven concepts. The validation of concepts in Reference
Architectures is often derived from preceding architectures. Especially in cases where
disruptive technologies or innovative applications are introduced it is challenging to have
sufficient proof for a Reference Architecture. In these cases Reference Implementations
and prototyping and an incremental approach might be an alternative for validation and
proof.
The future value of Reference Architecture depends on the vision going into it. This vision
is based on (future) customer and business needs. These needs are explored and
analysed to be transformed into future requirements for the product portfolio.
The figure below (Figure 5) shows this flow of proven concepts and known problems for
existing architectures and vision derived from needs into Reference Architectures. The
Reference Architecture guides the evolution of existing architectures and influences the
customers and business, which triggers new changes in their needs. Architectures, needs
and Reference Architectures evolve continuously.
Customer & Business

needs
Exploration
& analysis
Guides evolution
Mining
Architecture
patterns
Product Portfolio
Future Requirements
Proven concepts &

known problems
Vision
Triggers new changes
Existing
architectures
Reference
Architectures
Figure 5: Inputs of Reference Architecture
A Reference Architecture must describe the essence of the architecture, the most
significant and relevant aspects. A Reference Architecture can be supported by more
detailed models, APIs, standards, etc. The challenge is to create a well readable,
accessible Reference Architecture that at the same time is non-ambiguous and effective
for all stakeholders. The size of the Reference Architecture is domain and objective
independent. Some of these documents may be very large. The risk of a large Reference
Architecture is that the essence is hidden instead of highlighted. A counter measure for
large Reference Architectures is to decompose it into core Reference Architecture and
more detailed models, interfaces, standards, etc.
PAGE: 11/26


2.6 Reference Architecture Readership

A Reference Architecture must be accessible and understandable for multiple
stakeholders from developers to business managers and customers. Therefore the
Reference Architecture must be concrete and provide specific information. The challenge
is to create a Reference Architecture that is generic for multiple architectures and
contains specific information at the same time.
The Reference Architect owner owns the Reference Architecture. Ownership is a critical
success factor for a Reference Architecture. Sponsorship from a Chief Architect for the
Reference Architectures is a prerequisite. Such sponsorship works only if the Reference
Architecture provides value for the business, for example as a decision making tool for
business leaders.
2.7 Reference Architecture Linkage

Reference architectures play a key part in developing technology solutions to support
business processes. They are an integral part within the BP toolset landscape.
The below diagram illustrates how reference architectures interrelate with other BP tools,
namely the Technical Reference Model (TRM) which outlines the taxonomy of BP
Technical components. They provide the guidance on the best of class and proven design
for the technical components listed within the TRM.
Single or multiple segment or group reference architectures provide the technology
solutions that support the Enterprise Activity Model (EAM) which defines BP business
processes. The Bill-of-IT maps the technology solutions for the defined business
processes and organisational scope.
PAGE: 12/26


Outlines the
solution for a
defined
business
process &
organisational
scope
Bill-of-IT
EAM defining
the business
processes
BUSINESS
PROCESS
Technology
solutions
supporting the
business
TECHNOLOGY
SOLUTIONS
Specific Segement Reference
architectures drive the technology
solution
Segment RAs
How different
Reference
Architectures
define
technology
solutions
A combination of Group & Segment reference

architectures drive the technology solution
Segment RAs
Specific Group Reference

architectures drive the technology
solution
Segment RAs
REFERENCE
ARCHITECTURES
Group RAs
The BP
taxonomy of
technical
components
Group RAs
TECHNICAL
REFERENCE
MODEL
Figure 6: Reference Architecture Linkage
PAGE: 13/26


Technology solutions that support business processes can be underpinned by a single or

multiple reference architectures that stem from a group or segment level.
The example below illustrates a combination of group and segment level reference
architectures that underpin a technology solution that supports a business process.
Figure 7: Reference Architecture support of business process
PAGE: 14/26


3 Reference Architecture Hierarchy

As per the TOGAF Enterprise Architecture model there are different levels of abstraction
that address the different levels of concerns. The same applies with regards to Reference
Architectures. Each level is the focus of different stakeholders and contains increasing
levels of detail and a narrower scope and concept from the top level down to the solution
or operational level. As such, the Reference Architectures start at an abstract level and
then progress down to a detailed level as illustrated in the diagram below.
Figure 8: Reference Architecture Hierarchy
Reference architecture provides a proven template solution for architecture for a particular
domain. Its the high-level blue prints for putting the pieces of the puzzle together.
A reference Implementation goes beyond reference architecture and is an actual
implementation. This is where the rubber meets the road and it serves as an exemplar
down at the implementation level.
A reference implementation is a fully functional implementation of a specification in
reference to which other implementations can be evaluated. If its an exemplar of the
architecture, it is a Reference Architecture. If its an exemplar of the implementation,
then its a Reference Implementation, and each serves different purposes, and requires
different levels of detail or abstraction.
PAGE: 15/26


3.1 Reference Architectures
3.1.1 Conceptual Architecture

The intent of conceptual architecture is to direct attention at an appropriate decomposition
of the system without delving into the details. The conceptual architecture collects
together decisions relating to the key architectural constructs in the system. It defines
the capabilities and interactions between components used to deliver business outcomes.
By focusing on key constructs and abstractions rather than a proliferation of technical
details, conceptual architecture provides a useful vehicle for communicating the
architecture to non-technical audiences, such as management, marketing, and in some
cases users. It is also the starting point for Logical Architecture, which elaborates the
component specifications and architectural mechanisms to make the architecture precise
and actionable.
3.1.2 Logical Architecture
Logical architecture is a more detailed design which includes all major components and
entities plus their relationships. The data flows and connections are detailed in this stage.
The target audience is typically developers or other systems architects. However, it is
possible to create logical designs for business purposes to ensure that all components
and functionality is accounted and well understood. Logical architectures do not include
physical server names or addresses. They do include any business services, application
names and details, and other relevant information for development purposes. The logical
architecture aims to elaborate the optimum structure for software, independent of final
technical decisions
3.1.3 Solution Architecture
Solution architecture has all major components and entities identified within specific
physical servers and locations or specific software services, objects, or solutions. This
includes all known details such as operating systems, version numbers, and even patches
that are relevant. Any constraints or limitations should also be identified within the server
components, software, data flows, or connections. This design usually precludes or may
be included and extended by the final implementation team into an implementation
design.
PAGE: 16/26


4 Reference Architecture Framework

4.1 Reference Architecture Development Framework
The Reference Architecture Development Framework (RADF) provides an agile, modular,
rapid and repeatable service centric methodology for delivering enterprise and segment
architectures. The figure below illustrates the framework interactions and inputs with
regards to Reference Architecture development
Figure 9: Reference Architecture Development Framework
PAGE: 17/26


4.2 Reference Architecture Lifecycle

The Reference Architecture Lifecycle Framework provides a standardised approach for
architects to create and maintain Reference Architectures. The framework defines a
cyclical lifecycle for Reference Architecture development which comprises seven stages;
Initiate
Research
Draft
Maintain
Approve
Implement
Commission
Figure 10: The Reference Architecture Lifecycle
The cycle begins with the identification of the need for a new Reference Architecture and
ends with a plan for on-going maintenance. The cyclical basis reflects the requirement for
periodic reviews of each Reference Architecture to enable improvements and updates to
be made. Without the ability to continually improve Reference Architectures they will
become stale and less applicable to the changing environment and technologies in BP.
4.2.1 Initiate
The Initiate stage is used to determine whether there is a requirement / justification for a
new Reference Architecture and prioritises the relative importance of its development
within the Reference Architecture Framework. Along with this, all required stakeholders in
accordance with the RAPID model (outlined in Section 4.3) are identified and more
specifically the sponsorship and single point of accountability roles are clearly defined and
agreed.
4.2.2 Research
The Research stage is where the analysis of the new or to be revised Reference
Architecture area takes place. Here the expected requirements are defined, existing as-is
architectures are understood and alternate approaches are investigated in detail.
PAGE: 18/26


4.2.3 Draft
The Drafting stage is where the new or revised Reference Architecture is documented
and prepared for the initial review. This stage brings together the requirements, the
technical analysis and stakeholders viewpoints.
4.2.4 Approve
The Approval stage is where the document is submitted to the appropriate decision
making governance body for review and approval. There is an expectation that the
document may be revised and iterated as challenges are raised.
4.2.5 Commission
The Commission stage is used to ensure that communications, training and any agreed
enabling items (service lines / commercial agreements) required to support the Reference
Architecture are put in place prior to its formal launch to the wider Architecture
Community.
4.2.6 Implement
The Implementation stage is where the newly created and approved Reference
Architecture is formally published and wider communication activities are undertaken to
ensure that architects are aware of its availability.
4.2.7 Maintain
The Maintenance stage defines the on-going content life-cycle management approach for
each document contained within the Group Reference Architecture Library and ensures
timely reviews of existing References Architectures.
The embedded document outlines the Reference Architecture Lifecycle in greater detail.
Reference
Architecture Lifecycle.pdf
PAGE: 19/26


4.3 RAPID Framework
The following diagram and table outlines the RAPID framework, roles and their respective
responsibilities.
Figure 11: RAPID Model
R is for
Recommend
Key
Responsibilities
- Establish criteria
and required facts
upfront
- Gather inputs
- Synthesize
analysis
- Develop the
recommendation
PAGE: 20/26
A is for Agree
P is for Perform
I is for Input
D is for Decide
Key
Responsibilities
- Sign off on key
recommendations
to ensure
consistency with
company policies or
regulatory
requirements
Key
Responsibilities
- Flag potential
implementation
issues early and
ensure decision is
practical
Key
Responsibilities
- Provide input
based on data,
experience or
position
Key
Responsibilities
- Make the final
decision and
commit the
organisation to
action
- Work with
recommender to
achieve mutually
satisfactory proposal
- Execute decision
as intended
- Handle follow-on
decisions with rigor
- Ensure input is
clearly heard bring
in high quality
analytics and logic
to bear and use
influence
appropriately


4.4 Reference Architecture Ecosystem

The below diagram outlines the intended ecosystem required to manage Reference
Architectures from inception to retirement. The diagram also outlines the assigned RAPID
responsibilities and roles.
Figure 12: Reference Architecture Ecosystem
Roles:
Chief Architects:
This group is responsible for agreeing to all group specific Reference Architectures. They
also provide input into segment specific architectures however do not necessarily have
agree rights in this instance.
RA Owner:
This person is the custodian and owner of the Reference Architecture and in most
instances would be the subject matter expert in that particular domain.
The key duties of this role are but not limited to the following:
PAGE: 21/26


Proposal of the Reference Architecture

Overall responsibility for the creation of the Reference Architecture (whether
this be solely responsible to undertake the required work, or responsible for
the collaboration and collection of the required information to produce the
Reference Architecture)
Ensuring that all roles and accountabilities are defined and agreed in line
with the Reference Architecture Ecosystem
Ensuring that the Reference Architecture follows the development and
approval processes.
Ongoing maintenance and lifecycle management of the Reference
Architecture
Accountable Chief Architect:
This person is nominated as the Single Point of Accountability and holds the decision
rights and funding required for that particular Reference Architecture. This would typically
be the corresponding segment Chief Architecture for segment level architectures or the
Group Chief Enterprise Architect for group level architectures. It is essential that this
person ensures that all appropriate input and agreement has been gained from all
stakeholders that will be impacted by the particular Reference Architecture (e.g.
Operations SPA, Segment CIO, etc)
Relevant Governance Board:
This group is typically made up of a group of the sponsor and stakeholders that will be
impacted by the intended Reference Architecture. This group has agree rights within the
ecosystem
Operations SPA:
This is typically the person that will be responsible for the ongoing support and operation
of the described solution in the Reference Architecture. They have agree rights within
the ecosystem and essentially are the operational custodian and single point of
accountability within the operational remit.
Technical Advisory Group:
This group is typically made up of technical specialist or subject matter experts in the
particular domain that the Reference Architecture is addressing. This would include Digital
Security representation. The RA owner is responsible for ensuring that sufficient
engagement and input has been gathered from this group.
PAGE: 22/26


4.5 Development Process

The inception and development of a Reference Architecture will typically follow the
process outlined below.
A request for Reference Architecture development work needs to be completed.

This would most typically be completed by the person would be identified as the
Reference Architecture Owner.
Reference
Architecture Request Form.pdf
This is then sent to the corresponding Chief Architect for review and discussion.
Segment Level architectures: It is expected that the nominated Chief Architect
reviews and discusses the proposed Reference Architecture with the owner. A
decision shall be made whether this work is sanctioned. In conjunction, the Chief
Architect should socialise the initiative within the Chief Architects forum to gain
input as required and also provide the visibility of the initiative across the group.
Group Level Architectures: It is expected that the Enterprise Group Chief Architect
presents this initiative within the Chief Architects forum and gain agreement and
approval for the development of the proposed group level Reference Architecture.
The proposed Reference Architecture is sanctioned for development
Architecture Common Processes to be followed in the development of the

Reference Architecture. . All roles and RAPID assignments are recorded and
agreed, along with architectural deliverables within the Architecture Project Tracker
(APT) tool.
The normal APT processes will be followed for development and reviews of the
proposed Reference Architecture.
Appropriate reviews are undertaken for the approval of the Reference Architecture.
The final approved Reference Architecture document is sent to the IT&S Librarian
for upload into the IT&S Reference Architecture Portal.
PAGE: 23/26


Appropriate meta-data is tagged to the document and the Reference Architecture is

set to active.
The document then follows the maintain phase of the The Reference Architecture
Lifecycle that was outlined in Section 4.2.
The diagram below illustrates this process.
Figure 13: Reference Architecture Process Flow
PAGE: 24/26


4.6 Tools
The IT&S Reference Architecture Portal contains all the supporting information and
processes to be followed for the development of a Reference Architectures. This site will
also contain the definitive list of approved and active Reference Architectures across the
IT&S organisation.
The use of existing Architecture Common Processes (ACP) and the Architecture Project
Tracker (APT) shall be used in the development of the Reference Architectures. Detailed
information about the ACP and APT can be found at the IT&S Architecture Hub.
Below is a matrix that illustrates the association of the APT Resource names and the
Reference Architecture resource RAPID Ecosystem.
APT List of Resources
Reference Architecture Ecosystem
Lead Architect
Reference Architect Owner
Chief Architect
Accountable Chief Architect
Project Manager
Reference Architect Owner
Gate Keeper
Accountable Chief Architect
Business Sponsor
Relevant Governance Board, Operations SPA
4.6.1 Repository
All final approved documents should be uploaded into the Architecture Resource
Knowledgebase (ARK). The IT&S Librarian will ensure that the appropriate linkages are
created in the IT&S Reference Architecture Portal.
By uploading the documents in the ARK, the appropriate meta-data and references can be
created for the Technical Reference Model (TRM) at the same time.
4.6.2 Reference Architecture Document Template
The embedded document outlines the information to be captured and produced for the
development of Reference Architectures and Reference Implementations.
PAGE: 25/26


Reference
Architecture and Implementation Template.pdf
5 Appendix A: References
Ref
A
B
C
D
E
F
G
H
Source
Enterprise Architecture Executive Council
Forrester
Gartner
IBM
Hewlett Packard
Accenture
Architecting Forum
Enterprise Architecture, Software Architecture,
Architects & Architecting
PAGE: 26/26
Notes
www.eaec.executiveboard.com
www.forrester.com
www.gartner.com
Internal meetings
Internal meetings
Internal meetings
www.architectingforum.org
www.bredemeyer.com


Reference Architecture Framework

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Reference Architecture Framework

Uploaded by

Copyright:

Available Formats

Reference Architecture Framework

Reference Architecture Guidelines