1

Architectural PrinciplesA Tool to Reach the Goal Architecture

Åsa LindströmPh D Student Royal Institute of Technology, Sweden

asa@ics.kth.se, www.ics.kth.se, 070-7702480

2

Why?

3

The value chain of architectural principles…

BUSINESS STRATEGY IT STRATEGY ARCHITECTURAL

PRINCIPLES

4

What is an architectural principle?

1. Maximize benefit to the enterprise. Information management decisions are made to provide maximum benefit to the enterprise as a whole.

2. Common use applications. Development of applications used across the enterprise is preferred over the development of similar or duplicative applications which are only provided to a particular organization.

3. Data is shared. Users have access to the data necessary to perform their duties; therefore, data is shared across enterprise functions and organizations

4. Control Technical Diversity. Technological diversity is controlled to minimize the non-trivial cost of maintaining expertise in and connectivity between multiple processing environments

Exemples from TOGAF

5

The Federal Enterprise Architecture Framework

• Standards. Establish federal interoperability standards

• Investments. Coordinate technology investments with the federal business and architecture

• Data collection. Minimize the data collection burden• Security. Secure federal information against

unauthorized access• Functionality. Take advantage of standardization

based on common functions and customers• Information access. Provide access to information• Proven technologies. Select and implement proven

market technologies• Privacy. Comply with the Privacy Act of 1974

6

Content…?

7

Architectural principles at Company A

• Was developed in 2000• 35 principles• Used as a basis for their

technology framework

8

0,0

2,0

4,0

6,0

8,0

10,0

12,0

14,0

16,0

18,0

Develo

ping

strat

egies

Organ

izatio

nal is

sues

Projec

t man

agem

ent

Acquis

ition

Deploy

men

t

Servic

e m

anag

emen

t

User t

raini

ng a

nd su

ppor

t

Opera

tion

and

incide

nt m

anag

emen

t

Mon

itorin

g pr

oces

ses

IT sy

stem

s mod

ifiabil

ity

IT sy

stem

s int

egra

bility

IT sy

stem

s ava

ilabil

ity a

nd re

liabil

ity

IT sy

stem

s per

form

ance

IT sy

stem

s saf

ety

IT sy

stem

s inf

orm

ation

secu

rity

IT sy

stem

s fit t

o bu

sines

s

Data

quali

ty

IT sy

stem

usa

bility

and

use

r pro

ducti

vity

CIO Mean Value Principles mapped to ATD

9

0,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

IT organization IT system

Principles CIO

10

PART OF THE PRINCIPLE

DEFINITION

Statement What to improve

Motivation Why this is important for the enterprise

Implication What must be done and when, and who is responsible

Measures How the fulfilment of the principles is measured. Both for the Enterprise Architecture long-term and short-term, e.g. after an investment.

Comment

11

Rules for principlesSYNTAX

“Have we got the principle description

right?”

SEMANTIC“Have we got the right

principles?”

PRAGMATIC“Do the reader

interprets the principles right?”

Consistent

Stable

Verifiable Verifiable

Unambiguous Unambiguous

Modifiable Modifiable

Correct

Complete

Robust

Std 830-1998, Software Requirement Specification, 1998, www.ieee.org

12

More rules for principles• Few in numbers, approximately 10-20, so that

people can remember them• One document, so that it is easy to survey all

principles and impossible to loose a set of principles• Of equal importance, so that all will be employed• One statement for each principle, to make it

understandable• Not redundant, to make it understandable • Consistent, so that no misunderstandings occur on

what should be applied• Recommends actions to be taken, so that they are

clear on what should be done.• Measurable, so that the adherence to the principles

can be followed.

13

• States a fundamental belief of the enterprise in one or two clearly written sentences

• Recommends an action against which some arguments could be made

• Has relevance to a technical architecture• Is worded directly and in simply terms understandable by both

business and IT managers• Has business wide applicability• Is durable; will not be outdated quickly by advancing

technology• Has objective reasons for advancing IT instead of the

alternatives which were considered• Has impacts which needs to be documented• A principle is not a statement that no one would dispute• A principle is not a general business or financial statement• A principle does not select a specific standard or technology• A principle is not stated on such low level of detail so that it

might not endure• A principle is not included “because I say so”

14

SYNTAX SEMANTIC

Consistent Good. No inconsistencies were found.

Stable Good. Two potentially non-stable principles were found

Verifiable Improvable. Most principles were measurable, but some principles are hard to verify.

Verifiable Improvable. It is hard to verify that the enterprise architecture has been improved.

Unam-biguous

Improvable. Some principles with multiple focuses have been identified.

Correct &Complete

Improvable. Some minor differences were found.

Modifiable Improvable. Multiple documents are used and too many principles

Modifiable Improvable. Many redundant principles have been identified.

15

More information

• www.ics.kth.se -> Publikationer ->Working papers orhttp://www.ics.kth.se/Publikationer/Working%20Papers/publikationer_working%20papers.htm

• The Open Group Architecture Frameworkhttp://www.opengroup.org/architecture/togaf/

• Federal Enterprise Architecture Frameworkhttp://www.cio.gov/archive/bpeaguide.pdf

16

17

Architectural PrinciplesA Tool to Reach the Goal Architecture

18

19

Deployment The IT architect

• 150 measures and 3 hours/application and platform

• Coordinate technology investments with the enterprise and its architecture.

• The total business need/value is the primary objective when making information management decisions.

• The architecture should be optimized for modifiability. • The architecture should be optimized for interoperability.• Applications must be easy to use, satisfy end users need and provide

benefit to both the organization and the end users. • Data must be trustworthy and shall be of high quality.• Users must have access to the applications and infrastructure

necessary to perform their duties.• Technical diversity must be controlled and Proven technologies are

preferred over less tested technologies.• Data is protected from unauthorized use and disclosure.• Minimize the use of redundant applications and infrastructure in the

enterprise.

20

DeploymentApplication Portfolio Management

• 50 measures and 5 hours/application

• Applications shall correspond to their need of availability. Unavailable applications can cause production stops and lost revenue, which thereby affect the business in a negative way.

How well does the level of availability of the application correspond to the Service Level Agreement according to Table 7 above? (This question should be directed to persons on IT-coordination level)

0 None of the availability measures corresponds to the agreement2 There are times when the agreement is not fulfilled, but the availability agreement is met most of the time. 4 The availability measures for the application all correspond to the agreement.

Does the provided availability level result in any business complications? (This question should be directed to persons on IT- coordination or business level) The provided level of availability results in business complications:0 Once or a couple of times per week.2 Once or a couple of times per month.4 Once or a couple of times per year.

21

Vad sa de som var med?

• Bra översikt över ”sin” applikation• Ger tips på hur man kan arbeta med

förvaltningen av ”sin” applikation

• Bra översikt över flera applikationer• Gör varje år!• Gör före och efter större förändringar• Bra att låta process- och IT-ansvarig

svara på frågorna gemensamt