Der findes mange interessante nye funktioner i MooD 2015 (MooD Business Architect 2015) og for at få en større indsigt i, hvordan de nye funktioner kan bruges i min dagligdag, som enterprisearkitekt gik jeg i dybden med den grafiske brugergrænseflade, men jeg fandt hurtigt ud af at det ville give en større indsigt i programmets funktionalitet, hvis jeg i stedet anvendt en casebaseret tilgangsvinkel. Når jeg arbejder med cases så er det oftest nemmere at fordybe sig i funktionaliteten, hvis jeg ligger begrænsningerne fra den virkelige verden bag sig, således det ikke bare bliver mere arbejde oven på modeller der har et ”legacy” af en art.

Case

Der findes en række forskellige perspektiver der bør tages i betragtning og derfor gik jeg i gang med en brainstorm. Jeg fandt frem til at det ville være til at foretrække at beskrive og udvikle modeller til og om en middelstor eller stor organisation, hvor der har været en række forskellige begivenheder der har medført at den råder over applikationer som ikke nødvendigvis giver mening for organisationen at arbejde videre med, hvilket vil sige applikationer, platforme, informationssystemer der af den ene eller den anden grund vil skabe større omkostninger at udvikle og vedligeholde eller risici stiger for meget ved at beholde dem.

Ud fra denne betragtning kom jeg frem til følgende fiktive organisation. Navnet er generisk, men det er i og for sig også formålet for en fiktiv caseorganisation. Maskinfabrikken Møtrikken ApS har siden virksomheden blev stiftet i 1959 opbygget en kundegruppe der kan findes over det meste af Fyn, Jylland og Slesvig-Holsten. Virksomhedens hovedkvarter og produktion findes i Odense, hvor virksomheden har haft adgang til arealer, hvor den har kunnet opbygge fabrikshaller og lagerhaller. Maskinfabrikken Møtrikken ApS har siden 1959 vokset sig større og større og det viste sig allerede tilbage i 1979 at der var behov for teknologi der kunne give mellemlederne i henholdsvis produktionen og lagerforvaltningen et overblik over ordrer, produktion og forsendelser, og det afledte at Maskinfabrikken Møtrikken ApS indkøbte et lille men funktionelt mainframe der kunne processorer informationen på daglig basis.

Sidenhen, specielt i 1990erne, indkøbte Maskinfabrikken forskellige teknologier, informationssystemer og platforme der kunne processorer informationerne. Desværre har det siden vist sig at meget af den viden om teknologiernes sammenhæng var personspecifik og en del af de individer der har arbejdet med dem har sidenhen forladt organisationen. Ligeledes har det vist sig at der har været en relativ afslappet forhold til ansvar for driften af applikationerne og de tekniske løsninger der eksisterer i forhold til de informationer der skal behandles i Maskinfabrikken Tandhjulet ApS.

Opgaven vil derfor være at oprettet et applikationslandskab for Maskinfabrikken Møtrikken ApS, hvor modellerne viser hvem der ansvarlige for applikationer og hvilke leverandører der er for hver af dem.

Begyndelsen

Når et helt tomt bibliotek oprettes i MooD Business Architect 2015, så findes temaerne, processer, users og groups. Users & groups kan bruges i sammenhænge, hvor rettigheder skal tildeles, hvilket vise sig at være ganske interessant, hvis MooD Active Enterprise skal udstille de specifikke data der er følsomme, men bør være tilgængelige for bestemte profiler  i Maskinfabrikken Møtrikken ApS.

 

For at skabe et overblik over applikationer og leverandører samt ansvarlige for applikationer så kræver det at tre temaer skal udarbejdes.

Applikationslandskab

For at løse opgaven gik jeg derfor i gang med at oprette temaerne der ligger under ”File”.

Adgang til metamodellen igennem file.

Metamodel.

På billedet ovenfor kom jeg så til at begå en fejl ved at kopiere et eksisterende tema. Det giver ikke nogen værdi siden felter bliver duplikeret og øger kompleksiteten i forhold til vedligeholdelse.

For hver af de nye temaer tildeler jeg så et nyt ikon, hvilket fremgå af stifinderen (explorer) ude i MooD Business Architect. For hvert tema skal der oprettes et sæt typer (types) og disse kan ligeledes få tildelt ikoner, hvilket fremgår på billedet. For hver type skal felter og relationer defineres. I større projekter bliver det en nødvendighed at udarbejde metamodeller for at der findes et nogenlunde konsistent overblik over relationer og felter.  I forhold til temaet personer der skal bruges til at varetage data om it-medarbejderne der er allokeret som applikationsansvarlige. Først og fremmest et unikt id således data fra fx en Excel eller Access import kan gennemføres, og feltet er et helt tal. Dernæst navn (name) der er baseret i på et memo-felt og beskrivelse (Description) af applikationen. Sidenhen har jeg så tilføjet formål (purpose) der også er baseret på et memo-felt. Sidst men ikke mindst har jeg så tilføjet en relation mellem temaet ”Applications” og temaet persons, hvilket gør at person-objekterne nu kan tilknyttes de enkelte applikationer.

Inden selve konstruktionen af ledelsesmodellen for applikationer findes der et behov for udarbejdelse af såkaldt dummy data, og jeg har derfor oprettet applikationer. Applikationerne er ligesom med caseorganisationen fiktive fx Microcore Software Gates og UniCorn Source Code Manager.

Oprettelse af applikationer.

Åbning af applikationen for at udfylde data om applikationen.

Tilføjelse af ansvarlige.

Dernæst fik jeg oprettet et tema for personer. Jeg har af taktiske årsager valgt at holde metamodellen på engelsk fordi det i givet fald vil være nemmere at få hjælp fra MooD International (tidligere kendt som Salamander), hvis der skulle vise sig at opstå situationer, hvor support bliver nødvendigt.

Sidst men ikke mindst fik jeg oprettet et tema for leverandører (Suppliers).

Model Masters

Hvert objekt der findes i MooD kan der tilknyttes en model master. En model master bruges til at udstille data fra objekterne og disse modeller kan tilpasses således de bidrager med de rette billleder og de rette billeder (logo osv.) og ikke mindst den rette afstand mellem objekterne. Objekterne gør det muligt at opstille de indsamlede data på en let forståelig måde. Endnu bedre så kan de enkelte model masters referer ”linke” til hinanden, hvilket gør det muligt at få fremhævet forskellige informationer fra samme objekter.

Model master.

 Model master med data fra forespørgsler.

I den forbindelse har jeg udarbejdet forskellige model masters for at kunne give beslutningstagerne en mulighed for at skabe sig et overblik over applikationernes tilstand. Da jeg fik tilføjet felterne så har der været et behov for at få et overblik over applikationerne og deres estimeret andel dokumenteret i procent.

Forespørgsler

MooD Business Architect har en funktion til konstruktion af forespørgsler (queries) og disse skal bruges i forhold til at kunne trække data ud fra objekterne og udstille dem på fx et dashboard eller ledelsesmodel.

Forespørgsel der kan tilknyttes infopanel eller liste of objects med færdig forespørgsel.

Start med “parameter” der gør det muligt at få data om objekterne.

Relationer mellem objekter og parametre.

Udvælgelse af applikationer på eller under et bestemt niveau for dokumentation.

Forespørgslerne kan forbindes til ”info panels” og ”list of elements”. Der kan bruges til at vise resultaterne fra de forskellige forespørgsler og i udgangspunktet er listerne brugbare i forhold til at objekterne der opstilles er klikbare, hvilket betyder at det er muligt for brugerne kan tilgå information om objektet der udstilles og dermed kan mere information udstilles. Det kræver dog at de objekter der udstilles har lagt en model master over sig for at brugeren rent faktisk kan se indholdet ellers vil brugeren få en besked der lyder at der ikke findes en model tilknyttet det specifikke objekt.

Det videre forløb

Et fokus for udviklingen af modellen kunne være en oversigt over it-projekter der understøtter de målsætninger som beslutningstagerne i organisationen har fastlagt. Dertil kunne det tolkes som værende en problemstilling at der mangler overordnet dokumentation for applikationerne i forhold til udvikling og vedligeholdelse samt mangel på standarder for hvad udviklingerne og leverandørerne skal forholde sig til være temaer der kan udvikles og knyttes til fremtidig udvikling på applikationslandskabet.