1 architectural principles a tool to reach the goal architecture Åsa lindström ph d student royal...
Post on 21-Dec-2015
214 views
TRANSCRIPT
1
Architectural PrinciplesA Tool to Reach the Goal Architecture
Åsa LindströmPh D Student Royal Institute of Technology, Sweden
[email protected], 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