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: REFERENCE Architecture Framework.docx

PAGE: 2/26 BP INTERNAL BP INTERNATIONAL LIMITED 2012 LAST SAVED: 1 OCTOBER 2012

Document Control

AMENDMENT HISTORY

Version Date Comment Author Role

0.1 MAY-12 Initial Draft A. Theofilas Enterprise Architect

0.2 JUL-12 Updated with feedback from

segment tags and peers A. Theofilas Enterprise Architect

0.3 JUL-12

Minor update to repository

information and Reference

Architecture Template

A. Theofilas Enterprise Architect

0.4 JUL-12

Reference Architecture

Template updated with

example diagrams

A. Theofilas Enterprise Architect

1.0 Aug12 Reference Architecture

Template updated. A. Theofilas Enterprise Architect

ASSOCIATED DOCUMENTS

Document Name Version Author Date

REVIEW/APPROVAL

Reviewer/Approver Role Date

Chris Eaton Head of Solution Architecture

Strategy & Enterprise Architecture 20-Aug-2012

James Evans Director

Strategy & Enterprise Architecture 20-Aug-2012





Table of Contents

1 Executive Summary ................................................................................................................ 4 2 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





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.





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.





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.

Figure 1: Objectives of Reference Architecture

Increased

dynamics

integration

Increased

Complexity

Scope

size

Managing synergy

Providing modularization and the

complementary context

Explicit decisions about

compatibility, upgrade and

interchangeability

Explicit modelling of functions and

qualities above system level

Articulation of domain and

realization concepts

Providing a common lexicon and

taxonomy

Capturing and sharing architectural

patterns

Providing an architecture baseline

and an architecture blueprint

Providing guidance (architecture

principles, best practices)

Providing a common architectural

vision

Effectively create new:

Products

Product lines

Product Portfolio

Facilitate:

Multi-site

Multi-orginisation

Multi-vendor

Multi - *

System creation and

life-cycle support

Achieve interoperability

between many different

and evolving systems





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.





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.

Figure 2: Reference Architecture mission, vision, strategy

mission

strategy

vision

Multiple organisations

Reference

ArchitectureElaborated in

Guidance for future





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.

Information ArchitectureBusiness Architecture

Customer context Technical Architecture

Relations

Guidance

Requirements

Black box view

Design patterns

Technology

Business model

life cycle

Customer

Users

Information life

cycle

Figure 3: Reference Architecture components





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.

REFERENCE ARCHITECTURE FAMILY ARCHITECTURE PRODUCT FAMILY

SYSTEM

ARCHITECTURE

SHARED ASSET

ARCHITECTURE

SYSTEM

A

SYSTEM

B

SHARED ASSETS

REFERENCE

ARCHITECTUREARCHITECTURES

TECHNICAL

DOCUMENTATION

ACTUAL

SYSTEMS

ArchitectDesign &

EngineerBuild & Test

Extracting

essentials

Constraints &

opportunities

Field

feedback

Figure 4: Reference Architecture cycle





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.

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.

Existing architectures

Architecture patterns

Customer & Business needs

Product PortfolioFuture Requirements

ReferenceArchitectures

Vision

Exploration & analysis

Mining

Proven concepts & known problems Tr

igge

rs n

ew c

han

ges

Gu

ide

s ev

olu

tio

n





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.





Figure 6: Reference Architecture Linkage

Group RAs

Segment RAs

Segment RAs

Group RAs

Segment RAs

TECHNOLOGY SOLUTIONS

REFERENCEARCHITECTURES

TECHNICALREFERENCE

MODEL

BUSINESSPROCESS

Bill-of-IT

How different Reference

Architectures define

technology solutions

A combination of Group & Segment reference architectures drive the technology solution

Specific Group Reference architectures drive the technology

solution

Specific Segement Reference architectures drive the technology

solution

Technology solutions

supporting the business

EAM defining the business

processes

Outlines the solution for a

defined business

process & organisational

scope

The BP taxonomy of

technical components





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





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.





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.





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





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

Approve

CommissionImplement

Maintain

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.





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





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

A is for Agree P is for Perform I is for Input D is for Decide

Key

Responsibilities

Key

Responsibilities

Key

Responsibilities

Key

Responsibilities

Key

Responsibilities

- Establish criteria

and required facts

upfront

- Gather inputs

- Synthesize

analysis

- Develop the

recommendation

- Sign off on key

recommendations

to ensure

consistency with

company policies or

regulatory

requirements

- Work with

recommender to

achieve mutually

satisfactory proposal

- Flag potential

implementation

issues early and

ensure decision is

practical

- Execute decision

as intended

- Handle follow-on

decisions with rigor

- Provide input

based on data,

experience or

position

- Ensure input is

clearly heard bring in high quality

analytics and logic

to bear and use

influence

appropriately

- Make the final

decision and

commit the

organisation to

action





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:





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.





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.





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





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.





Reference Architecture and Implementation Template.pdf

5 Appendix A: References

Ref Source Notes

A Enterprise Architecture Executive Council www.eaec.executiveboard.com

B Forrester www.forrester.com

C Gartner www.gartner.com

D IBM Internal meetings

E Hewlett Packard Internal meetings

F Accenture Internal meetings

G Architecting Forum www.architectingforum.org

H Enterprise Architecture, Software Architecture,

Architects & Architecting

www.bredemeyer.com

reference architecture framework

Documents