imagining ict-architecture
jeroen j van beele; versie 0; januari 2004
contents
•
•
•
•
•
definitions, approaches and roles
problems and solutions
scoping and context
my approach
references
these are my personal images
• the first thing that strikes is the diversity in
definitions approaches and roles available
• for an indication of this diversity see
www.aim.nl/onderzoek/onderzoek_2003-2004.htm
• that’s why i sometimes
experience ict-architecture
as a magnet that attracts a
whole bunch of problems
definitions
• ieee 1471 definition 3.5: the fundamental
organization of a system embodied in its
components, their relationships to each
other, and to the environment, and the
principles guiding its design and evolution
• chris verhoef: architectuur is dat wat
moeilijk te veranderen is
from the first 6 papers of lac 2003
• architectuur is stadsvernieuwing, geen
stedenbouw
• architectuur is stuurinstrument voor
beheerst veranderen
• enterprise architecture wordt gedefinieerd
als een proces en een product
approaches
• frameworks
– ieee 1471
– greefhorst, koning en van vliet in
www.cs.vu.nl/~hans/publications/dimensies.pdf
mention 17 frameworks
• maturity models
– meta group: acmm
– ordina: amm
roles
• the genootschap van informatiearchitecten
distinguishes 3 roles
– informatie architect
• information from the production factor perspective
– it-architect
• ict-infrastructure
– it-business architect
• ict landscape within information landscape
magnetism
• the reason for this magnetism is that there are still quite a
lot of and diverse unsolved problems around in the ictdiscipline, especially problems not addressed by regular
methods are passed on by the line to the ict-architect
• if you want to narrow down the scope of ict-architecture to
the essential construction of information systems you will
find that you can only put ict-architecture into practise by
simultaneously solving problems you just scoped out
• sometimes an ict-architect feels like fostering a flock of
monkeys
problems tackled
•
•
•
•
•
•
•
•
•
•
•
•
i have to pay too much for something i dindn’t ask for and that is delivered too late
communication between business and ict
overview of all the systems and their interconnections
evolution of information systems - flexibility
reuse of code
spaghetti has risen from code to system level - interoperability
what should or can we do with our legacy?
methods and techniques
ict-knowledge management
choosing technologies and products
we need a supertechy
many technical problems turn out to be
projections of organisational problems
solutions provided
•
•
•
•
•
•
•
•
•
•
•
ict-governance; tco; business case; outsourcing
business-ict alignment
frameworks (ieee 1471; zachman); esthetics: pictures and rules
ordering and clustering: ontkoppeling (run vs build time)
oo; cbd; webservices
middleware
open up legacy using agents; reverse engineering
cmm
knowledge management
is ict-architecture a proces, a product or both?
this list resembles amm’s
context
• the problems listed above are mainly the result of the
incompleteness and inconsistency of separately well defined
methods such as ict-governance (eg cobit), project
management (eg prince ii), software engineering (eg dsdm)
and maintenance (eg itil)
• a major paradigm within ict is scoping because of the many
interconnections it embraces. the strength of scoping is also
it’s weakness: by isolating a problem you solve the problem
but create a new problem at the interface with the context
this might be a common denominator for the diverse
problems listed: they all lack integration with their
respective contexts
coping by scoping?
• the interconnection ever increases - this means that
changes face ever more side effects
• by scoping the problem is shifted towards the scopecreated boundaries
• scoping is part of the answer but also part of the problem
• so there is a central role in the solution to be expected for
co- and adhesion
• technically connections can be understood as flow, this
hints to the view that if-then-else constructions are far too
rich to be used in a decent way
my approach
• the following should be in place
• not necessarily realised by ict-architects
• inert areas
• alignment chain
• entity - execution - event
inert areas
• definition: an inert area is a part of an organisation that is
characterised by it’s dynamics such as goals, development
and influences
• in the context of ict we find several inert areas:
–
–
–
–
–
–
business
culture
human resources
organisation
process
ict
subareas of ict:
– data
– functionality
– flow
– technical infrastructure
alignment
business
strategy
ict-strategy
inert area
strategy
policy
ict-policy
policy
plan
ict-plan
plan
governance and alignment
• each area needs to be governed (who decides)
and all of them need to be aligned together
• so with respect to ict we need:
– ict-governance (tco, business cases, outsourcing,
ict-strategy)
– business-ict alignment
• ict-governance is a condition sine qua non for
ict-architecture
• ict-architecture is an ict-governance instrument
(governance) analysis frameworks
money
project
time
functionality
architecture
......quality attributes......
continuity
gremium
concern
source
concern
concern
gremium
decision
decision
serves
obstructs
represented in
has impact on
target
concern
concern
gremium
concern
time to value
information
systems
transition
start
earlier
information
systems
finish
faster
type; kloppen
wants
earlier
talk; kleppen
then
expectation management
ict-architecture process
• make ict-architecture products together with all relevant
stakeholders
– business; ict: strategy, development, maintenance; others like users
– decision makers should understand all relevant concerns
– communicate using archetypes
• implement
–
–
–
–
–
pictures and rules
training
reviews
acceptance tests
change to archiculture
along the software life cycle
–
–
–
–
–
–
definition
design
build
integration
test
acceptance
ict-architecture products
• strategy
• concern web
– the value that ict-architecture adds is
maintaining the organisation’s long term concerns
• policy
• plan
• architecture to be
• as is - migration - to be
concern web
•
•
•
•
quality attributes
quint model
interoperability
separation
(independance)
• agility
– a system is agile if
the amount of
resources needed for
changing it is
correlated to te
functional change
realised
informatie
voorziening
functionaliteit
efficient
toepas selijk
accuraat
interoperabel
compliant
veilig
traceerbaar
begrijpelijk
leerbaar
bedienbaar
expliciet
instelbaar
aantrekkelijk
duidelijk
behulpzaam
gebruiksvriendelijk
tijdsgedrag
resourcegedrag
nu werken
straks werken
bruikbaar
onderhoudbaar
betrouwbaar
volwassen
robuust
recovery
beschikbaar
afbouwbaar
analys eerbaar
veranderbaar
stabiel
testbaar
manageable
herbruikbaar
veranderbaar
installeerbaar
integreerbaar
configureerbaar
gestandaardiseerd
vervangbaar
proces
besturing
anders werken
portable
bouwbaar
ondersteunbaar
upgradable
extendible
verplaatsbaar
controleerbaar
voorspelbaar
reproduceerbaar
marktaansluiting
vendoronafhankelijk
platformonafhankelijk
pakketbeschikbaar
migreerbaar
converteerbaar
saneerbaar
consolideerbaar
in-/outs ourcebaar
schaalbaar
beheersbaar
methode
kennisbehoud
wijzigbaar
al veel klaar
optimaal
elegant
intuitief
begrijpelijk
oplossingsvrijheid
onafhankelijk
(=ontkoppeling)
non-complex
non-redundant
real time
compleet
generiek
uniform
open
viewpoints
• concerns - ieee 1471 - viewpoints
• core viewpoints for the ict-architect to
document strategy, policy and plan
–
–
–
–
process
functionality
data
technical infrastructure
• other viewpoints derived from core
viewpoints in context
business
ict
stakeholder
inert area
business
ict
strategy
policy
plan
cost
time
return
risk
finance
strategy
requirements
process
functionality
data
infrastructure
3e
isolate the flow
• here i want to present a model suited for
capturing the dynamics of ict
• the model is constructed looking at
organisms
• organisms grow and evolve at different
levels
organism metaphor
mutation level
cell growth
organism reproduction
species evolution
cycle
short
longer
long
dna
unchanged
changes
restructure
change
restricted
more
complete
3e-model: entity - execution - event
3f-model: fact - function - flow
3g-model: gegeven - gedrag - gebeurtenis
entity
execution
event
relation
customer
1
N
order
1
N
line
1
N
example
1
product
yes
111
check
stock
ok
no
order
yes
check
credit
no
issue
order
(possible) applications
• basis for the vocabulary of the core
viewpoints
• implementation paradigm
• maintain legacy
• restructure (refactore, reengineer) software
• eai
• architectural conformance
implementation: molecules
wf
...
da
...
maintain legacy (after verhoef)
information
systems
molecule
view
trans
formation
evolution
repartitioned
modification
.......
evoluted
information
systems
change
recipe
inverse
modified
references
•
•
•
•
•
www.aim.nl/onderzoek/onderzoek_2003-2004.htm
www.cs.vu.nl/~hans/publications/dimensies.pdf
www.idi.ntnu.no/~letizia/swarchi/IEEE1471.pdf
www.serc.nl/lac/2003/papers/archicultuur.pdf
www.serc.nl/lac/docs/Papers/xaosorde.pdf