Post on 31-Mar-2015
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 ict-discipline, 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
• 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
problems tackled
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 scope-created 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
policy
plan
ict-strategy
ict-policy
ict-plan
inert area
strategy
policy
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
architecture
continuity time to value
projectmoney
time functionality ......quality attributes......
sourceconcernconcerngremium gremium
targetconcernconcern
concerndecision has impact onrepresented inobstructsserves
concerngremium
decision
talk; kleppen
type; kloppen
finish
fasterearlier
earlier expectation management
informationsystems
informationsystems
transition
wants then
start
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– the value that ict-architecture adds is
maintaining the organisation’s long term concerns
• policy
• plan
• concern web
• 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
marktaanslui ting
vendoronafhankelijkplatformonafhankeli jk
pakketbeschikbaarmigreerbaar
converteerbaarsaneerbaar
consolideerbaarin-/outsourcebaar
schaalbaar
optimaal
elegantintuitief
begri jpelijkoplossingsvri jheid
onafhankel ijk(=ontkoppeling)
non-complexnon-redundant
real timecompleet
generiek
uniformopen
ondersteunbaar
upgradableextendible
verplaatsbaarcontroleerbaar
voorspelbaarreproduceerbaar
veranderbaar
installeerbaarintegreerbaar
configureerbaargestandaardiseerd
vervangbaar
nu werken
beheersbaar
straks werken
methode wijzigbaar
kennisbehoud al veel klaar
anders werken
toepasseli jk
accuraatinteroperabel
compliantveilig
traceerbaar
begri jpelijk
leerbaarbedienbaar
explicietinstelbaar
aantrekkel ijkduidelijk
behulpzaamgebruiksvriendelijk
ti jdsgedrag
resourcegedrag
analyseerbaar
veranderbaarstabiel
testbaarmanageable
herbruikbaar
functionaliteit
betrouwbaarefficient
bruikbaar
bouwbaar
onderhoudbaar portable
informatievoorziening
procesbesturing
volwassen
robuustrecovery
beschikbaarafbouwbaar
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
strategypolicyplan
costtime
returnrisk
finance
strategyrequirements
processfunctionality
datainfrastructure
business ict
busi
ness
ict
inert area
stak
ehol
der
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
execution
3e-model: entity - execution - event3f-model: fact - function - flow
3g-model: gegeven - gedrag - gebeurtenis
relation
entity
event
customer order line
checkstock
checkcredit
no
no
okissueorder
order
yes
yes
1
N N1
N
1
product
1 1
example
1
1
(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)
informationsystems
moleculeview
repartitioned
modifiedchangerecipe
evolutedinformation
systems
trans
formation
inverse
modification
.......
evolution
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