Skip to content

IASA-medlemsmøte 2010-04-15 - Introduksjon til virksomhetsarkitektur

  • Dato: Torsdag 15. april 2010. 18:00-21:00
    • Sted: Scotsman, 2. etasje
    • Tema: Introduksjon til virksomhetsarkitektur
    • Twittertags: #iasa #introvirk

Invitasjon

Hva er egentlig virksomhetsarkitektur? Merk: norsk oversettelse av "Enterprise Architecture" som muligens er et bedre kjent begrep. Er det noe vi i IASA skal bry oss om? Eller arkitekter generellt for den saks skyld? Det er blitt snakket mye om virksomhetsarkitektur de siste årene - samtidig som det kan virke uklart hva dette egentlig dreier seg om. Vi tror derfor det er nyttig at IASA Norge tar for seg temaet, og innbyr til diskusjon rundt hva det egentlig er og hva det brukes til.

Virksomhetsarkitektur synes å adressere virksomheten som helhet, og det kan synes som det er større utfordringer der enn for de enkeltstående løsninger vi utvikler. Hvilket kan være en svært god grunn til å engasjere seg i virksomhetsarkitektur. Samtidig så virker det uklart hva dette egentlig er, og hva resultatet blir. Erfaringer viser også at det ofte er en viss avstand fra de som driver med virksomhetsarkitektur og de som utvikler løsninger - kan man da få til noen effekt, og hvorfor er det slik?

Vi har allerede fått med oss representanter fra kunder som jobber aktivt med virksomhetsarkitektur og vil dele sine erfaringer. Det er fortsatt rom for foredragsholdere - til korte lyntaler eller til erfaringsforedrag. Vi ønsker i dette møtet å introdusere temaet. Foredragene etterfølges av paneldebatt; Hvorfor virksomhetsarkitektur?

Agenda

1800 - Velkommen og innhente forsyninger i baren 1815 - Introduksjon til medlemsmøte 1830 - Hva er egentlig virksomhetsarkitektur v/Odd Christian Landmark fra ErgoGroup 1900 - Erfaringer med virksomhetsarkitektur hos DnB NOR v/Nils Pedersen fra DnBNOR 1930 - Nye forsyninger 1945 - Erfaringer med virksomhetarkitektur fra ulike miljøer v/Simen Bergsrud fra CSC 2005 - Det er ikke arkitektur jeg er i mot - det er arkitekter! v/Kaare Nilsen fra ArkTekk 2030 - Nye forsyninger 2045 - Gullfisk panel - Hvorfor virksomhetsarkitektur? referent Mads Nissen

Les hva Grady Booch sier om EA is not TA på:

EA Is Not TA

I'm back from New York where I keynoted an invigorating conference sponsored by the IASA, in which they brought together a number of enterprise architecture folks (such as John Zachman) and technical architecture folks (such as Len Bass). The collision of those worlds is something that's been popping up in a number of conversations I've had recently, and it so moves me to make my position clear.

EA (enterprise architecture) is not TA (technical architecture).

Although the two share the noun "architecture" they are different things. EA attends to the architecture of a business that uses technology; TA attends to the architecture of the software-intensive systems that support the business. Each domain - that of the business and that of the system - have fundamentally different stakeholders with different perspectives and different viewpoints. The fact that the both share some aspects of terminology and concerns and even notation is good, but can be confusing in the dialog between those two worlds..

Indeed, speaking of two worlds, in the dialog between science and religion, there's also this notion of two worlds: science has some things of which it may speak with authority and faith has some things of which it may speak with authority, but when science tries to answer questions of faith (why is the world the way it is) or vice versa (is there or is there not a randomness in the laws of the universe) then conflict arises. Not to diminish the complex texture of the dance between science and religion - if you want to go there, then the Templeton Foundation is one place to start, although Richard Dawkings has some things to say about that too - but IMHO EA and TA are similarly of two worlds. Most contemporary economically-meaningful enterprises use software-intensive systems to carry out their mission, and so there is and should be this jiggling between the architecture of the business (as it uses technology) and the architecture of the software-intensive system (as it serves and leads the business).

If you accept my premise that this collision of worlds exists between EA and TA, then I want to be clear that both worlds must co-exist and both must interoperate. SOA actually has some interesting traction here, because on the one hand, architecting a business around the services it provides and architecting a software-intensive system that makes manifest those services are shared goals of the enterprise and the technology.

And yet - and here's where I'm likely to inflame some folks - IMHO it's a mistake to try and extend EA frameworks and notations and processes to attend to the architecture of the software-intensive systems it uses, just as it is a mistake to try and extend SA frameworks and notations and processes to attend to the architecture of the business. There might be some overlap in view and basic modeling elements and processes at a high enough level of abstraction, but when you get to the details, it becomes too much, and you lose the perspective of what each is trying to do. EA is not a desert topping and a floor wax and neither is TA.

Påmelding:

Twitter feed fra møtet

{rss:url=http://search.twitter.com/search.atom?q=%23iasa+%23introvirk&since=2010-01-08}