architecture with a purpose

Architecture with a PurposeA suggestion for a light-weight architecture framework

© Heinz Tonn , May 2016

Issue

• Architecture Frameworks are large specifications, consisting of methods, tools, templates and processes. There are for example 750+ pages of specification for TOGAF alone.

• Some organisations hesitate and shy away from introducing architecture as they see it as an overhead or consulting gimmick.

• Other organisations implement these framework on an full or almost complete scale and are then burdened with the associated overhead.

• In both cases it can happen that the need or purpose of architecture is lost to most other members of the organisation because there is no architecture in the first place or it is so abstract that non-architects have difficulty understanding it.

• The benefits organisations could gain by having an architecture capability are lost as a result.


Aim

• This slide deck suggests a architecture framework called Architecture with a Purpose.

• Architecture with a Purpose is a light-weight architecture framework derived from the needs of the whole organisation, not just architects.

• Thus the framework is based on the purpose of architecture which is to serve the enterprise.

• This framework can be extended to a full-scale framework and should only be seen as a first step to introduce or revitalise architecture in an organisation.

• This slide deck provides an introduction and definition to Architecture with a Purpose in under 20 pages.


Overview

The framework consists of 3 main elements

1. Purpose – Justification, basic introduction and setting the frame for the following parts.

2. Stakeholder & Concerns – Detailing stakeholder groups and their concerns.

3. Common Modelling – Detailing which elements to use, how to structure those and what the resulting viewpoints are. Structure and elements provide comparability of the documented architectures across the IT landscape. The delivered viewpoints address stakeholder concerns.

Stakeholders & Concerns

Purpose

Common Modelling

Modelling

Guidelines

§

Domain

Model

Common

Elements

User &

Process

Workplace

Network

Information

Technology </>

Viewpoints

IT Service Management

TheProject

TheBusiness

Fellow Architects


Purpose

• The generic purpose of architecture is to manage the complexity

• Complexity is part of any IT project in todays fragmented landscape of IT solutions and services and collaborating businesses.

• In addition, architecture is to ensure that the solution, system or service delivered by a project fits the needs of the client or owner and satisfies the expectations of the users.

• Furthermore there are also needs in the wider organisation, such as IT service management having to operate the solution, as well as other stakeholders as detailed in the next part.


Purpose

Common Modelling

Modelling

Guidelines

§

Domain

Model

Common

Elements

User &

Process

Workplace

Network

Information

Technology </>

Viewpoints


TheProject

TheBusiness

Fellow Architects


Stakeholder & Concerns

There are the four main stakeholder groups and their interests or concerns in no specific order.

• The Business – Business owners, budget holders and non-technical users of the solution.

• The Project – Staff implementing and delivering the IT and possibly organisation changes.

• Fellow Architects – Domain, technical and subject-matter experts.

• IT Service Management – IT staff managing and operating the delivered service or solution.

Details of each Stakeholder Group are detailed on the next slides.


Purpose

Common Modelling

Modelling

Guidelines

§

Domain

Model

Common

Elements

User &

Process

Workplace

Network

Information

Technology </>

Viewpoints


TheProject

TheBusiness

Fellow Architects


Stakeholder & Concerns The Business

• Stakeholder• Business owner as the main requestor and budget

holder paying for the solution or service.

• Business administrator managing users and their usage.

• Business or public user as consumer of information.

• Concerns• That the business requirements, objectives and

constraints are meet.

• That the solutions or service facilitates the desired business outcome.

• That the solution provides value-for-money and is delivered in the agreed timeframe.

• Typical Deliverables• Solution Description as in a manual, NOT a design or

assembly instruction.


Purpose

Common Modelling

Modelling

Guidelines

§

Domain

Model

Common

Elements

User &

Process

Workplace

Network

Information

Technology </>

Viewpoints

TheBusiness

TheProject


Fellow Architects


Stakeholder & ConcernsThe Project

• Stakeholder• Programme manager responsible for the business

outcome.

• Portfolio manager, responsible for alignment between different programmes and projects.

• Project manager responsible for timely delivery within budget.

• Concerns• That deliverables and tasks to implement the solution

are known (from plan to hand-over).

• That it fits into the available budget and timeframe.

• That all resource requirements are known and feasible.

• Typical Deliverables• Design (High Level, Low Level) as in a description of

how to build the solution (Bill of Material, assembly sequence, cost & effort estimates).


Purpose

Common Modelling

Modelling

Guidelines

§

Domain

Model

Common

Elements

User &

Process

Workplace

Network

Information

Technology </>

Viewpoints

TheBusiness

TheProject


Fellow Architects


Stakeholder & ConcernsFellow Architects

• Stakeholder• Design authority as the governor of standards, for e.g.

information security or legal.

• Domain expert as the expert for a specific business unit.

• Technical or subject-matter expert (e.g. storage architect).

• Concerns• That generic or common constraints and requirements

are meet (e.g. security, safety).

• That generic or common objectives are observed.

• That the resulting solution fits into the overall IT landscape.

• That there is no duplication or “silofication”.

• Typical Deliverables• Covered by deliverables for other stakeholder groups

(e.g. Design, Solution Description).


Purpose

Common Modelling

Modelling

Guidelines

§

Domain

Model

Common

Elements

User &

Process

Workplace

Network

Information

Technology </>

Viewpoints

TheBusiness

TheProject


Fellow Architects

Stakeholder & ConcernsIT Service Management

• Actual stakeholder• Service management responsible for managing service

or solution quality with the service users and owners.

• IT operations responsible for running and maintaining the solution or service.

• System administration responsible for the resolution of requests and incidents (e.g. help desk, support).

• Concerns• That the expected service quality can be delivered.

• That the requirements to operate and manage the solution are known (e.g. documentation, skills).

• That the change requirements are known (i.e. improve, extend, scale).

• Typical Deliverables• Manuals, Design (post go-live and updated version, not

the pre-implementation version).


Purpose

Common Modelling

Modelling

Guidelines

§

Domain

Model

Common

Elements

User &

Process

Workplace

Network

Information

Technology </>

Viewpoints

TheBusiness

TheProject


Fellow Architects



Purpose

Common Modelling

Modelling

Guidelines

§

Domain

Model

Common

Elements

User &

Process

Workplace

Network

Information

Technology </>

Viewpoints

TheBusiness

TheProject


Fellow Architects

Common Modelling

This part contains the basics of how architectures should be visualised, described and documented.

• Domain Model – Modelling structure.

• Common Elements –Element types or components to be used for modelling.

• Viewpoints – Visualisations and their descriptions.

• Modelling Guidelines – Rules for modelling.


Common ModellingDomain Model

The following domains should be used to structure the common elements:

• User & Processes – Roles and activities outside IT.

• IT Workplace – User interfaces and devices through which user utilise IT.

• Network – connectivity between devices or sensor on one side and data centre resources in the backend.

• Information Technology – hardware, software for information processing as well as supporting IT resources and services (e.g. directories).


Purpose

Common Modelling

Modelling

Guidelines

§

Domain

Model

Common

Elements

User &

Process

Workplace

Network

Information

Technology </>

Viewpoints

TheBusiness

TheProject


Fellow Architects


Common ModellingCommon Elements

These are element types to be used and the domain they should appear in.


Purpose

Common Modelling

Modelling

Guidelines

§

Domain

Model

Common

Elements

User &

Process

Workplace

Network

Information

Technology </>

Viewpoints

TheBusiness

TheProject


Fellow Architects


DomainsCommon Elements

User &

Process

Workplace

Network

Information

Technology </

>

User

Network

Device

Process or

Task

Device or

Client

Client

Application

Access

Network

Technology

Application

or

Configuration

Server Storage

Service </>

Common ModellingModelling Guidelines

1. The Domain Model is a mandatory standard; no other domains should be introduced.

2. The Common Elements are a mandatory standard, no other element types should be introduced.

3. Additional domains and element types need to be carefully and centrally managed to ensure comparability across different architectures.

4. An actual elements can have different shapesand forms but should correspond to only one of the Common Elements (e.g. Device = Mobile, Laptop, Thin Client)


Purpose

Common Modelling

Modelling

Guidelines

§

Domain

Model

Common

Elements

User &

Process

Workplace

Network

Information

Technology </>

Viewpoints

TheBusiness

TheProject


Fellow Architects


Common ModellingModelling Guidelines

5. The Viewpoints represent a minimum standard, meaning that additional views, visualisations or descriptions can be added above and beyond as long as they refer to the same Common Elements.

6. External Services used by the solution can be represented as a black box, without domain association or common element use but an interface to other elements.

7. All interfaces and information flows should be shown as connectors between common elements. No element can be un-connected.

8. Elements or services one removed from the scope boundaries should be modelled to cover the interface or information flow.


Purpose

Common Modelling

Modelling

Guidelines

§

Domain

Model

Common

Elements

User &

Process

Workplace

Network

Information

Technology </>

Viewpoints

TheBusiness

TheProject


Fellow Architects


Common ModellingViewpoints

Overview Diagram – All used elements in their domains and interfaces.

Process Diagram – Interactions of how the solution or service is used and maintained.

Work Breakdown Structure – BoM and the associated work to be carried out (tasks).

Plan – Sequence constraints of tasks, dependencies between tasks, durations.

Information Security Diagram – Overlay of the Overview Diagram to address security.

Service Level Assurance – Overlay of the Overview Diagram to show how service levels are achieved.


Purpose

Common Modelling

Modelling

Guidelines

§

Domain

Model

Common

Elements

User &

Process

Workplace

Network

Information

Technology </>

Viewpoints

TheBusiness

TheProject


Fellow Architects


Addressed ConcernsLoop-Back from Common Modelling to Stakeholder Concerns

The following table shows how and where Stakeholder Concerns are addressed by the Viewpoints of Common Modelling.


Sta

ke

ho

lde

rs &

Co

nc

ern

s

TheBusiness

TheProject


Fellow Architects

Overview

DiagramProcess Diagram

Work Breakdown

Structure

Service Level

Assurance

Information

SecurityPlan

Viewpoints

For

information

only

Validation of

Business

Requirements

Assurance of

Value-for-Money

Assurance of

expected delivery

Validating BoM

and interfaces

Deriving testing

requirements

Validating work

scope

Validating system

requirements

Assurance of

feasibility

Understanding

security concept

Identify potential IT

dependencies or

redundancies

Assurance of

standard and

policy adherence

Assurance of

technical feasibility

Assurance of

security policies

and standards

For

information

only

Understanding

support and

helpdesk

requirements

For

information

only

Understanding

support and

management

requirements

Assurance of hand-

over to service

timeline

Understanding

security operations

requirements

For

information

only

For

information

only

Assurance of

Business Security

Requirements

Identify potential

business

dependencies or

redundancies

Summary

• Introducing architecture to an organisation doesn't need to be a pain and is no rocket science.

• Introducing architecture actually benefits the organisation.

• It just depends of the framework which is proposed and the benefits it has.

• The architecture framework proposed here provides the following benefits:

• Architecture with a Purpose is purpose-driven as the main aim of Common Modelling is to address Stakeholder Concerns (see previous slide).

• Architecture with a Purpose is light-weight (explained in under 20 slides).

• Architecture with a Purpose can be extended by experienced architects to a full-scale architecture capability without change, only additions.

• Architecture with a Purpose might just be the right way for some organisations to introduce an architecture capability from scratch or revitalise an existing architecture capability.


Thank you for your attention

Heinz Tonn

Freelance Enterprise Architecture Consultant

Find me on LinkedIn uk.linkedin.com/in/heinztonn


uk.linkedin.com/in/heinztonn