|
Microsoft genomför varje år några stora kund/utvecklar-konferenser som kallas TechEd, världen över. I år hölls vår geografiskt närmaste konferens i Amsterdam, i början av juli. Föreläsningarna kan vara lite ojämna men ett antal håller mycket bra kvalitet och är också förvånansvärt frispråkiga. Pajkastning mot konkurrenter är befriande ovanligt - men det kanske inte behövs när man redan har världsherravälde ;-) Ett antal tusen personer deltog men man skröt inte om deltagarantalet som man brukar göra, så vi kan gissa att det var något färre än tidigare år. Arrangemanget är rättså välplanerat och genom att föreläsningarna är indelade i "teknikalitets-svårighetsgrad" så är det lätt att hitta det man är intresserad av. Radio-LAN fanns tillgängligt och dessutom ett antal persondatorer. Vissa persondatorer hade telefonlur och IP-telefoni - fungerade huvudsakligen bra och var gratis. |
|
Till ämnet. Översiktsmässigt kan man notera förseningar av många saker. Longhorn, Indigo mm är försenade. (Efter seminariet annonserades även att det nya filsystemet WinFS blir försenat.) Därmed blir man t ex tvungen att skeppa ut en del önskade funktionella förbättringar i Service Pack 2 till XP - och därmed bryter man löftet om att endast kvalitetsförbättringar skulle komma ut som SP:er.
I och med förseningarna kan man känna både en stor otålighet och stora förväntningar inom Microsoft-lägret. "Vänta bara till Indigo kommer!" Vissa smådelar släpps i förväg, eller också tillhandahåller man exempelkod för att ta sig runt problem. För kunden innebär det tyvärr att man i vissa fall bör ligga lågt med förändringar, eftersom man riskerar få göra om arbetet när den mer fullständiga lösningen kommer. Detta kan förstås vara helt rätt val ändå, ifall man har en affärsstrategi baserad på kort ledtid.
En av nyckelteknologierna som det pratas mycket om i branschen nu är Web Services. Microsoft har tillsammans med IBM känts extra pådrivande för att etablera dessa. Standardarbetet t ex med "WS-"-standarderna rullar vidare, men det kan vara skakigt hur väl nya standarder finns införda i stabila produkter. Microsofts Indigo skulle lösa en del problem med dagens Web Services-stöd men som nämnts ovan är Indigo försenad. Det finns ett paket från Microsoft som heter WSE som innehåller vissa tidiga delar i Indigo. Om man behöver denna funktionalitet med detsamma bör man kunna använda WSE, men man får räkna med omkodning när Indigo sedan släpps.
Dessa negativa synpunkter hoppas jag dock inte hindrar branschen från att redan nu använda Web Services till det dessa redan är jättebra på. Då tänker jag främst på integration mellan applikationer inom samma organisation (ofta inom "samma datahall"). T ex kan säkerheten lösas på samma sätt som man i många år ofta har gjort vid anrop mellan system, genom VPN-tunnlar, separata LAN, Virtual-LAN, certifikat, SSL etc. Lösningen får alltså än så länge sökas i datakom-infrastrukturen snarare än i skikt högre upp. Web Services-trafik emellan organisationer som "känner varandra" kan med vissa begränsningar också lösas på liknande sätt.
Ett annat begrepp som det talas om mycket är SOA (Service Oriented Architecture). Ibland kan man kanske tycka att detta är kejsarens nya kläder, den här typen av löst kopplade API:er (Application Programming Interface) har det funnits goda exempel på i många år. Vad som är nytt är att det finns en nyvunnen och ganska väl spridd förståelse för VARFÖR just löst kopplade API:er kan vara bra. Microsoft talar om SOA som om det vore en synonym till Web Services, men det finns naturligtvis andra sätt att anordna SOA. Den synnerligen stora fördelen med Web Services som bas för SOA är dess potential för interoperabilitet mellan lösningar som körs på helt olika teknikplattformar. Microsoft talar sig varmt för öppenhet (i den här aspekten åtminstone) och vikten att kunna koppla ihop sig med andra tekniker!
Det fokus som finns på SOA:s egenskaper (och följderna av dessa i sin tur) inom branschen är mycket glädjande och löftesrikt. Man ska dock samtidigt komma ihåg att SOA-införanden i sig kan bli exempel på det man har kallat "inter-application spaghetti" om man inte ser upp. Jag vill mena att detta ställer extra höga krav på saker som att modellera meddelandeinnehåll, underhålla syntax- och semantik-beskrivningar, logga vilka applikationer som anropar vilka SOA-API:er, driftövervakning (t ex baserat på vad man kunde kalla SOA-ping), versionshantering, samverkan med integrationsmotorer som BizTalk mm mm.
Det finns numera en avdelning hos Microsoft som heter Patterns & practices. Det är en lovvärd satsning. Avdelningen ska publicera mönster, guider och förebildskällkod (i form av s k Application Blocks).
Man erkänner att en del tidigare förebildskällkod såsom Duwamish och Pet Shop kanske inte alltid varit så bra just som förebilder när det gäller säkerhet, undantagshantering och god arkitektur. De menar att källkoden man nu gratis kan få via Application Blocks ska vara av "production quality". Åtskilliga föreläsningar under seminariet hänvisade till: "Det här kan man åstadkomma med Application Block XYZ".
Vad man måste komma ihåg är att detta är osupportad kod som man själv får ta underhållsansvar för. Microsoft utlovar inga nya versioner och ifall en sådan släpps är det inte säkert att den är bakåtkompatibel. Det är alltså framförallt vid skräddarsydda större lösningar koden bör användas, och då behandlas som om den vore skapad inom projektet (ur kvalitets/förvaltningsaspekt). Troligen är Application Blocks av störst värde för pionjärer. En annan notering är att koden åtminstone vid ytlig betraktelse verkar komplex och möjligen överambitiöst strukturerad - pendeln kanske har svängt för långt åt andra hållet jämfört med Microsofts gamla "gladprogrammerings"-kultur.
Det är inte så lätt idag att direkt förstå vad Microsoft (och andra leverantörer) menar när de säger workflow, arbetsflöde. Begreppet dök upp i åtskilliga föreläsningar under TechEd. En av anledningarna till att workflow-styrning behövs är att integrationsmotorer används för att hantera asynkrona meddelandeflöden där affärsundantag och tekniska fel naturligt kan uppkomma och måste avhjälpas. Den här typen av workflow kanske kunde kallas back-office workflow för att nu introducera ännu en anglicism. BizTalk Orchestration är en existerande lösning för detta.
En annan sorts workflow återfinns där människor ska handlägga ärenden i olika steg. Härvid tillkommer behov av användargränssnitt för ärendena och olika sorters formulär. Microsoft har inte haft något bra erbjudande inom detta område tidigare, kunderna har istället använt olika sorters produkter som Lotus Notes, K2, Staffware etc. Fortfarande känns inte Microsofts lösningar helt mogna men tre komponenter bör nämnas: Infopath som ingår i Office 2003 och som i princip är en enkel formulärshanterare (baserad på XML) och BizTalk 2004 Human Workflow Services (HWS), liksom formulär inom SharePoint.
Utan att gå in på det ytterligare kan det ändå vara på sin plats att varna för den begreppsförvirring som finns på svenska mellan ärendehantering, diariehantering och dokumenthantering. Tillkommer nya modebegrepp som BPM (Business Process Management) som är ändå bredare än workflow.
Att administrera användare, lösenord och rättigheter kan vara ett elände i större organisationer. Olika plattformar och verksamhetsapplikationer kan ha helt olika lösningar. Samtidigt brukar det innebära att användaren måste logga in separat i de olika systemen och komma ihåg olika koder. För en stackars privatperson som använder Internet kan det bli oerhört många användarnamn/lösenord totalt sett att minnas.
Några olika lösningar börjar dock skönjas. En metakatalog är en huvudförteckning av användare som tänks automatuppdatera de andra användarkatalogerna. Microsofts variant heter Microsoft Identity Integration Server (MIIS) som alltså bör kunna se till att användar-info hålls ā jour. Även om nu användarnamn/lösenord är lika i flera system så kan man behöva logga in separat i alla systemen i alla fall. Detta tacklas i olika single signon-lösningar (SSO). Här blir man i praktiken ofta besviken på kostnaden och komplexiteten att införa single signon - området känns inte moget. På TechEd presenterades exempel på fungerande men krångliga skräddarsydda lösningar. Det finns också konkurrerande standarder på området och det är oklart vilket som vinner.
Om man har ett antal existerande system så bör man noga överväga ifall man ska börja använda någon storskalig single signon-lösning redan nu. Kostnad kontra nytta kan utfalla negativt. Däremot när man konstruerar nya system, alternativt beskriver krav vid upphandling, bör man få med beredskap för single signon. Om ett och samma företag/organisation publicerar flera Internet-tjänster kan det naturligtvis vara mycket befogat att användarna ska slippa logga in separat i dessa. Vad gäller Sverige bör också nämnas eID från bankerna som gör det möjligt för privatpersonen att ha en enda identifiering mot många Internet-tjänster.
En gemensam typ av problem uppstår när man vill införa integrationslösningar som BizTalk respektive metakataloger som MIIS. Det finns risk för att affärslogik dupliceras, något som man normalt anser som något ont, framförallt ur underhållssynvinkel.
Ett exempel kan vara att ett existerande faktureringssystem i sin logik vet att det i vissa fall ska skicka fakturaposten till en reskontra, i andra fall till en annan. När man räknat hem användning av EAI-integrationslösningar (Enterprise Application Integration, t ex BizTalk) så vill man förenkla genom att minska antalet kontaktpunkter mellan alla applikationerna och istället centralisera dataflödena. I vårt exempel skulle då integrationsmotorn istället fatta beslutet om till vilken reskontra fakturaposten ska skickas. Om fakturasystemet är ett standardsystem eller en äldre egen applikation som man inte vill röra finns logiken kvar där också och dupliceringen är ett faktum.
Ett annat exempel är att det finns användargränssnitt och specifik programlogik för att hantera underhåll av användar- och rollinformation inom en applikation. Om nu underhållet istället ska ske ifrån en metakatalog som "master" så måste denna logik finnas duplicerad där man underhåller metakatalog-informationen. (I något fall kan man kanske undvika problemet genom flerriktad katalogsynkronisering men sådan har allvarliga problem i sig.)
Förutom problemet med underhåll och förståelse i efterhand av duplicerad kod så finns det ett problem som kunde kallas "nersövningsbehov av duplicerad logik". De existerande användargränssnitt där underhåll utförs av antingen parametersättning för faktureringslogik eller rolltilldelning (enligt exemplen ovan) måste användare förbjudas köra. I många fall kommer det inte att gå att "söva ner" dessa menyval utan man måste lita till en manuell föreskrift om att inte använda dem. Här finns naturligtvis en framtida felfaktor.
Trots dessa invändningar anser jag att både integrationsmotorer och metakataloger har ett stort berättigande, men man måste vara realist när man bedömer nytto/risk-potential och kostnad.
Sven-Håkan Olsson, september 2004
Kommentera gärna till mej via e-post e dyl!