IT-Universitetet: Objekter er yt, processer er in

Det er meget godt alt sammen, men kan vi få noget menneskeforståelig fakta på bordet? Fortæl os lidt om hvad det rent praktisk går ud på, istedet for bare at komme med abstrakte, indforståede opridsninger.

Ideen er jo at arkitekten skal træde et skridt længere tilbage (meget mindre bitnusser i forhold til vores diskution den anden dag :-) ) og eksempelvis se IT/Software som en måde for virksomheden at få en strategisk fordel. Den fordel skal opstå ved eksempelvis at se på de processer der er i virksomheden og se om man kan transformere dem til (automatiseret) software. Det vil give en strategisk fordel, og det er der meget fokus på at opnå dette. Alle kan købe et software system, det vil gøre alle "lige" konkurrencedygtige, men hvis man har nogle (automatiserede) softwareprocesser der er forankret i software så vil man herigennem få nogle fordele ved at kunne flytte sig hurtigere end konkurrenterne - eller frigøre resourcer i virksomheden til at fokusere på at forbedre endnu mere..

Ideen er så at arkitekten fokuserer på de processer der er i virksomheden og får dem dokumenteret, og efterhånden implementeret dem (eks fra kunden besøger vores hjemmeside til de har modtaget en DVD med posten). Arkitekten kommunikere så dette til udviklerne (som stadig skal arbejde med objekter) men som store hele nu bygger software til at underbygge processer med.

Korte af de lange :-)

Hørt, Brian. Godt forklaret.

Ideen er jo at arkitekten skal træde et skridt længere tilbage (meget mindre bitnusser i forhold til vores diskution den anden dag :-) ) og eksempelvis se IT/Software som en måde for virksomheden at få en strategisk fordel. Den fordel skal opstå ved eksempelvis at se på de processer der er i virksomheden og se om man kan transformere dem til (automatiseret) software. Det vil give en strategisk fordel, og det er der meget fokus på at opnå dette. Alle kan købe et software system, det vil gøre alle "lige" konkurrencedygtige, men hvis man har nogle (automatiserede) softwareprocesser der er forankret i software så vil man herigennem få nogle fordele ved at kunne flytte sig hurtigere end konkurrenterne - eller frigøre resourcer i virksomheden til at fokusere på at forbedre endnu mere..

Ideen er så at arkitekten fokuserer på de processer der er i virksomheden og får dem dokumenteret, og efterhånden implementeret dem (eks fra kunden besøger vores hjemmeside til de har modtaget en DVD med posten). Arkitekten kommunikere så dette til udviklerne (som stadig skal arbejde med objekter) men som store hele nu bygger software til at underbygge processer med.

Korte af de lange :-)

Tak for forklaringen, det gør det noget mere håndgribeligt.

Men det afføder nogle nye spørgsmål. Fx: hvordan adskiller det sig fra hvordan arkitektur udvikles idag, udover at det måske er nogle andre buzzwords der bliver brugt til at betegne den, i min optik, præcist samme arbejdsgang? Og måske mere vigtigt: hvor kommer "objekter er yt" så ind i billedet henne, som overskriften påstår, hvis processorientering er et ekstra lag udenom den objektorienterede praktiske kode, som stadig vil være nødvendig?

Arkitekten kommunikere så dette til udviklerne (som stadig skal arbejde med objekter) men som store hele nu bygger software til at underbygge processer med.

Med andre ord..."Objekter er yt" og "Den objektorienterede tilgang er på vej ud" er udtryk som ikke har hold i virkeligheden ?

Så synes jeg nu ikke, at der er så meget nyt under solen. Jeg synes nu, at software arkitekter i mange år har distanceret sig fra, hvordan et system skal implementeres (OO, funktionelt, web, C/C++, XML, whatever) og i hvert fald i starten holder sig på et mere abstrakt plan og prøver at gøre processer mere automatiserede.