Henrik Fladkjær bloghoved

Forslag til bogens struktur

Kære alle,
Jeg har fået mange gode kommentarer og tilbud om at være med i skriveprocessen. Det er jeg utrolig glad for. Som jeg tidligere har skrevet, vil jeg i denne uge – jeg når det lige – komme med mit første bud på, hvordan bogen struktur kan se ud. Jeg er fortsat åben over for forslag til ændringer i strukturen. I forhold til prioriteringen af elementerne i bogen, så vil jeg gå mere i clinch med de, der ønsker en anden prioritering. Både for at se, om det kan integreres i den struktur, jeg når frem til eller det skal berige bogen i form af et horisontalt ekstra kapitel. Jeg vil i næste uge begynde at skabe mere forpligtende skrivekontakter.

Kapitel 1 Bogens målgruppe.
o HA studerende.
o Cand. merc. studerende.

I forhold til målgruppen, som i første omgang vil være HA studerende, så er det vigtigt for mig, at det er den erhvervsøkonomisk viden, der skal understøttes med it.

Kapitel 2 It valg.
o Proprietære systemer.
o Open Source systemer.

Jeg synes ofte, at jeg ser det som nærmest et religiøst spørgsmål. Sådan har jeg det ikke. Jeg bruger gerne Open Source og kvaliteten er ofte høj. Jeg anvender også gerne proprietære systemer. Inden for det erhvervsøkonomiske område er Excel eksempelvis ikke til at komme uden om. Open Source har jeg også oplevet, som et mantra der fik kunder og udviklere i nettet, men pludselig skiftede strategien og væk var det fantastiske community og væk var centrale faciliteter i deres ”Open Source” version.

Kapitel 3 Data.
o Erhvervsøkonomiske data.
o Erhvervsøkonomiske problemstillinger.
o Strategiske mål med data.
o Data karakteristik.

Data og ikke mindst kvaliteten af data er meget centralt for mig fordi jeg synes det giver nogle fantastiske metodiske implikationer, som er spændende at arbejde med. Teoretiske modeller kræver data i den rigtige struktur, kvalitet og mængde, men vi ved, at det ofte er utopiske krav at stille. Dropper vi så beslutningsmodellerne? Foreslår vi nye data? Kommunikerer vi konsekvensen af vores beslutningsmodel når data er inkonsistente?

Kapitel 4 It arkitektur som strategisk fundament.

Her har jeg ladet mig inspirere af bogen: Enterpirse Architecture as Strategy, Jeanne W. Ross mfl, Harvard Business´Press, 2006.
Første kapitel omfatte: “To Execute Your Strategy, First Build Your Foundation”

Kapitel 5 Proces modellering.
o Dokument flow.
o System flow.

Jeg synes, at det er gode værktøjer til at understøtte den mere metodiske analyse af eksempelvis en virksomheds centrale processer.

Kapitel 6 Relationel database.
o Overblik over og udviklingen af den relationelle database.
o Hvem bruger en relationel database?
 Brugertyper.
 Rettigheder.
o Hvad er et RDBMS?
o Den relationelle database model.
o SQL.
o Normalisering

Det forventer jeg bliver et centralt kapitel i bogen. Jeg forventer også, at der her kommer flere horisontale bud på dette kapitel. Jeg forventer at anvende MySQL i min eksemplificering, men jeg forventer også mange andre tilgange hertil.
Det bliver et kapitel, hvor der også bliver udarbejdet små film læseren kan anvende. Lige fra, hvordan læseren kan installere databasen til, hvordan SQL kommando virker.

Kapitel 7 E/R diagrammering
o Relationer
o Roller
o Kardinalitet Endnu et centralt kapitel i bogen. Her får de studerende efter min overbevisning et fantastisk værktøj til at implementere en teori i en relationel database. Igen skal der udvikles undervisningsfilm.

Kapitel 8 Udvikling af software løsninger
o Prototyping
o RAD
o Programmering
o Server løsninger
o Cloud løsninger
o ….
o ….

Det er for mig en naturlig afslutning på den relationelle database og E/R diagrammering. Nu har vi anvendt vores erhvervsøkonomiske teori og dokumenteret teorien i tabeller og relationer. Hvordan kommer vi så skridtet videre og udvikler en konkret løsning. Mit simple bidrag er at anvende Rapid Development Software til at udvikle prototyper eller mere eller mindre færdige applikationer. Jeg har anvendt www.Wavemaker.com. Her er jeg sikker på, at der kan komme mange parallelle kapitler.

Kapitel 9 Rapportering
o Excel
o Rapportgenerator
o …
o …

Hvilke muligheder er der for at rapportere på de data virksomheden opsamler? Her er jeg ikke ude efter en BI løsning, men mere en én til én løsning mellem de data der er registreret og en rapport på disse data.

Kapitel 10 Centrale datakilder
o ERP
o CMS
o …
o …

ERP skal selvfølgelig have den store tur både de gode ting, der er ved at en virksomhed benytter et ERP system, men også de problematiske ting ved ERP systemer. Eller måske mere korrekt implementeringen af ERP systemer. Der er også udfordringer i forhold til ERP systemer både i forhold til gamle systemer uden opgraderingsmuligheder og ERP systemer der er uhensigtsmæssigt implementeret.
Selvfølgelig skal kapitlet indeholde elementer om, hvordan et ERP system understøtter almindelig daglig drift med at oprette kunder sælge en vare sende en faktura osv., men jeg er også meget interesseret i, hvordan det er muligt at anvende et ERP system, så det ikke kun varetager daglig drift, men også bliver et aktiv i at kunne generere kvalificerede data til komplekse erhvervsøkonomiske modeller.

Kapitel 11 Business Intelligence
o Data Warehouse
o ETL
o OLAP
o Datavisualisering

Med hensyn til DWH, så er mit ønske at udvide de studerendes måde at tænke beslutningsorienterede løsninger på. Inden for mange erhvervsøkonomiske områder findes der typisk flere forskellige modeller, der dækker de samme problemstillinger. De trækker også på de samme data, men i beregningslogikken er der alligevel en forskel der gør, at to forskellige modeller kan signalere to vidt forskellige beslutninger. Begge modeller er teoretiske korrekte, men forudsætningerne for modellerne kan være forskellige, så det bliver en ledelsesopgave at gå ind og træffe den, forhåbentlig, rigtige beslutning. Denne kompleksitet vil jeg gerne afspejle i et DWH. I forbindelse med ETL processerne har jeg selv arbejdet med Pentaho’s PDI. Der findes en gratis version på kettle.pentaho.org. Jeg ved, at mange fravælger et grafisk miljø og selv skriver den nødvendige kode til at ud- og indlæse data. Det kunne være interessant med fordele og ulemper i forhold hertil.
Data skal igen kunne præsenteres og her er jeg meget i tvivl om OLAP skal introduceres eller det skal blive på et Excel pivot niveau. Jeg forestiller mig også, at der skal arbejdes med datavisualisering.

Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Torben Mogensen Blogger

Det handler ikke kun om open/closed source. Der er mange andre vigtige aspekter:

  1. Dokumenterede dataformater, så man kan overføre data til andre platforme eller lave dataanalyse udenom systemet.

  2. Licensbetingelser: Engangsbetaling versus abonnement, pris per bruger, server eller andet. Pris for opgradering.

  3. Platforms(u)afhængighed: Er du låst til at køre på et bestemt OS eller på bestemt hardware?

  4. Support: Pris for support: Abonnement eller per case.

  5. In-house/out-of-house hosting? Hvor ligger dine data? Lokalt eller hos leverandøren?

osv.

  • 6
  • 0
#2 Daniel Udsen

Skygge IT er noget der formeteligt skal med her eftersom det er et stort problem og noget der er mindst ligeså ansvarligt for lockin som diverse leverendøres hustleri.

Open vs Lukket software er lidt en "Red Herring" det relevante spøgsmål er hvilke netværks effekter et valg har, ie låser du dig til en leverendør etc. Oftest vil opensource i praksis give dig mere positive netværks effekter end lukket source men det er ikke en regel uden undtagelser.

Excel er et godt eksempelt på et fikst lille værktøj der har skabt store problemer fordi det driver en masse udokumenterede skyggeløsninger der aldrig vil kunne porteres til en testbar platform etc.

Et andet problem er licensrod, hvis du begynder at omkostningstyre ved at spare på de antal licenser du køber så spørger du i praksis om at få et compliance problem, eftersom de folk der ikke får en licens er tvunget ud i udokumenterede workarounds etc.

Skygge it har ofte sin oprindelse i licensstivhed hvor hardware er tilgængeligt mens licenser ikke er(en 1:1 ansat til client er ofte antaget etc.), et problem en der skal tages højde for når du vælger platform, ie en ad libitum licens er klart at foretrække frem for en pr enhed/hoved licens hvilket igen oftest betyder open source.

En advarsel der bør nævnes er at der ikke rigtigt gælder nogen markedsførings lov når det kommer til den alfabet suppe der er B2B it systemers feature liste i.e. du er bedre stillet ved at ignorere salgs materialet og begynde at trawle forumer efter folk der har haft problemer. Og husk alt er mugligt i design fasen mens ting ofte fejler katastrofalt under udrulning. Strategier er irrelevante hvis ikke du har logistikken til at bakke den op mens logistik uden strategi stadigvæk kan levere uden en bagvedliggende strategi.

  • 2
  • 0
#3 Magnus Toftdal Lund

I Danmark er der stor tradition for at bruge standardsystemer til ERP-løsninger, hvor fx Japan bruger meget specifikke systemer, som er skræddersyet til deres forretning. De mest succesfulde systemer, jeg har set, er de firmaspecifikke - det kan bare være rasende dyrt...

Især inden for automobil branchen er det for japanske fabrikanter et direkte konkurrenceparameter, hvilket system de bruger hvor - i modsætning til amerikanske ditto, hvor standardsystemer er fremherskende.

  • 1
  • 0
#4 Martin Jünckow

Jeg ved, at mange fravælger et grafisk miljø og selv skriver den nødvendige kode til at ud- og indlæse data. Det kunne være interessant med fordele og ulemper i forhold hertil.

Vi besluttede i vores team at gå væk fra grafiske værktøjer til ETL (vi benyttede Talend tidligere, som minder om Pentaho) og istedet skrive vores eget kodebaserede ETL-framework.

Nogle af vores konklusioner herfra:

For grafiske værktøjer: - Grafiske værktøjer er hurtige at udvikle i - Grafiske værktøjer giver et godt overblik over processen - Grafiske værktøjer gør det muligt for folk som ikke er hardcore udviklere at forstå og muligvis endda implementere processen

Imod grafiske værktøjer: - Komplekse jobs er svære/tidskrævende at debugge - man er begrænset til de muligheder værktøjerne stiller tilrådighed (og de er ofte temmelig begrænsede i forhold til et mere kode-orienteret miljø). - Grafiske værktøjer har en tendens til at opfordre til "copy/paste" kode, fordi det er let lige at kopiere nogle komponenter og rette et par enkelte ting til hvis man skal lave noget der er næsten identisk med et tidligere flow. - Grafiske værktøjer er lettere end almindelig kode at "breake" under debugging fordi det ofte betyder man må lave ændringer for at enable/disable dele af flowet, forsøge at putte ekstra komponenter ind i flowet til at udskrive værdier med etc. hvorved debugging i sig selv hurtigt introducerer yderligere bugs. - De arbejder ofte med en row-baseret tilgang til data som kræver store mængder memory og som koster performance. Da vi konverterede vores Talend-baserde ETL jobs til rene java-baserede ETL jobs oplevede vi i mange tilfælde at jobsene nu afviklede dobbelt så hurtigt som tidligere og et dramatisk fald i memory-forbrug - selvom der var tale om samme logik. - Grafiske værktøjer håndterer parallel-eksekvering dårligt og man løber let ind i concurrency-problemer hvis man forsøger da der er meget få muligheder for at styre adgang til shared data. - Med grafiske værktøjer er man mere låst til producentens måde at tænke ETL på, det er svært at tilpasse tingene til at matche ens behov på samme måde som man kan med et custom kodebaseret framework.

Kort fortalt er grafiske værktøjer hurtigere at implementere løsninger i og giver et godt overblik, men egner sig bedst til mere simple ETL jobs.

Hvis man har mere komplekse behov (og har dygtige udviklere ansat) så er der mere fleksibilitet i en ren kodebaseret løsning og en kodebaseret løsning kan også struktureres bedre og vil være lettere at debugge.

Håber noget af ovenstående kan give lidt stof til eftertanke i forbindelse med problemstillingen i Kapitel 11.

  • 2
  • 0
#5 Ditlev Petersen

Jeg synes, der mangler noget om it-sikkerhed. Man skal have kendskab til emnet, men behøver ikke vide alt. Der mangler vist også noget om lovgivning og lign. inden for området. Hvad skal logges, hvad skal dokumenteres, krav til revision, hvad må man registrere osv.?

  • 3
  • 0
#6 Jesper Louis Andersen

Please, ikke endnu en bog med MySQL. P( reddes | Mysql) = 1.0, eller rettere sagt: sandsynligheden for at databasen skal reddes givet at den er skrevet i MySQL er 100%. Der er for lidt RDBMS i MySQL og for meget filsystem. Den er superelendig til OLTP og OLAP. De fleste der anvender den ender med at skrive endda meget store dele af deres logik i applikationslaget.

Lige meget niveauet, så lærer du folk dårlige vaner med det databasevalg.

PostgreSQL er på alle måder et bedre valg. Og det er argumentativt under en friere licens også. Desuden slipper du for Oracle's klør.

  • 3
  • 0
#8 Daniel Udsen

Please, ikke endnu en bog med MySQL. P( reddes | Mysql) = 1.0, eller rettere sagt: sandsynligheden for at databasen skal reddes givet at den er skrevet i MySQL er 100%. Der er for lidt RDBMS i MySQL og for meget filsystem

Men er det ikke hele grunden til at bruge MySQL?

Er lidt enig med dig i at MySQL er overbrugt og overhyped, og for rent lokale instalationer er du næsten altid bedre stillet med en embeds database som Sqlite3 eller hsql.

  • 0
  • 0
#10 Axel Kellermann

Når snakken er om databaser, synes jeg at man skal introducere andre databaser en relationsdatabaser, da de også er interessante for mange af de datatyper og systemtyper der er idag. Jeg har noteret mig at mange systemer der f.eks. arbejder med objekter og relationer mellem objekter meget prøver at emulere triple-stores, men slipper ikke særligt heldigt fra det fordi det gerne giver moster SQL'er når der skal søges. Jeg har ikke det store forkromede overblik over disse databaser og deres virkemåde, men jeg kan se at de bliver væsentlige fremover. De går under mange forskellige navne og mærker, hvor nogle af buzz-ordene er: NoSQL, RDF, Triplestores, Neo4J, MongoDB for at blande lidt fra både begreber og projekter. Systemer som Facbook, Twitter og Google havde ikke kommet så langt hvis de var bundet til relationsdatabaser.

Målgruppen er - som jeg ser det - for en stor del kommende beslutningstagere og de skal vide noget om muligheder for de forskellige systemer, databser, teknologier, men hvor meget praktisk de skal have vil jeg sætte stort spørgsmålstegn ved, derfor er tilgængeligheden for eksempeldatabasen vigtigere end mærket. Jeg bruger meget både MySQL og Postgres, men synes at de er meget lidt visuelle og besværlige at installere, hvor Access er så visuel at man ikke har fornemmelse af teknikken - svært valg, men hvis man skal vælge en OpenSource vil jeg også helst pege på PostgreSQL.

  • 1
  • 1
#11 Martin Jünckow

Jeg synes tværtimod det er farligt at gå for meget i dybden i en sådan bog omkring NoSql databaser der generelt kræver stor teknisk forståelse at gøre brug af og som har markant dårligere værktøjer til at tilgå data med sammenlignet med traditionelle relationelle databaser (en af MySQLs styrker iøvrigt, omend jeg er enig i den generelle kritik).

Jeg ville højest nævne deres eksistens og ellers fokusere på RDBMS i en bog tiltænkt studerende (især med et erhvervsøkonomisk fokus).

  • 1
  • 1
#13 Axel Kellermann

De fleste systemer i dag er distribuerede systemer. Derfor er det vigtigt at denne type folk - igen formodede kommende beslutningstagere - ved noget om fordele og ulemper ved distribuerede systemer og hvordan man kan drage nytte af det og hvilke faldgruber der er idet. Det falder på sin vis ind under arkitektur, men det er en forudsætning for god arkitektur.

  • 1
  • 0
#14 Martin Jünckow

Problemet med "de andre" er at de i høj grad kræver professionelle udvikler-kompetencer og en stor viden om databehandling at gøre brug af - og vi taler om studerende som knap forstår hvad en RDBMS er, så det vil være op ad bakke at behandle i et enkelt afsnit i en sådan bog. Derudover er den måde som de her nosql databaser virker på altså mere henvendt til udviklere med særlige behov end til studerende på en erhvervsøkonomisk linje imo.

Derudover er det væsentligt at forstå at "nosql" database-segmentet altså dækker over en meget bred vifte af meget forskellige teknologier til data lagring alle med forskellige fordele og ulemper - det bliver hurtigt omfattende at dække selv overfladisk og udviklingen går stærkt i øjeblikket så dette segment vil formentlig se meget anderledes ud om 5 år og store dele af den viden man kan nedfælde idag være forældet. Fokus bør være på RDBMS hvor grundprincipperne næppe ændrer sig i nærmeste fremtid og som stadig forbliver relevant for hovedparten af de løsninger der udvikles (især indenfor det erhvervsøkonomiske segment).

  • 1
  • 1
#15 Axel Kellermann

Igennem mine tidligere indlæg har jeg tænkt over at målgruppen HA/Cand. Merc. studerende er måske for difus?!? Som tidligere nævnt betragter jeg dem som kommende beslutningstagere eller personer der kommer til at lave beslutningsgrundlag. Derudover forventer jeg at de skal vide noget overordnet omkring udvikling og drift af IT-systemer og have forståelse for hvad det betyder for og kræver af organisationen. Hvis de har et ønske om, at komme tættere på udviklingen af systemer er det vel mere en specialisering de skal ind på, hvor det ikke er muligt at skrive en generel bog på det. Jeg sidder i en organisation hvor der er rigtigt mange der ikke ved noget om IT - også/især beslutningstagere - og der er det som om man stadig forventer at man skubber en CD ind i en PC og så kører det bare - der kunne det være rart bare med noget basalt viden om f.eks. distribuerede systemer, deres kompleksitet og deres indvirkning på driften, men selvfølgelig også hvilke fordele de har. Det bringer mig sådan set også frem til at der ikke er drift med i det. I dag er der rigtigt mange driftsmodeller, hvor det kunne være rart, at der blev opridset forskellige modeller og deres økonomiske, juridiske og organisatoriske konsekvenser.

  • 0
  • 0
#17 Martin Jünckow

Jeg har ikke noget problem med at folk skal have noget generel forståelse for IT systemer, det er helt klart nødvendigt at vi får noget mere fokus på det. Men der kommer et punkt hvor systemerne og kompleksiteten bliver så stor at det begynder at blive mere relevant for softwarearkitekter end for erhvervsøkonomer og hvor forudsætningerne for at forstå hvad vi taler om formentlig ikke er tilstede før man har været min. 5 år ude i erhvervslivet.

  • 1
  • 1
#18 Henrik Fladkjær

Det handler ikke kun om open/closed source. Der er mange andre vigtige aspekter:

Hej Torben, Jeg er rigtig glad for dine mange emner. Specielt dataformater og platforms(u)afhængighed er vigtigt. Nogle af dine andre punkter bliver behandlet i nogle af de kapitler jeg foreslår. Licens og hosting synes jeg eksempelvis vil komme naturligt i forhold til ERP systemer. Det der er vigtigt for mig er, at de studerende med bogen får både et teoretisk og praktisk fundament. Jeg vil gerne have, at det ikke kun bliver textbook it. Derfor synes jeg at det er vigtigt, at eksempelvis licens og hosting ikke bliver for omfangsrigt, da det tager tid fra eksempelvis det at kunne designe en datamodel og udvikle en lille applikation, som eksempelvis kan være en lille kalkulations model de studerende kan præsentere for en virksomhed. Vh Henrik.

  • 0
  • 0
#19 Henrik Fladkjær

Skygge IT er noget der formeteligt skal med her eftersom det er et stort problem og noget der er mindst ligeså ansvarligt for lockin som diverse leverendøres hustleri.

Hej Daniel, Det er nogle spændende betragtninger, jeg selv har vanskeligt ved at forholde mig til, men hvis du er frisk, er jeg sikker på, at du har en rigtig god case, som kunne indgå i bogen. Vh Henrik

  • 0
  • 0
#20 Henrik Fladkjær

Vi besluttede i vores team at gå væk fra grafiske værktøjer til ETL (vi benyttede Talend tidligere, som minder om Pentaho) og istedet skrive vores eget kodebaserede ETL-framework.

Hej Martin. Det er nogle super betragtninger, som jeg igen gerne vil have implemeteret. Umiddelbart går jeg efter en grafisk løsning fordi, som du selv skrive, at det er velegnet til mindre løsninger eller mindre komplicerede projekter og det er det jeg skal bruge. Jeg vil også spørge dig, om ikke jeg kunne få en snak med dig på et tidspunkt i det nye år, hvor jeg kan samle dine kommentarer og din viden op i enten en case eller en faktaboks eller en film, der viser forskellen på et mere kodebaseret ETL versus et grafisk ETL eller en podcast, hvor du kan komme med dine meninger og holdninger. Vh Henrik

  • 0
  • 0
#21 Henrik Fladkjær

Jeg synes, der mangler noget om it-sikkerhed. Man skal have kendskab til emnet, men behøver ikke vide alt.

Hej Ditlev. Jeg er enig i, at der skal noget med om sikkerhed. Fik fortalt en helt ny case herom i week-enden, hvor en virksomhed havde overført en del penge til et udenlandsk selskab tilsyneladende uden problemer. Alle virksomhedens procedurer var overholdt, og den modtagne virksomhed havde afsendt varerne. Efterfølgende skulle der igen overføres penge og den ansvarlige for overførslen kontakter virksomheden for at høre om pengene lige som sidst skal overføres til kontoen i det nye land i stedet for den konto, de normalt havde overført til. Så startede panikken. Virksomheden havde aldrig haft en konto i et nyt land og væk var pengene. Der må igen være nogle spændende cases og nogle grundlæggende retningslinjer man kan opstille. Det der er helt sikkert er, at sikkerhedsaspektet kræver stor fokus, og det kræver viden der er far beyond den viden mine HA vil kunne tilegne sig. Er du frisk er jeg også frisk på en snak herom i det nye år. Vh Henrik

  • 0
  • 0
#22 Henrik Fladkjær

Hej Jesper,

Please, ikke endnu en bog med MySQL.

Please, ikke endnu en bog med MySQL.

Hej Jesper, Daniel og Lars. Jeg har en forventning om, at kapitlet om den relationelle database bliver et af de kapitler, der i bogen vil udkomme som kapitel 6a, 6b, 6c, ..., osv. Jeg vil håbe, at der er nogen der er med på at skrive flere parallelle kapitler om dette vigtige emne. Vh Henrik

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