gamla tentor Flashcards
Hanseth och Lyytinen (2010) använder sig av Complex Adaptive Systems theory (CAS) som teoretisk grund (kernel theory) för sin designteori för digitala infrastrukturer
Hur motiverar Hanseth och Lyytinen (2010) valet av CAS som teoretisk grund? 2 p.
Ordning skapas via attractor är en del av CAS-teorin
Anpassar sig hela tiden till miljön
Tänkt dig att infrastrukturen är som en biologisk varelse.
Hanseth och Lyytinen (2010) motiverar valet av Complex Adaptive Systems (CAS) som teoretisk grund med att dessa system hanterar de dynamiska och komplexa egenskaperna hos digitala infrastrukturer väl.
Enligt dom kan man inte utgå från den traditionella synen på IS - där man anser att **designern har kontroll **över situationen, att kravspecifikationen man har från början anses vara “färdig”, dvs. att man har tillgång till alla användare och att systemet ska utvecklas utifrån en specifik situation eller ett specifikt behov för en organisation.
Inom CAS ser man ett system som självorganiserande och dynamiskt och komplext, där man som designer inte har full kontroll över hela processen, alltså motsatsen till det traditionella.
Attractors är ett viktigt begrepp i kontexten av CAS. Förklara utförligt vad som avses med begreppet och ge exempel på vad en attractor kan vara? 4 p.
En attractor är något, exempelvis
- en it-capability
- en egenskap av en institutionell entitet (ett e-recept med hög kvalitet)
- en standard, som fungerar som en generative mechanism inom en informationsinfrastruktur med syftet att skapa tillväxt (ex. windows).
Attractor handlar om att hitta ordning i kaoset
- Attractors fungerar då som en punkt av stabilitet i det här kaoset.
I Hanseth och Lyytinen kopplar de attractors till bootstrap phase, eller bootstrap problem, där det är viktigt att tidigt skapa tillväxt av användare inom informationsinfrastrukturen.
Genom en attractor vill man uppnå “network effect”. Ett exempel är e-post, en it-capability. Ju fler som använder e-post = snabbare tillväxt av användare eftersom när fler kommunicerar via e-post kommer fler också vilja göra det, och då ökar värdet av it-capabilityn eller systemet/infrastrukturen som helhet.
Det blir som en snöbollseffekt man vill uppnå genom att satsa på en attractor, vilket Hanseth och Lyytinen anser vara eftersträvansvärt i bootstrap phase eftersom det är då man är i behov av en snabb tillväxt av användare.
Ytterligare exempel på en attractor kan vara en teknologisk standard som:
- GSM inom mobiltelefoni, som blev den dominerande standarden globalt
- en öppen källkodsplattform som Wikipedia, som har blivit en central källa för information på internet.
I Hanseth och Lyytinens (2010) designteori ingår designregel 4 “Make the organization of IT capabilities simple”.
Förklara utförligt vad denna designregel avser
“Make the organization of IT capabilities simple” avser the adaptability problem, där man vill skapa tillväxt i infrastrukturen.
Designregeln innebär att man ska designa informationsinfrastrukturen med tillhörande IT capabilities på ett enkelt sätt med tydliga ansvarsområden och inte för avancerad funktionalitet. Man vill inte ha en design av infrastrukturen som leder till så kallade “lock-ins”, dvs. problem orsakade av tidigare beslut eller designval som är svåra att lösa baserat på hur den installerade basen är utformad. Infrastrukturen måste vara skalbar och anpassningsbar för att kunna möta behoven efter bootstrap-fasen.
Förklara vilka likheter och/eller skillnader det finns mellan det som Hanseth och Lyttinen (2010) beskriver som the adaptation phase och det som Eriksson och Öhlund (2023) beskriver som
institutionalization phase?
En skillnad som finns mellan artiklarna är att Eriksson och Öhlund starkt påpekar vikten av att legitimera den institutionella enititeten och det institutionella systemet, något som är förknippat med kvaliteten av e-recept som attractor som i sin tur genererade institutionaliseringen (tillsammans med exchange contract).
Detta är också kopplat till lagar, förordningar och regler som anpassats för att legitimera/institutionalisera systemet. Erksson och Öhlund lyfter alltså många sociala delar som hör till beteenden, normer, lagar, regler och förordningar.
Medan i Hanseth och Lyytinen lyfts inte dessa aspekter av adaption phase som en del för att skapa tillväxt, det saknas. Eriksson och Öhlund menar att designprocessen inte alls behöver vara bottom-up som Hanseth och Lyytinen beskriver. I Eriksson och Öhlund samverkar alla delar, från makronivå till mikronivå, och båda är lika viktiga för institutionalization phase.
Det som Eriksson och Öhlund anser vara på makro-nivån är
designen av exchange contract samt normer, lagar och så vidare (institutionell logik), och det är precis dessa delar som saknas i Hanseth och Lyytinen. Hanseth och Lyytinen fokuserar
mer på infrastrukturen i sig och inte det övriga som krävs för institutionalisering.
Förklara huruvida designregeln “Make the organization of IT capabilities simple” är tillämplig i samband med e-receptsprojektet (Eriksson och Öhlund 2023).
Beskriv på vilket/vilka sätt designregeln är tillämpbar alternativ på vilket/vilka sätt den inte är tillämpbar
Make the organization of IT capabilites simple kan relateras till att exempelvis den tidigare gatewayen togs bort, eftersom den innehöll allt för mycket komplexitet. Man strukturerade
också upp de olika modulerna med hjälp av exchange contract som förbättrade interoperabiliteten genom hela infrastrukturen. Innan projektets start fanns det flera olika moduler från prescriberns sida, och efter projektet fanns det bara en modul från prescriberns sida. Detta är en förenkling som kunde göras med hjälp av exchange contract, där alla använder samma rutiner, samma dataformat, samma datastruktur osv. Det kan också kopplas till att det inte krävdes avancerad funktionalitet för att öka kvaliteten på e-recepten och för att få tillväxt inom infrastrukturen.
—–
Hanseth och Lyytinen (2010) menar på att en designer som skall utveckla en ny IT capability står inför ett s.k. ”chicken-egg problem” under bootstrap-fasen.
Förklara utförligt vad de avser med detta ”chicken-egg problem” under boot-strap fasen och vad man som designer behöver göra för att lösa detta problem.
Det grundläggande som Hanseth och Lyytinen lyfter som designregler under bootstrap-fasen är att designa initalt för användarna:
- lägg till en installerad bas –> bygg på den installerade basen.
Sammanfattningsvis gäller det att i bootstrap-fasen samla ihop en liten grupp användare och designa utifrån denna. Ett problem här är att eftersom man utgår från en liten användarbas är det svårt att förutse framtida behov och krav. En risk är då att man blir path dependent, det vill säga att besluten man tar i början leder in på en specifik väg.
En risk med detta är exempelvis så kallade IT-traps, där de designval man gjort i början i bootstrap-fasen kan ställa till det senare i adaptability-fasen, att man blir begränsad och inte kan tillämpa vissa lösningar som i sin tur hade skapat tillväxt för infrastrukturen.
Detta resulterar i en “tension” mellan problemen, att försöker man lösa det första så kan man hämma möjligheterna att kunna lösa det andra - och vice versa. Detta är viktigt att undvika eftersom problemen/faserna är beroende av varandra. Ett exempel kopplat till e-recept är att man mellan 2003-2004 lyckades generera tillväxt i användarantalet (bootstrap). Om infrastrukturen inte skulle hänga med i utvecklingen (adaptability) skulle detta orsaka problem på apoteken med långa köer, eftersom systemet inte hunnit skalats upp och förändrats utefter nya behov och krav. På samma sätt blir detta ett problem i Hanseth och Lyytinen, att båda faserna måste prioriteras utan att försämra möjligheterna till att lösa det ena eller andra.
Eriksson och Öhlund (2023) definierar i sin artikel begreppet institutionell entitet. Förklara utförligt vad som avses med begreppet och exemplifiera ditt svar.
En institutionell entitet är samma sak som ett institutionellt objekt, och det är inte samma sak som ett fysiskt ting eftersom ett fysiskt ting kan relatera och vara kopplat till flera institutionella entiteter.
En institutionell entitet är:
- En bärare av rättigheter och skyldigheter
- Något som vi socialt har skapat och något som vi måste tro på för att det ska vara av värde.
- Slutar vi tro på dom = inget värde i dom
Exempel på institutionella entiteter:
- Ett E-recept
- Inom fotboll är fotbollsmatchen den institutionella entiteten
- Ett registreringnummer
- Ett personnummer
Entiteten ska generera någon form av värde för samhället, inte bara lokalt.
I Eriksson och Öhlund (2023) beskrivs skillnaden mellan en databas och ett register.
Förklara vad som är skillnaden mellan dessa två begrepp?
Ett register kontrolleras av registerlagen och som designer är man inte garanterad “directaccess” till register, å andra sidan i en databas kan man ex. skriva queries och hämta önskad
information när man vill och hur man vill.
Ett register är mer kontrollerat och styrs av lagar och
regler och dess struktur och åtkomstregler är utformade för att skydda informationen och säkerställa att den används på ett ansvarsfullt och lagligt sätt.
Förklara varför digitala institutionella entiteter är sådana generativa mekanismer (generative mechanisms) i kontexten av digitaliseringen utav institutionella system?
Exemplifiera detta med utgångspunkt från e-receptsprojektet.
I fallet med e-recept var själva e-receptet (digitalt institutionell entitet) det som fick systemet att gå från ett institutionellt system till ett digitalt institutionellt system.
En viktig faktor för digitaliseringen var e-receptets kvalitet och legitimitet. Det började med en insikt i att kvaliteten på e-receptet behövde öka, vilket skulle fungera som en attractor. Till detta upprättades ett nytt exchange contract, med bland annat regulativa- och konstitutiva regler och validering, samt att en tidigare gateway som dolde errors togs bort.
Det som uträttades på makro-nivån (institutionell logik), ställde krav på, legitimerade och styrde det som fanns på mikro-nivån (antagandet av institutionell logik) - såsom sociala interaktioner och själva informationsinfrastrukturen.
När användare antog den institutionella logiken - dvs. trodde på det institutionella systemet, respekterade och följde exchange contract, förstod ansvarsområden och liknande, så fungerade detta som en generative mechanism för digitaliseringen av det
institutionella systemet, likt det Hanseth och Lyytinen lyfter kring network effects.
Det som hände på mikronivån ställde krav på och påverkade makronivån - den institutionella kontexten och designen av exchange contract, och vice versa. Denna mekanism resulterade i att kvaliteten och legitimiteten på e-receptet ökade, vilket i sin tur bidrog till digitalisering av det institutionella systemet. Detta har i sin tur resulterat i nya lagar gällande e-recept som legitimerar det som institutionell entitet ytterliggare, exempelvis att det får lagras genom hela livscykeln.
Förklara vad ett API är för något och i vilket/vilka syften ett sådant kan nyttjas
API står för Application Programming Interface och är som en slags teknisk modul som levererar en viss funktionalitet med gränssnitt. Ett API kan nyttjas i system där man vill ha
“lösa kopplingar” och modularitet för att enkelt kunna förändra i systemet som helhet utan att det påverkar alla delar.
Ett exempel på användning av ett API är i laboration 2 i kursen, i en Model-View-Controller-applikation. Syftet med den applikationen är liksom beskrivet tidigare att modulerna ska vara löst kopplade och ha egna ansvarsområden
Förklara vad ett utbyteskontrakt (exchange contract) är för något och diskutera vad, om någon, skillnaden mellan ett utbyteskontrakt och ett API är.
Ett exchange contract är en viktig del i en informationsinfrastruktur som bidrar till exempelvis institutionalisering och interoperabilitet.
Ett exchange contract innehåller regler och specifikationer kring det som ska utbytas. I fallet med e-recept innehöll exchange contract ex:
- Konstitutiva regler - såsom classification rules,
- Regler för data och struktur
- Regler för errors
- Regler för validering och liknande.
- XML-schema
- Processbeskrivning
- Konceptuell modell
Man kan säga att ett exchange contract sätter ramarna, dvs. är en “mall” för informationsinfrastrukturens olika flöden - både gällande det tekniska men också gällande den sociala interaktionen och ansvarsområden.
Enl. Hanseth och Lyytinen är det viktigt att ha en bra balans mellan stabilitet och flexibilitet i ett exchange contract. Men själva skillnaden mellan ett exchange contract och ett API är att ett exchange contract också innehåller ett DPI (Digital Practice Interface (beskrivet i Eriksson och Öhlund)), som
fastställer den sociala interaktionen och ansvarsområden - medan ett API mer står för det tekniska gränssnittet och det tekniska informationsutbytet i informationsinfrastrukturen.
Resurs (Resource) är ett grundläggande begrepp inom RESTful. Förklara och exemplifiera vad som avses med begreppet resurs i samband med detta.
En resurs kan vara exempelvis en bild, en artikel eller en sida man kan referera till, peka på eller hämta med en identifierare. En resurs identifieras med en unik URI, Uniform Resource
Identifier, som är kopplad till den specifika resursen.
Mer specifikt:
En resurs representerar någon form av information eller data som kan manipuleras eller hämtas genom webbtjänster. Resurser är kärnkomponenter i RESTful-tjänster och är tillgängliga via unika identifierare, oftast i form av Uniform Resource Identifiers (URI).
Vad är en Resurs?
- En resurs är i grunden en representation av en enhet eller ett informationsobjekt i systemet. Det kan vara så konkret som en fysisk entitet (t.ex. en bok i ett bibliotek) eller mer abstrakt (t.ex. en tjänst eller en samling av andra resurser). Resurser i en RESTful arkitektur är konceptuellt separerade från de representationer som skickas till klienten. Detta innebär att samma resurs kan presenteras i olika format (som JSON, XML, HTML) beroende på klientens behov och önskemål.
Identifiering av Resurser med URI
- Varje resurs i ett RESTful system identifieras unikt via en URI. Denna URI fungerar som en adress till resursen och gör det möjligt för klienter att hitta och interagera med resursen. Till exempel kan URI:n http://example.com/articles/123 peka på en specifik artikel i en artikel-databas. Genom att använda denna URI kan klienter hämta artikelns data, uppdatera informationen eller utföra andra åtgärder som systemet tillåter.
Exempel på Resurser
- Bild: En bild lagrad på en webbserver kan vara en resurs. URI:n http://example.com/images/logo.png kan användas för att direkt hämta och visa bilden i webbläsare eller applikationer.
- Artikel: En artikel i en blogg eller nyhetssida är en resurs. Genom URI:n http://example.com/blog/posts/first-post, kan en användare hämta hela innehållet i den första bloggposten.
- Användarprofil: I ett socialt nätverk representerar varje användarprofil en resurs. URI:n http://example.com/users/svensvensson kan leda till en sida med information om användaren “svensvensson”.
Interaktion med Resurser
- Interaktion med resurser sker genom HTTP-metoder som GET (för att hämta en resurs), POST (för att skapa en ny resurs), PUT (för att uppdatera en befintlig resurs), DELETE (för att ta bort en resurs), bland andra. Detta gör det möjligt för klienter att utföra standardiserade åtgärder på resurser på ett enhetligt sätt.
Sammanfattningsvis är resurser i en RESTful arkitektur de grundläggande byggstenarna som representerar information och tjänster. Genom unika URI:er blir dessa resurser åtkomliga och manipulerbara, vilket möjliggör kraftfulla och flexibla webbtjänster.
Eriksson och Goldkuhl (2013) beskriver i sin artikel olika pre-conditions i kontexten av utveckling utav digitala infrastrukturer.
Förklara varför det är viktigt att vara medveten om dessa pre-conditions. Exemplifiera ditt svar
Det är viktigt att vara medveten om pre-conditions för att kunna ta informerade beslut samt undersöka om ett eventuellt projekt överhuvudtaget är genomförbart som tänkt/planerat eller
på andra sätt. Oavsett får man en bättre bild av den institutionella designkontext man har att göra med.
Ett exempel är legala preconditions, som innebär de lagar, regler och förordningar som relaterar till utvecklingen och den digitala infrastrukturen.
En planerad designplan kan inkludera olika register, information från andra organisationer/myndigheter, sekretessbelagd
information eller liknande. I sådana fall måste man diskutera detta med inblandade aktörer och framförallt jurister, gärna innan projektet har kommit för långt in i processen eftersom sådant kan sätta käppar i hjulen för genomförbarheten. I vissa fall kanske det också krävs eller är nödvändigt att ändra en lag eller förordning för att infrastrukturen ska kunna designas på ett hållbart sätt, eller för att institutionaliseringen ska bli legitim.
Ex. gällande fallet där svenska myndigheter
Förutom att designers bör vara medvetna om dessa preconditions så bör även övriga aktörer ha kännedom om dessa för ett lyckat samarbete. Det handlar om att “från andra sidan”, ex. som jurist, förstå designernas utgångspunkt, mål och syfte.
Eriksson och Goldkuhl (2013) beskriver i sin artikel olika pre-conditions i kontexten av utveckling utav digitala infrastrukturer.
Förklara vad som, i artikeln, avses med ”the organizational precondition”. Exemplifiera ditt svar
Organizational precondition innebär att förstå och kartlägga den organisatoriska kontexten. Ett exempel är fallet med ekonomiskt bistånd som beskrivs i artikeln (Eriksson och Goldkuhl), där ett flertal myndigheter och kommuner är inblandade.
En enskild organisation kan vara väldigt bra på att utveckla interna system, men inte lika bra på att utveckla infrastrukturer som sträcker sig över den egna organisationens gränser. Det är
otroligt svårt att organisera sig i ett offentligt projekt (public sector). I Sverige har det ex. länge inte funnits någon centraliserad myndighet att vända sig till för hjälp, råd eller direktiv eller som samordnar alla inblandade parter(myndigheter och kommuner). Detta innebär givetvis problem om exempelvis vissa myndigheter för projektet inte ser en egen vinning i projektet eller inte vill engagera sig och vara med.
Organisatoriska förutsättningen är därmed viktig för ett projekts genomförbarhet och för interoperabiliteten i infrastrukturen
