IT-Universitetet: Objekter er yt, processer er in

Den objektorienterede tilgang er på vej ud og må lade pladsen for procesorientering, hvis det står til IT-Universitetet. Nutidens arbejdsgange er løbet fra objektorientering, lyder meldingen.

Nutidens it-systemer er ude af trit med den måde, viden og informationer skal behandles på i et moderne samfund, mener en forskergruppe ved IT-Universitetet i København.

Software, som vi kender den, kan kun løse opgaver enkeltvis, men ikke tænke i sammenhænge, og det spiller ikke sammen med moderne arbejdspladser. Derfor kræves der et paradigmeskifte i tilgangen til it-systemer for at rette op på det, lyder meldingen fra forskerne.

»Der stilles stadig større krav til effektive arbejdsgange, omstillingsparathed, ligebehandling og kvalitetssikring, ikke mindst i forbindelse med globaliseringen. Det er netop hvad procesorienterede it-systemer kan hjælpe med til, men det kræver nytænkning både med hensyn til hvordan it-systemerne designes, og hvordan de anvendes,« udtaler lektor ved IT-Universitetet, Thomas Hildebrandt, i en pressemeddelelse.

Objektorientering er forældet
Indtil nu har it været præget af den objektorienterede tilgang, som tager udgangspunkt i objekterne, der administreres, hvilket for eksempel kan være et dokument til ansøgning om forældreorlov.

Men den objektorienterede tilgang er forældet, mener forskerne, og fremtidens software skal være procesorienteret. Eksempelvis er en ansøgning om forældreorlov en del af en proces, der begynder før barnet fødes, og først afsluttes mange år efter.

IT-Universitetet og Københavns Universitet har dannet et nyt netværk mellem offentlige instanser, virksomheder og it-forskere, der alle interesserer sig for procesorientering.

»En af virksomhederne i netværket har netop lavet en procesorienteret løsning til administration af forældreorlov. Stort set alle virksomheder i Danmark, for slet ikke at tale om forældrene, ville kunne få gavn af sådan et system, ikke mindst hvis det kunne garanteres at leve op til loven og nemt kan tilpasses i forbindelse med lovændringer,« udtaler Thomas Hildebrandt.

Også de studerende på IT-Universitetet skal lære at tænke i det nye paradigme, og procestænkningen er et nøgleelement i den nye bacheloruddannelse i Global Business Informatics på ITU.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (30)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Henrik S. Larsen

Hvad var der så?
Det ved vi ikke, hvis Zeus ikke opfyldte vores krav
så opfandt vi Fandalf (ironi forekommer og ja har lige set LOTR)

Jeg har tit en fornemmelse af, at hvis ting fungerer sådan "ok" (Cobol, PL/1, C#, Java, C, C++, et al) så er man sandelig nødt til at opfinde noget nyt. Ellers har man ingen eksistensberettigelse.

Sidney Lee anyone?

  • 0
  • 0
Jacob Christian Munch-Andersen

Hvad betyder processorientering ? F.eks. mere taylorisme eller mere fleksibiltiet?

Først tænkte jeg at det nok havde noget med parallel programmering at gøre, men når man læser artiklen lyder det som noget lidt blødere.

Det fremgår så også af artiklen at procesorientering åbenbart er en diametral modsætning til objektorientering. Man kan måske slet ikke anvende objekter når man programmerer procesorienteret? Det lyder ikke så tiltalende.

  • 0
  • 0
Jesper Louis Andersen

Ideen med at opfinde en "ny" måde at anskue programmering på er at sætte os i stand til at beskrive en problemstilling nemmere. Der bliver stadig programmeret i assembler i dag, men størstedelen af programmerne er skrevet i et eller andet passende programmeringssprog. Det skyldes at sproget gør det nemmere for programmøren at ræsonnere omkring hvad programmet gør.

Når en kunde f.eks. skal oprettes i et system gennemgår kunden en proces. Kunden sætter processen i gang via en hjemmeside, og derefter skal en supportafdeling måske godkende kundens køb. Eller forældreorloven fra artiklen, hvor processen kan stå stille i et år før den skal videre.

Det kan sagtens modelleres på nogenlunde fornuftig vis i assembler, C# eller Java - men det her er forskning i om der findes en anden måde at anskue procesmodelleringen på, som er fordelagtig og gør det nemmere at programmere. Det ville medføre at man kunne prøve flere processer af og at man ville kunne konstruere processer der var mere komplekse fordi de nu kan overskues.

Et godt eksempel på hvad det kan føre til er regnearket. Det er reactive programming

http://en.wikipedia.org/wiki/Reactive_programming

hvor opdatering af en celle i arket automatisk propagerer opdateringer til andre celler i en kaskadeeffekt.

  • 0
  • 0
Jan Flodin

Det skræmmer mig at procesorientering udnævnes til noget nyt. Jeg anvendte procesorientering som salgsargument allerede i midtfirserne, hvor vi i mit firma solgte office automation ud fra slagord som "kontorets samlebånd".

Nå ja, det var selvfølgelig ikke alle der forstod hvad vi mente, men med paraller til bilindustriens opblomstring som følge af Fords opfindelse af samlebåndet gik det da op for de fleste, at de store automatiseringsgevinster som regel kommer ved at fokusere på processen og ikke blot de enkelte opgaver/objekter.

Jeg indrømmer dog at en del IT-folk i mellem tiden er blevet forblændet af objektfokusering så det er nok derfor at vi - ligesom i tøjbranchen - nu skal tilbage til firserne for at finde tidens trend.

Det er lidt trist at være en gammel mand for nyheder viser sig ofte at være gammel vin på nye flasker.

  • 0
  • 0
Torsten Holtse

jeg kunne også godt bruge lidt mere forklaring, men uden at vide præcist hvad procesorienteret programmering går ud på så lyder det meget snævertsynet fra ITU's side. I objektorienteringens barndom var det det jo også det ultimative svar, men senere har man jo fundet mangler. Det samme vil vel ske med procesorientering (jeg kan da allerede se et par stykker rent logisk). For nu rigtigt at udbrede min .NET-entusiasme så vil jeg da mene, at .NET's tilgang med forksellige muligheder, der alle kan snakke sammen er en langt bedre idé end at skifte hele moleviten ud :-)

  • 0
  • 0
Kim Madsen

Objekt orientering er ikke en modsætning til process orientering. Tværtimod.
De to går fint hånd i hånd. En process er et forløb af operationer der foretages på en eller flere objekter, som så kan resultere i at objekterne enten bare modificeres eller at der skabes nye. Alt sammen under den samme "hat" nemlig processen.
Teknisk set, så vil den styring der er på en process ofte også egne sig til at blive beskrevet i en objekt orienteret metodik.

med venlig hilsen
Kim Madsen
kbm@kbmitexperts.dk

  • 0
  • 0
Torben Hoffmann

-1 for lidt tynd beskrivelse.
+2 for lidt tynd beskrivelse som give os mulighed for at byde ind med en masse!

Object Process Methodology (OPM) prøver faktisk at få objekter og processer til at hænge bedre sammen - se http://en.wikipedia.org/wiki/Object_Process_Methodology for mere info eller læs en af de artikler der findes frit tilgængeligt.

Jeg er "vokset op" med stærk procesorientering i form af CSP og lignende formalismer samt masser af matematik, så jeg har altid haft svært ved nogle af de mere eksotiske hjørner af objekt-orientering, men OPM giver mulighed for at fange begge sider mere fornuftigt, men det kræver en anden måde at tænke på.

Men der er vel ikke noget mærkeligt i at tiden går og man får brug for nye værktøjer og teorier for at kunne klare de udfordringer som den nye verden bringer? Journalistisk er det selvfølgelig spændende at kaste lidt benzin på et paradigme-bål, det lærer man jo i de fleste kurser om populær formidling af forskning og det ser ud til at Thomas Hildebrant har benyttet dette i sin pressemeddelelse eller at V2-journalisten har fokuseret på benzinen.

  • 0
  • 0
Thomas Hildebrandt

Rigtigt Torben :-) Og juleferien og forum-formen på V2 kan sagtens undskylde, at der ikke blev tid til at uddybe artiklen mere fra journalistens side.

Min påstand er ikke, at processorientering er en diamentral modsætning til objektorientering, men at objekter som vi kender dem er utilstrækkelige til design af software, der skal understøtte nutidens arbejdsprocesser eller for den sags skyld it- og processorarkitekturer.

Som Kim Madsen så rigtigt påpeger, vil der stadig være data, objekter (eller tjenester) der behandles eller kaldes af processerne. Vi holdt heller ikke op med at anvende relationelle databaser, da vi begyndte at programmere med objekter.

Man kunne også sige at jeg sammen med en række virksomheder og kollegaer også har meldt mig under fanerne i jagten på de parallelle processers hellige gral ligesom min tidligere ph.d.-kollega fra Århus,
Kresten Krab Thorup, og mange andre forskere verden rundt.

Mit mål er dog at bygge bro mellem de klassisk datalogiske udfordringer i sprog-design (som Kresten og jeg er opflasket med i Århus) og de udfordringer der ligger i at finde primitiver og teknologier der også passer til menneskelige arbejdsprocesser.

Jan Flodin bemærker helt rigtigt at procesorientering har rødder tilbage til office automation, workflow management etc. Andre forskere
bruger betegnelsen Process-aware information systems. Så nej, processorienteringstanken er ikke ny.

Det der er nyt er, at både lovgivningsprocesser, forretningsprocesser, arbejdsprocesser, globalisering, serviceorienterede it-arkitekturer og
flerkerne computerarkitekturer i dag skriger på
processorientering.

Der er derfor en stigende interesse i at finde måder at beskrive processer og bygge it-systemer orienteret efter disse processer. Jesper Louis Andersen har derfor helt ret i at et af temaerne for netværket i processorientering er hvordan et
processorienteret programmeringssprog kan gøre det nemmere at implementere og vedligeholde velfungerende processorienterede it-systemer.

Helt konkret er WS-BPEL 2.0 og BPMN (1.2 og snart 2.0) dukket op som standarder til at beskrive forretnings- og arbejdsprocesser.

Der er imidlertid mange problemer med WS-BPEL og BPMN. Et grundlæggende problem er, at det mildest talt er en rodebutik der for at opnå konsensus mellem IBM og Microsoft blander gammel vin (i form
af flow charts og while-løkker), spædet op med interessante idéer omkring message passing (dybt nede inspireret af Robin Milner's pi-calculus) og XML som primitiv datatype, men ignorerer meget andet
(herunder viden om sikker håndtering af parallelle processer, samt de gode ting vi opnåede med objektorientering).

BPMN forsøger at give en grafisk standard med udgangspunkt i det samme tankegods som BPEL. Ifølge den kommende BPMN 2.0 standard er det primære designrationale, at forretningsfolk i årevis har tegnet flowcharts....

At BPEL og BPMN er de facto standarder betyder, uanset deres begrænsninger, at mange forståeligt nok vil gribe til disse for at prøve at løse deres behov for at beskrive processer. Det er trods alt
mange gange nemmere for chefen/juristen/processmedarbejderen at forstå
et flow chart (eller aktivitetsdiagram) end en stump Java eller C# kode. Af samme grund forsøger Microsoft sig med Windows Workflow Foundation til .NET. Det er jo også tiltalende at disse diagrammer
skulle kunne flyttes frit mellem platforme. Under den første workshop for dynamiske og deklarative business processes (DDBP 2008) hvor jeg
gav et foredrag sidste år hørte jeg sågar at Ericsson ville gå fra Erlang til BPEL, fordi det var blevet de-facto standard....

Desværre er sprogene og standarderne ud over at være rodede også uformelle, så det er kun lykkedes for de store udbydere at implementere dem NÆSTEN ens. Det skrev en specialestuderende fra DIKU
sammen med hans vejleder og jeg selv en artikel om til næste års Symposium On Applied Computing (SAC 2010).

Det er dog et lige så stort problem at der mangler etablerede designmønstre og sproglig understøttelse for sikker håndtering af parallelisme, grænseflader mellem processer, samt genbrug og nedarvning af processer.

Det er også et kæmpe problem at flowcharts og while-løkker bare ikke er særlig fleksible. Processorientering handler netop ikke om
Taylorisme, men om fleksibilitet (tak Stephan for at påpege at det ikke var soleklart i artiklen). Om at kunne lave it-systemer der passer til (skiftende) arbejdsprocesser og lovgivning - og ikke som
det i dag er tilfældet, at man mange gange bliver nød til at indrette arbejdsprocesser og lovgivning efter hvad der er muligt eller foreskrevet af de nuværende it-systemer.

Vores lovgivning eller moderne arbejdsgange er ikke oplagte at beskrive med flowcharts eller en whileløkker. Bliver der ændret en
paragraf eller behov for at gentage eller springe en del-opgave over skal programmet ofte laves radikalt om...! (Her er deklarative, regelbaserede sprog mere velegnede. Det handlede mit foredrag på DDBP
2008 om). Dernæst kommer afhængigheder af lokationen og andre resourcer i arbejdsprocessen, uddelegering af opgaver, samarbejde på tværs af virksomheder og lande.

Mere teknologinært, så er vores applikationer til moderne event-drevne, kontekst-sensitive, flerkerne systemer heller ikke oplagte at beskrive som flowcharts eller whileløkker.

Formålet med netværket for procesorientering der omtales i artiklen er derfor at virksomheder og offentlige instanser i Danmark går sammen
med forskere om at finde de rette teknologier og metoder for process-orienteret it - og herunder inddrage både formelle matematiske processmodeller og typeteori, menneske-maskin interaktion, CSCW og en
kritisk stillingstagen til teknologiens indvirkning på arbejdsprocesserne.

Første skridt blev taget den 7. December hvor medlemmer af netværketet
mødtes til et seminar om process orienteret på IT Universitetet - se henvisning på http://www.trustcare.dk

Jeg vil meget gerne høre fra andre der bokser med process-orientering og gerne vil dele ud af deres erfaringer og udfordringer.

  • 0
  • 0
Anonym

Thomas

OK - tak for uddybningen.

Vær opmærksom på

  • fælden at tro at man modellerer det endelige system. Konstant forandring og parallel innovation stiller store krav til fleksibiliteten og specielt de semantisk interoperable aspekter på interface-siden, så man kommer tættere på en fleksibel lego-klods model koblet med processmodellering end en fast defineret one-size-fits-all workflowmodel.

  • at man specielt på sikkerhedssiden er dårligt kørende i sundhedssektoren - den "nationale serviceplatform" har mere til fælles med en halvdesparat nødløsning som ignorerer og fjerner sikkerheden end en model for fremtidens sundhedssystemer. Vi skal have fokus på processisolering end-to-end.

Sikkerhed er en effektivitets- og innovationsdræber når man undervurderer de hastigt stigende krav og legacy-effekten af ikke-tilpasningsorienteret sikkerhed. I dag falder man i begge fælder samtidig.

Det går helt galt i pervasive healthcare fordi processerne overlapper i det åbne trådløse rum og serverne ikke kan betragtes som sikre. At modellere parallelt isolerede og samtidig dynamisk forandrende processer på en hospitalsgang er en pokkers kompleks øvelse som vi helt sikkert har behov for bedre værktøjer til at håndtere.

  • 0
  • 0
Thomas Hildebrandt

Hej Stephan

helt enig! Det er netop den øvelse jeg
har kastet mig over sammen med mine kollegaer i forskningsprojektet trustcare.

Selv hvis vi ikke skulle nå frem til en endelig
løsning er jeg overbevist om at øvelsen
i sig selv har positive sidegevinster, som f.eks
øget viden om og opmærkspmhed på processoriemteringsprimitiver,
sikkerhed og fleksibilitet.

Ikke mindst når man kombinerer det med netværksarrangementer, undervisning af kreative og ambitiøse studerende som tager denne viden med ud i verden når de forlader ITU.

  • 0
  • 0
Anonym

Thomas

Jeg kender godt Trustcare og forsøger blot at sætte fingeren på den svære og kritiske paradigme problemstilling.

Vi arbejder med de samme områder blot fra forskellige vinkler.

Priway og RFIDsec er hjemmehørende på 5te og har begge sundhedssektoren som det centrale fokusområde og innovationsdriver.

Morten underviser på Sundheds-IT i brugervenlighedsdesign. Jeg forsøger at få rettet op på paradigmeforståelsen i sikkerheds- og strategiundervisningen så man kan komme tilbage til en kunde- og innovationsorienteret forståelse - som alle der kender blot en smule til paradigmebarrierer er det en sej øvelse.

Jeg brugte en hel del tid i HYDRA-projektet på at analysere og designe modelbaseret middleware til ambient devices med fokus på netop det distribuerede sundhedsvæsen.

Desværre nåede HYDRA ikke i mål, men måtte stoppe på halvvejen og ofre både sikkerhed og interoperabilitet for at skabe funktionalitet indenfor projekthorisonten - det typiske problem i forskningsprojekter. Men vi tog mange dybe spadestik og må så blot erkende at der er åbne forskningsopgaver.

Men man kan løse problemer og det er dybt kritisk for samfundsøkonomien er vi får flyttet hovedfokus over på slutkunden (borgeren) og at understøtte innovationen i tilpasningsprocesserne fremfor kun at se på den stivnende centrale styring og usability for behandleren.

Mere præcist at udvikle paradigmet fra Bruger-dreven innovation til Behovsdreven innovation hvor behovet valg driver innovationen.

Den nuværende tilgang til digitalisering generelt men specielt i Danmark opfatter jeg som et stærkt ideologisk "DDR 2.0 paradigme". Danmarks deroute siden starten af 90erne kan i min analyse direkte og entydigt henføres til DDR 2.0 paradigmet.

Teknisk er vi i stedet for at løfte opgaven med semantic web ved at bygge en forældet og stiv mainframeforståelse ovenpå den åbne TCP/IP forståelse - det er en hån mod det flotte forarbejde som internettets pionerer gjorde.

Men semantisk interoperabilitet er ikke en simpel øvelse, specielt ikke på sikkerhedsområdet. Det er nemt at lave sikkerhed når default er ja - svært når default er nej som det gælder for specielt alle personhenførbare data.

Se f.eks.
http://www.ambafrance-dk.org/IMG/pdf/ICT_Privacy_20090924.pdf
http://ec.europa.eu/justice_home/news/events/workshop_pets_2009/presenta...

  • 0
  • 0
Jan Flodin

Hej Thomas

Tak for din noget længere forklaring som giver mig en række associationer til det koncept som bl.a. Gartner Group kalder Workload Automation.

Jeg tror det kunne være relevant for dig at se lidt nærmere på det og da jeg (tilfældigvis) sælger produkter i det område vil jeg meget gerne bistå med relevante links. Send mig en mail på jan_flodin@bmc.com hvis du vil vide mere.

Det sjove er faktisk at Workload Automation tilgangen tager udgangspunkt i gammeldags batch scheduling tankegang, men det er selvfølgelig også avanceret processtyring.

  • 0
  • 0
Thomas Hildebrandt

Hej Stephan,

tak for mere info - jeg kender jo også godt Priway og RFIDsec, men har til gode at sætte mig grundigere ind i hvad jeres løsninger kan tilbyde.

Jeg enig i at det ikke er en simpel løsning.

Jeg tror også vi er enige i at sikkerhed burde håndteres helt anderledes end det gøres idag.

Analogier til DDR vil jeg dog holde mig fra :-)

  • 0
  • 0
Torben Hoffmann

Hej Thomas - tak for en god uddybning.

I lyset af det du skriver tror jeg det vil være en god idé at se lidt på OPM (som jeg nævnte før), da det på mig virker som om OPM på en eller anden måde har fået taget hul på problemstillingen med at få statiske og dynamiske aspekter gjort mere ligeværdige.

Ang. Ericssons skifte fra Erlang til BPEL, så tror jeg at der er tale om noget forstyrret snak fra en som ikke forstår hvad Erlang går ud på! Erlang er lavet til telekom (og kan bruges andre steder med succes) mens BPEL (i mine øjne) er født til business processes(TM), hvilket ikke umiddelbart har noget med Erlangs processer...

Men at Ericssons fokus skifter fra problemstillinger, hvor Erlang er en central spiller til områder hvor BPEL er vigtigt virker derimod helt op ad det semi-IBM stunt Ericsson ser ud til at være i gang med.

  • 0
  • 0
Kresten Krab Thorup

Man kunne også sige at jeg sammen med en række virksomheder og kollegaer også har meldt mig under fanerne i jagten på de parallelle processers hellige gral ligesom min tidligere ph.d.-kollega fra Århus,
Kresten Krab Thorup, og mange andre forskere verden rundt.

Mit mål er dog at bygge bro mellem de klassisk datalogiske udfordringer i sprog-design (som Kresten og jeg er opflasket med i Århus) og de udfordringer der ligger i at finde primitiver og teknologier der også passer til menneskelige arbejdsprocesser.

Jeg er også lidt ked af den måde artiklen om mit projekt blev vinklet i artiklen den anden dag. Jeg mener ikke at proces-forståelse er i modsætning til objekt-orientering.

  • 0
  • 0
Thomas Hildebrandt

Formålet var selvfølgelig ikke blot at sige noget kontroversielt.

Jeg håber den længere forklaring og efterfølgende debat hjalp en smule. Pressemeddelelsen gav ikke plads til megen forklaring af hvad det vil sige at være processorienteret (- og den der var blev klippet ud i artiklen :-)

Formålet var at gøre opmærksom på, at der er stigende interesse og behov (uden for universiteterne) for fleksible it-systemer orienteret omkring processer, såsom ESDH, workflow og business process management systemer.

Interessen har jeg mærket i form af en meget positiv tilslutning til et vidensnetværk for procesorientering vi har etableret sammen med virksomheder (brugere såvel som udbydere af process orienterede it-systemer). Herunder KL der med deres projekt arbejdsgangbanken har beskrevet hundredevis af arbejdsgange i kommunerne i BPMN med henblik på identificere best practices på tværs af kommuner. Det
virker oplagt, at for at drage fuld nytte af disse beskrivelser skal de administrative systemer der understøtter arbejdsgangene kunne forstå disse processbeskrivelser.

Dette formål gik lidt tabt i den skarpe vinkel på at "forskerne på ITU siger at objektorientering er yt".

Jeg står dog fuldt ved at det ikke er oplagt (men selvfølgelig ikke umuligt) at programmere denne type systemer i objektorienterede sprog som vi kender dem.

Dermed ikke sagt at objektorientering ikke kan bruges side om side med processorientering.

  • 0
  • 0
Anonym

Thomas

Først og fremmest ser jeg ingen uenighed. Artiklens problemområde er måske mindre godt fremstillet, men der er klart behov for bedre værktøjer og pervasive healthcare på et hospital er et af de mest komplekse cases.

Men man bør som element fokusere på hvad det vil sige at lave "gode" løsninger og herunder "gode" processværktøjer.

Analogier til DDR vil jeg dog holde mig fra :-)

Find gerne en bedre analogi. Men den er rammende og tjener sit formål ved at provokere paradigmet som netop er karakteriseret ved de implicitte antagelser - bevidstgørelse er kritisk for forandring.

Taylorisme havde ligesom dårlig usablity kun lokale konsekvenser, men nu er teknologidesign ofte det samme som at lovgive - bare stærkere. Uden valgfrihed virker dårlig teknologidesign snærende, dikterende og begrænsende. Dvs. taler vi offentlige, infrastruktur eller tilsvarende områder kan teknologes designes til at udgøre et diktat - eller det modsatte.

Teknologidesign er værdidesign. Hvad enten man vil det eller ej. Spørgsmålet er kun om man er bevidst om hvad man gør. Hvis man ikke bevidst undgår at lave diktater, så er det diktater.

Når jeg kategoriserer det primære herskende teknologiparadigme som "DDR 2.0" er det fordi man i praksis skaber stivnende legacy og samtidig ligger kontrollen centralt istedet for at fokusere på interoperabiliet, fleksibilitet og styring via de individuelle behovsvalg.

Pointen er at det IKKE er tilstrækkeligt at gøre det nemt at ændre systemerne, hvis det ikke kan ske run-time drevet af behovet og kundernes valg.

Hvis en processforståelse tror at man "optimerer" et system ved at lave "processen" uden at sikre rum for at processer skal kunne ændre sig og gøre det i forskellige retninger dikteret af slutkundens aktuelle behovsvalg, så er man netop i en planøkonomisk forståelse hvor teknologien dikterer behovet fremfor omvendt.

Inputtet til processforståelsen er kravet om dynamisk opgradering og stærk interoperabilitet, dvs. muligheden for FORSKELLIGE parallelle processer (måske med forskellig teknologisammensætning) som gradvist ændrer sig i forhold til en stadigt mere nuanceret behovsforståelse.

Sikkerheden selv er faktisk det sværeste område fordi sikkerhedsteknologi kontinueret degraderer og behovet bliver stadigt mere nuacneret samtidig med at sikkerhedsaspekterne i protokollerne er den lart største kilde til legacy.

I praksis er den kritiske drivkraft borgerens FRIE VALG mellem alternativer presset frem af priskonkurrencens nødvendighed. Og det mener jeg apolitisk uanset hvem som betaler, dvs. den politiske omfordeling.

Kort sagt - du kan ikke undslippe problemstillingen fordi dine designvalg har konsekvenser. Vi taler om store konsekvenser - det er selve hovedårsagen til at dansk økonomi har været i deroute de sidste mindst 15-20 år. De initielle gevinster ved teknologidrevet tvang bliver hurtigt overhalet af de akkumulerende ineffektiviteter ved manglende dynamik.

Det danske selvbillede har behov for et ordentligt skud realisme og back-to-basics. Og det sker kun hvis dem som kan gør noget ved problemerne.

  • 0
  • 0
Thomas Hildebrandt

Stephan,

jeg er helt enig i at systemer skal designes
så de kan tilpasses nye (og individuelle) behov dynamisk, dvs run time.

På den måde kunne vi udbrede vores evne til at inddrage
brugere under designfasen til også at gælde brugsfasen.. (tilpasning og evolution ville blive en naturlig del af drifsfasen).

Hvis man ser på historien for EPR i Danmark og lukningen
af Apex skyldtes det så vidt jeg er orienteret netop at det
blev for dyrt og besværligt at vedligeholde.

Hvis man samtidig kunne gøre systemerne
så gennemsigtige at man rent faktisk kunne have
begrundet tillid til at de gjorde det de skulle tror jeg faktisk
vi kunne få løsninger der ikke bare ville virke i Danmark
men også kunne eksporteres, e.g. til USA (jvnf tidligere tråd om
fejlslagne it systemer i det amerikanske sundhedsvæsen)

Glæder mig til tage fat på disse udfordringer i det nye år sammen med dig og alle
de øvrige der har meldt positivt tilbage!
nye år, indtil da, godt nytår!

  • 0
  • 0
Anonym

Thomas

Igen - jeg ser ingen direkte modsætninge. Vi er formentlig ret enige og jeg ser også en klar tendens i den rigtige retning.

To sproglige paradigme-ting af væsentligt betydning fordi de har og skal have konsekvenser.

På den måde kunne vi udbrede vores evne til at inddrage brugere under designfasen til også at gælde brugsfasen.. (tilpasning og evolution ville blive en naturlig del af drifsfasen).

Enig - men vær opmærksom på at den PRIMÆRE bruger altid er slutbehovet, dvs. borgeren. Man begår oftest den fejl at antage at borgeren er objekter man gør noget ved i stedet for de primære subjekter som skal kunne styre processerne (også hvis de har en læge som rådgiver eller lign. etc.) og som samtidig samfundets mest værdifulde og mest sårbare aktiv.

Problemet er at der er tunge historiske beslutninger, der skal laves om i et organisatorisk-politisk beslutningsrum domineret af særinteresser med en klar mangel på borger-repræsentation, dvs. de egentlige brugere er dårligt repræsenteret og i så tilfælde højst som det rene gidseltagning.

Det meste "bruger-dreven" innnovation er ren peudo-legitimering fordi man aldrig præsenterer borgerne for modeller hvor de har kontrollen medmindre det er for bevidst at kunne sabotere sådanne modeller.

Hvis man samtidig kunne gøre systemerne
så gennemsigtige at man rent faktisk kunne have
begrundet tillid til at de gjorde det de skulle

Enig, men det er i praksis mindre interessant om systemer tilsyneladende gør det, de skulle, hvis

a) De er dårligt planlagt, dvs. at målet for "systemet" enten er forkert eller ikke kan tilpasse sig. Du kan gøre det forkerte perfekt og stadig være helt gal på den og låst af legacy selvom designet engang var godt.

b) Processerne ikke er isolerede, dvs. at kontrollen glider og fortsat skævvrider magtkonstruktionerne væk fra slutbehovet til særinteresser (som altid trækker for at få magt).

tror jeg faktisk vi kunne få løsninger der ikke bare ville virke i Danmark men også kunne eksporteres, e.g. til USA (jvnf tidligere tråd om
fejlslagne it systemer i det amerikanske sundhedsvæsen)

Pointen er ikke at jeg er uenig i det, du siger - og jeg ser referencen til den tidligere tråd - men at det ikke er tilstrækkeligt hvis man ikke oversætter ovenstående til krav til teknologidesign.

Danmark har aldrig kunnet lave offentlig systemeksport. Det skyldes efter min opfattelse primært at vi aldrig laver systemer som respekterer borgerne (sikrer at slutbehovet har magten over processtilpasningen). I Danmark laver vi offentlige it-systemer for centralt at kontrollere borgerne og samfundsøkonomiske processer (dvs. med systemet selv og navnlig DJØF-systemet i centrum).

Sådanne modeller er uforeneligt med både demokrati og de kritiske markedsøkonomiske processer og derfor stritter andre som har en bedre forståelse for samfundets grundprincipper naturligt imod.

Du kan sige det sådan at fejlen er at det offentlige beslutningssystem antager tillid (hos borgerne) men udviser ingen tillid selv (overfor borgeren) og samtidig via systemdesignet underminerer tilliden (ved at gør borgeren til styringsobjekt i stedet for den styrende kun begrænset af de konkrerkte krav). Før vi får gjort op med den tilgang vil Danmarks deroute fortsætte.

Hvis det danske velfærdssamfund skal overleve er rammer for, værktøjer til og muligheden for at processer kan tilpasse sig slutbehovet uden at blive dikteret er ikke bare en mulighed, men en nødvendighed.

Godt Nytår og vi ses i det nye år med ærmerne smøget op ;-)

  • 0
  • 0
Jens Madsen

Normalt forstår jeg en process, som et stykke software, der kan køre parallelt med andet, og hvor data typisk udveksles via fifoer, ligesom i Erlang.

Når processorientering, kan betragtes lidt som en modsætning til OOP, skyldes det den måde, som OOP opreklamerede sig selv i sin tid: Man forsøgte at forklare, at en flue var et objekt, at en banan var et objekt, at en bil var et objekt osv. Meddens at virkeligheden er, at de ikke er objekter - for objekter kan ikke køre parallelt. Det kan processer. Hver enkelt flue, og hver enkelt køleskab, kan arbejde samtidigt og kommunikere med hinanden, meddens de arbejder parallelt. De kommunikerer ikke ved at lave "kald" til hinanden, men ved at skubbe til hinanden - altså langt mere i lighed med processer, der kommunikerer via fifoer. Sender en flue, noget til en anden flue, vil det være først ind, først ud. Og ikke være sidst ind, først ud, som ved stakke - og ved OOP.

OOP "stjal" områder som indkapsling, privat/public osv fra parallelverdenen, og implementerede som et proceduralt kaldesystem, hvor at såvel parallelismen, som fifo kommunikationen mellem komponenterne blev vendt på hovedet. I praksis, så langt fra virkeligheden, som kunne opnås.

I hardware giver dette problemer. FIFO kommunikation giver mulighed for parallelisering og at hardwaren kan pipelines (pipelines er fifo struktur, og kan ikke være stak orienterede). Stak kommunikationnen, og den procedurale måde at tænke på, giver problemer. OOP har ikke "løftet" sig bort fra dette, og er stadigt stak orienteret, og procedure orienteret. Procedurene er bare kapslet ind. Men man har ikke forladt måden at tænke på.

Når tingene kører parallelt, og kommunikerer via fifoer, så giver det mulighed for parallelisme, bedre mulighed for matematisk analyse, og det giver mulighed for pipelining i hardware. Det egner sig til implementering, meddens OOP giver problem. Der skal være fifoer imellem parallele processer, for at de fysisk kan implementeres optimalt. Stakke mellem processer, er ikke fysisk realiserbare og ligger langt fra den fysiske virkelighed. Men tæt på OOP. Denne fejl, gør ikke kun at OOP ikke har noget med virkelighedens objekter at gøre, men også at de ikke lader sig implementere effektiv i hardware og i parallele sammenhænge. En FIFO kommunikationsmetode, og parallelitet, er her langt mere naturlig, og muligt at implementere, end en metode der ikke giver mulighed for den forsinkelse, som FIFOer muliggør. FIFO kommunikationen gør, at der kan være lange kommunikationslinier og forsinkelser mellem processer, uden at funktionen "ombyttes", eller at hastigheden går ned. En fifo kommunikation mellem parallele processer, giver tilmed en deterministisk funktion, hvorimod at stak orienterede metoder, ofte kan give problem med programmering af parallelisme, så det er deterministisk, og det ses ofte at metoder der ikke beroer på køer/fifoer, medfører indeterminisme. OOP giver i nogle tilfælde også meget komplekse måder at løse problemer på, fordi man søger at løse naturlige parallele problemstillinger, ved hjælp af tilstandsmaskiner. En tilstandsmaskine søger på kunstig vis, at ved hjælp af tilstande kunne emulere flere processers forskellige indstruktionspointer (hvor langt de er kommet i processen) - og søger at løse en parallel opgave ved hjælp af et tilstandsdiagram. Dette medfører både at opgaven bliver uoverskuelig, i forhold til en parallel tilgangsmåde, og samtidigt bliver den umuligt at håndtere, når den skal gøres parallelt, og køre optimalt ved anvendelse af processorens parallele resourcer.

Artiklen, og dens "process" orientering til løsning af forældreorlov, er måske en smule misbrug af begrebet. Men ikke værre, end OOP's forsøg på at overbevise verden om, at alt var objekter. I sin tid, blev ved forsøget på introduktionen til objekter, anvendt metoder som at vise et dyr, f.eks. en flue, og påstå, at denne også var et objekt. Sandheden er, at alt er processer, som arbejder parallelt, og kommunikerer via køer. Alt er processer, og ikke objekte på den måde, som det kodes på i OOP.

  • 0
  • 0
Kim Madsen

Jeg er fuldstændig enig i at et objekt og en process ikke er samme ting. En process er, som du også beskriver, noget der kører over tid, mens et objekt er en samling af data og metoder som kan påvirke data og evnt. producere nye objekter.

Et objekt afvikles ikke af sig selv. Der skal en process til at afvikle metoderne i objektet og populere det med data.

Det er dog helt forkert at se dem som modsætninger, da jeg meget nødigt ville undvære objekter i en process. Objekter er ganske geniale til at holde samling på oplysninger og forretningslogik vedr. disse oplysninger.

Det er heller ikke en modsætning at have et FIFO (altså kø) baseret kommunikations system som er objekt orienteret. Jeg har skam selv udviklet et sådan helt fra scratch, og det er udviklet helt og holdent med objekt orienterede metoder, men afvikles i høj grad trådet (altså i flere parallelt kørende processer).

Objekt orientering er 'kun' en måde at beskrive øjebliksbilleder på og de funktioner man kan bruge til at påvirke øjeblikket. Men det er en meget effektiv måde at gøre det på.

For at kæde øjebliksbillederne sammen, skal indføres en eller anden process.

Det kan være så simpelt som en enkelt tråd, hvor objektet(objekterne) påvirkes sekventielt, hvilket løser ca. 65% af alle udviklingsopgaver. Og det kan være så kompliceret som at have fabrikker der spytter 'processer' ud (altså objekter der hver især har en eller flere tråde tilknyttet, som bearbejder en eller mange flere objekter, altsammen i parallel).

At se process orientering som den gamle sammenkobling mellem Excel og Word (altså Windows automatisering) er efter min mening helt hen i vejret, og indikerer at man ikke har indblik i hvordan tingene teknisk fungerer under overfladen.

Det er iøvrigt en metodik, som rigtig mange udviklere afskyr, da den ikke er nem at vedligeholde.

Den kø baserede metodik (FIFO) til inter process kommunikation er tilgengæld en ganske smart metode, men er slet ikke i modsætning til objekt orientering.

Det er jo heller ikke nogen ny ide... men faktisk bare en variation over det mekaniske samlebåndsarbejde, vel egentligt i praksis realiseret af Ford i 1920'erne.

Kø strukturer som interprocess kommunikations medie er dog først rigtigt smart, når man har en eller anden form for 'vejviser' indbygget, som sikrer at de relevante "ud" data havner i de relevante "ind" køer. Og der er flere forskellige måder at gøre det på.

Een måde er statisk eller semistatisk routning. Det er ofte den måde Java udviklere bruger JMS (Java Messaging System) på. Pakker routes til de køer som de skal ind på, ud fra hvilken kø de kom fra.
Alternativt routes pakker baseret på deres indhold (typisk XML), men reglerne er stadig typisk statisk sat op når systemet startes.

En anden måde, som TIBCO (og jeg) har en forkærlighed for er dynamisk routing baseret på publish/subscribe metodik. Der er det modtageren der som udgangspunkt afgør hvad den er interesseret i at modtage, og det fortæller den systemet. Så vil alle meddelser som passerer igennem systemet, og som matcher modtagerens kriterier, automatisk ende op hos modtageren. Ofte benævnes denne slags systemer som ESB (Enterprise Service Bus) orienterede.

Det giver et meget dynamisk system, hvor ny funktionalitet kan puttes ind i systemet, uden at systemet skal 'rebootes' eller rettes i.

Det giver selvfølgelig også nogle udfordringer mht. sikkerhed, men der findes også løsninger for det.
Een af de vigtigste parametre for sikkerhed er at tænke igennem, i hvilke kategorier modtagere kan befinde sig i (sikkerhedsmæssigt). Så kan ca. 95% af pakke filtreringen nemlig foretages automatisk ved at have en (eller flere) ESB'er for hver sikkerheds kategori, og binde dem sammen med gateways som sikrer at kun meddelser der må passere fra een sikkerheds kategori til en anden, får lov til det. Der spiller altså topologi ind, og man kan fin tune den endnu mere, og også lægge public key kryptering på de enkelte pakker i de tilfælde hvor der skal være fuldstændig sikkerhed for at kun noder der var tænkt at skulle kunne læse en pakke kan få lov til at gøre det.

Det var en længere forklaring... men håber i bærer over med mig :)

mvh

Kim Madsen
kbm@kbmitexperts.dk

  • 0
  • 0
Kim Madsen

"...automatisk ende op hos modtageren. Ofte benævnes denne slags systemer som ESB (Enterprise Service Bus) orienterede."

skulle have været:

"...automatisk ende op hos modtageren.

Ofte benævnes denne slags systemer som ESB (Enterprise Service Bus) orienterede."

Altså ESB refererer ikke kun til publish/subscribe baserede kø mekanismer.

mvh

Kim Madsen
kbm@kbmitexperts.dk

  • 0
  • 0
Thomas Hildebrandt

Hej Kim,

et godt indspark. Jeg er helt enig i at der ikke er modsætninger mellem objekter og processer, eller objekter og besked-baserede systemer og FIFO-køer.

Imidlertid ser jeg et stigende behov for at processer bliver eksplicitte i vores programmerings sprog og ikke sekventielle Java-tråde eller "
fabrikker der spytter 'processer' ud (altså objekter der hver især har en eller flere tråde tilknyttet, som bearbejder en eller mange flere objekter, altsammen i parallel)." som du skriver.

Det jeg mener vi har behov for er at have processen som en eksplicit sproglig byggeklods i vores typede sprog - med typer der kan sige mere end hvilke beskeder der kan sendes/modtages, men også i hvilken rækkefølge, og på hvilke sikkerhedsniveauer (som du selv er indepå). Der har i den seneste årrække været interessant forskning i session-types, behavioral types som fanger dette - og som på også har fået direkte indflydelse på standarden og arbejdet med WS-CDL.

I den forstand ville procesorientering være en naturlig videreførsel af objektorientering, ikke en modsætning (ligesom oo også viderefører procedurer og brug af relationelle databaser).

Jeg ser ikke proces-orientering som den gamle sammenkobling mellem Excel og Word eller Windows automatisering. Men jeg (og mange af de virksomheder jeg har kontakt til) kan godt få øje på nytten af at betragte proces-orientering så bredt, at det også indfanger sammenkædning af eksisterende applikationer som Excel og Word.

mvh & godt nytår
Thomas

  • 0
  • 0
Kim Madsen

Hej Thomas,

Jeg er enig i at de traditionelle programmeringssprog snildt kan udvikles endnu mere end de allerede er, til at indeholde support for trådning (og altså kørsels processer).

Det er der allerede forsket en del i, og der er også opfundet nye sprog som bruger processen som udgangspunkt.

Det der kunne ske var, at man knnne definere et state diagram for de enkelte objekter, og lade den enkelte state afhænge af andre objekters state, hvorved du har defineret en process.

Det er dog allerede gjort i forskellige add on produkter til de traditionelle udviklingsværktøjer. Se f.eks. tildels Windows Indigo projekt (nu WCF), som piggybacker på object orienteret C# og dens attributter. Tilsvarende er der ting i gære hos arkitekterne for programmerings sproget Delphi.

Der er dog flere forskellige krav til process/tråd styring som skal håndteres forskelligt afhængig af det resulterende produkt. F.eks. vil backend orienteret kode typisk ende op med at skulle hostes i en eller anden form for applikations server. Dvs. at man er underlagt de overordnede regler der er for den valgte applikations server og dens opsætning. Dette har den fordel, at det potentielt kan gøre cloud computing nemmere, altså at de enkelte objekter, som er defineret til at kunne leve i et process flow, forholdsvist nemt kunne kopieres ud i en cloud og eksekveres der.

Modsætningen er den enduser orienterede process orientering... spil... analyse værktøjer... GUI m.m. Der vil der typisk være helt andre krav til hvordan processen skal opføre sig, og det kan typisk ikke lægges ud i en ekstern applikation server.

Altså er udfordringen at finde balancepunktet mellem at lave en syntaks/et system, der er god både mod server orienterede systemer og mod monolitiske GUI applikationer.

mvh

Kim Madsen
kbm@kbmitexperts.dk

  • 0
  • 0
Log ind eller Opret konto for at kommentere