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

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 context s

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

business strategy policy plan

alignment

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

money time project functionality ......quality attributes......

continuity architecture time to value concern gremium decision source concern concern gremium decision serves obstructs represented in has impact on target concern concern gremium concern

information systems transition information systems earlier start type; kloppen earlier wants talk; kleppen finish faster 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

nu werken

informat ie voorzi ening

straks werken

funct ional iteit • interoperability • separation toepas seli jk (independance) accuraat int eroperabel compliant veilig • agility traceerbaar begri jpel ijk – a system is agile if leerbaar bedienbaar the amount of expliciet inst elbaar aantrekkel ijk resources needed for duidelij k behulpzaam gebrui ksvri endelijk changing it is ti jdsgedrag correlated to te efficient resourcegedrag bruikbaar betrouwbaar volwassen robuust recovery beschi kbaar afbouwbaar analys eerbaar veranderbaar stabiel testbaar manageable herbruikbaar onderhoudbaar veranderbaar inst all eerbaar int egreerbaar confi gureerbaar gestandaardi seerd vervangbaar bouwbaar portable onderst eunbaar upgradable extendi ble verpl aatsbaar controleerbaar voorspel baar reproduceerbaar marktaanslui ting vendoronafhankelijk platform onafhankeli jk pakketbeschikbaar mi greerbaar converteerbaar saneerbaar consolideerbaar in-/outs ourcebaar schaalbaar functional change realised proces besturing

beheersbaar

anders werken

methode kennisbehoud wijzi gbaar al veel klaar

opti maal elegant int uitief begri jpel ijk oplossi ngsvri jheid onafhankel ijk (=ontkoppeli ng) non-com plex non-redundant real ti me 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

inert area business strategy policy plan ict cost time return risk finance strategy requirements 3e process functionality data infrastructure

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

N

1 product 1

example

1 1 1 order check stock check credit yes no yes no ok 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 evolution evoluted information systems molecule view trans formation repartitioned modification .......

cha ng e 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