Data Management. Tema

Transkript

1 Data Management Tema Data Management handler om mange forskellige aktiviteter og discipliner med det centrale formål at sikre virksomhedens data og at sikre at værdien af disse data bliver realiseret. God data management kan sikre den afgørende fordel i forhold til konkurrenterne.

2 Introduktion til Data Management Data strategi Data er blevet forretningskritisk og et væsentligt konkurrenceparameter for virksomheder. Hvor data tidligere snarere var et værktøj, er det i dag ofte her fårene skilles fra bukkene. De virksomheder, som forstår at indsamle, bevare og udnytte deres data vil have en vigtig konkurrencefordel. På forretningsniveau er det afgørende, at virksomheden en gang for alle får udviklet en datastrategi, således at der i virksomheden er en klar holdning til, hvordan data skal bruges og tilgås på tværs af virksomheden. Herefter er det vigtigt at vælge de rette værktøjer til at understøtte virksomhedens datastrategi. Med dette udgangspunkt vil det være muligt at udvikle et klart roadmap for udvikling af virksomhedens systemer, således at de bedst understøtter behovene. Herved vil det blive nemmere at få et overblik over, hvor man skal starte både ud fra hvor den største værdi er at hente, men ligeledes ud fra virksomhedens overordnede strategi, således at denne understøttes og til dels drives af den rette it-understøttelse.

3 Master Data Management Master Data is a single source of key business data, which is used across different systems and platforms in a business. Master data guides how transactions finds their way through your business to deliver the promised service to your customers. You might have defined optimized processes for servicing your customers and brilliant-looking reports and dashboards for management. But what does it matter if you consider the following: If you do not have correct address information, then you might ship goods the wrong place. If you do not maintain correct product codes across systems, you might end up sending the wrong product to the customer. If you assign the wrong payment terms, you may jeopardize your business cash flow. If you assign wrong employee data, your employees may not get paid in accordance with their contracts. Examples are plenty. In all areas of your business, data management can make the difference between a business running smoothly or a business spending too much time on exception and error handling. Manage your data Data has to be managed, controlled and reported in order to make sure data is in pristine shape and ready to service different areas across your business and your customers. By managed, I mean operationally managed. Not just a one-off data cleaning blitz once in a while when you realize that data quality in a subpart of your business is lacking and thus hurting your customers or your ability to control and direct your business. You have to set up your workflow and controlling processes to proactively monitor and correct master data as it enters your business. Ideally user interfaces in your business systems do not allow incorrect values, e.g. stopping an address that doesn t exist, but many times this is not possible. But to know which data needs to be managed and controlled more carefully you need Master Data Governance.

4 Master Data Governance We don t have to make it more boring than it already is by combining Master Data and Governance in the same sentence. Maybe it should be called Business Power and Mastery? The people who are given the power to define what data is important to form the building blocks of any business, i.e. customer, product, people, etc., have an immense impact on the business. They will pave the way as knowledge about the business is leveraged to slay the competition and provide an even better match between products/services and the most coveted commodities in the marketplace: customers with money to spend. Mastering the definitions of the business building blocks and the ongoing process of making sure this data is kept in pristine state requires mastery; mastery in knowing what data is required for servicing the customer, what data is required for targeting the customer, and what data is required to measure the progress of your business. In our experience less is more. Have only the right characteristics in place and bin all data you are not able to explain the use of - or which you have not used for something significant in the last year. Make sure you have reporting in place to monitor the completeness and validity of data. And if you are dead serious about data you will have systems filling in the blanks for you, e.g. postal code when City or phone number information is available, and check validity of addresses.

5 Master Data Services Master Data Services is a tool included in Microsoft SQL Server tool to maintain and develop business rules in a more automatic way and maintain a high data governance to continuously uphold a high data quality. Master Data Services gives your business users an insight into how your data maps and data are structured on a company level. Advantages: Validation of data (rules and lists) Mapping and structuring of Entities is simple in either a Web interface or Excel Change revision. Who changed what and when? Versioning gives you options to experiment, without breaking production Central place of master data, which every system could subscribe to Data Quality Services Data Quality Services is a service that helps you clean your data. You can generate rules that help new data (i.e. a new customer) coming in, being aligned with your business and handle this issue automatically. Advantages: Smart cleansing of data (computer assisted instead of manually maintained rules) Remove duplicates by semantic comparison of data Cleansing using external source (postal code, country, address etc.) Data Quality Services combined with Master Data Services is a powerful tool to clean, maintain and administer your Master Data within a well-defined model and a source for other systems. And that s the bottom line Master Data Management has a direct impact on your bottom line whether you are able to quantify it or not. Manage your processes and govern your data to rid your systems of bad data, and use proven technology so that you do not have to do it all by hand.

6 Risici ved Excel Excel er et rigtigt godt værktøj og en uundværlig del af dagligdagen for de fleste virksomheder. Det er relativt nemt at komme i gang med, men kan alt fra statiske analyser på meget store mængder data til simple beregninger og hurtige visualiseringer. Derfor er det - trods blot omkring 20 år på bagen - blevet et af finansafdelingernes mest centrale værktøjer. I forhold til data management i Excel er der dog nogle problemstillinger, man bør overveje. Det mulige og det ønskelige Når det kommer til Excel, er man nødt til at skelne mellem, hvad der er teknisk muligt, og hvad der egentligt er ønskeligt. Med Power BI har Microsoft øget mulighederne, men problemerne ved at foretage databehandling i Excel er stadig de samme, hvis man bevæger sig ud over de kernefunktionaliteter, programmet er rigtigt godt til. Det er nok Excels tilgængelighed, som gør, at mange virksomheder i vækst blot fortsætter med udvikling af et komplekst netværk af Excel-ark, som understøtter forretningens forskellige behov for rapportering, analyse og databehandling. Uden grundige overvejelser omkring risikostyring kan dette dog være en problematisk strategi. I denne artikel ser vi på de konkrete problemer og risici, som er forbundet med anvendelsen af Excel i forskellige dele af forretningen. Hvilke risici åbner man sig for? Og hvad bør man sikre, hvis man vil beholde sin Excel-løsning?

7 Forretningskritiske Excel-ark Hvorvidt databehandling i Excel er kritisk handler på den ene side om mængder og kompleksitet og på den anden side om vigtigheden af de data, som behandles. Store datamængder og komplekse sammenhænge, fx mellem flere ark, er svære at overskue, og kan især udgøre en risiko ved almindelig brug, fx på grund af forkert indtastning, forkert markering af felter eller fejl i formler. Det lyder måske relativt uskyldigt, men den nok mest kendte kostede investeringsbanken JP Morgan 6 mia. dollars. Fejl er reglen, ikke undtagelsen. Nogle fejl er dyrere end andre. Behandler man meget vigtig data i Excel-ark, bør man altid - uanset om det er store mængder eller komplekse datasæt - tage skridt til at sikre integriteten ved at opstille regler og procedurer for, hvordan man håndterer sine regneark. Man kunne starte med at stille sig selv disse spørgsmål: Baselines Excel-ark i virksomheden? Altså tjekkes alle formler og funktioner indledningsvist. Hvem/hvor mange har adgang til arket? Er formler beskyttede mod ændringer? Hvordan sikrer man versionering, og at flere ikke arbejder samtidig i arket? Har (og vedligeholder) man dokumentation omkring ark (kilder og sammenhæng med andre regneark)? Det er altså et spørgsmål om, hvordan man garderer sig mod, at fx tastefejl forekommer og korrumperer data. I Excel er problemet netop, at når disse fejl forekommer (eller måske rettere: når de bliver opdaget), er det meget besværligt at rette dem og spore konsekvenserne, da historikken er tabt. Afledte problemer Udover deciderede fejl er der en række afledte problemstillinger ved databehandling i Excel. Ofte opstår disse problemer, fordi regnearkene er lokalt forankrede i enten en afdeling, hos en leder eller ved specifikke medarbejdere. Dette øger afhængigheden af enkelte personers viden, hvilket er et problem i forhold til sygdom, ferie, jobskifte og overlevering af opgaver. Herudover ser vi ofte, at denne tilgang til data betyder, at forskellige afdelinger arbejder med forskellige definitioner af nøgletal. Dette skaber naturlige problemer i forhold til analyser, men betyder samtidig også, at implementering af ændringer kan besværliggøres på tværs af virksomheden, fordi de netop aldrig er blevet defineret.

8 Symptomerne på mangelfuld databehandling kan således være mange: Afhængighed af enkelte personers viden Langsom rapportering pga manuelle processer Ukomplette rapporter pga manglende indtastninger /mangelfuld opdatering Besværligt at opdage og spore fejl Besværligt at implementere ændringer i definitioner på tværs af virksomheden Manglende mulighed for at genskabe efter fejl tabt historik Flere forskellige udgaver af sandheden Disse peger alle på en række steder, hvor man ligeledes med fordel kan se på arbejdsprocesser og overveje, hvordan/om databehandlingen understøtter dem. Her er Excel ikke nødvendigvis et problem, blot ikke den optimale løsning f(x)=24845*x^ *x x=

9 Bunker Holding Dan Bunkering Dan Bunkering Copenhagen Middelfart Singapore KPI Bridge Oil London East North West SABT South Africa New York Manhattan Brooklyn Queens Profit Profit pr. trader ROI Profit Profit pr. trader ROI Profit Profit pr. trader ROI , ,00 4,50% , ,00 3,5% , ,00 2,5% Dan Bunkering Dan Bunkering Copenhagen Middelfart Singapore KPI Bridge Oil London East North West SABT South Africa New York Manhattan Brooklyn Queens Today Profit Profit pr. trader ROI Month Year to Date Profit , ,00 Profit ,50 Profit pr. trader ,00 ROI 3,5% Profit ,50 Profit pr. trader ,00 ROI 2,5% 4,50% Dan Bunkering Dan Bunkering Copenhagen Middelfart Singapore KPI Bridge Oil London East North West SABT South Africa New York Manhattan Brooklyn Queens Today Profit Profit pr. trader ROI , ,00 4,50% Month Profit ,50 Profit pr. trader ,00 ROI 3,5% Year to Date Profit ,50 Profit pr. trader ,00 ROI 2,5% Profit Today Month Year to Date Profit Optimér brug minimér risiko For mange kokke fordærver maden, siges det. Det samme kan med rette siges om Excel. Jo flere mennesker, der bruger, udvikler og behandler et (komplekst net af) Excel-ark, desto større er risikoen for fejl og dermed kravene til stramme processer. Når data anvendes til beslutningsstøtte, skal de med sikkerhed være korrekte. Denne sikkerhed mindskes eller bliver meget ressourcekrævende at garantere i Excel, når virksomheden vækster. I bund og grund handler det hele om, hvorvidt man er bedre stillet med et data warehouse og en Business Intelligence-løsning. Eftersom Microsoft også har nogle rigtigt gode BI-værktøjer, som kan integreres med Excel, kan man bevare det velkendte miljø og samtidig opnå en mere hensigtsmæssig og anvendelig løsning. Det er ikke nødvendigvis en stor opgave, men den er nødvendig.

10 Data Warehouset En grundig og frem for alt ensartet databehandling kræver et data warehouse. Dette sikrer, at nøgletal er udregnet ensartet og derfor ikke bliver grund til diskussioner. I et data warehouse sikrer vi én central beslutnings- og behandlingsproces, som for eksempel betyder, at nøgletal altid bliver udregnet efter samme formel, og at kunder altid optræder med samme kundeid. Når først datakvaliteten på denne måde er sikret, kan vi koble andre værktøjer på, fx Excel. Excel Med en nem brugerflade, kort indlæringskurve og nærmest uendelige anvendelsesmuligheder er Excel blevet en fast installation på enhver computer i så godt som enhver større virksomhed. Nogle kalder endda Excel for en forudsætning for den udvikling, vi har set i den finansielle verdens produkter og hermed storhed og forfald. Men det er en anden historie. Pointen er, at Excel er et fortræffeligt program til de ting, Excel er skabt for at håndtere. Til databehandling i en virksomhed er det ikke en god langsigtet løsning. En langsigtet løsning vil sikre, at medarbejdere ikke foretager datavask i Excel (dvs. sorterer og ensarter), og at de ikke kombinerer data fra forskellige systemer, da disse handlinger giver problemer med definitioner og dermed uensartede resultater. En langsigtet løsning sikrer så vidt som muligt integriteten, samtidig med at den sikrer medarbejdernes adgang til at analysere data. Når virksomheden vokser, bør man derfor udfase brugen af Excel til kritisk databehandling og analyse. Den oplagte løsning er at implementere et data warehouse og automatiseret setup til analyse og rapportering. Simpelt rapporteringssetup Afhængig af en virksomheds størrelse og kompleksitet kan der være et varierende antal datakilder, som danner grundlag for vigtige rapporter. I begyndelsen drejer det sig måske blot om et CRM, ERP og ordresystem. Nøgletal trækkes ud af disse kildesystemer og lægges ind i Excel, hvorefter de kan bruges til analyser og rapportering.

11 de datagrundlaget til fremtiden. Et data warehouse er ikke den eneste og endegyldige løsning. Det er dog den, vi ser på i denne artikel. Data warehouse-løsning Et data warehouse indsættes som mellemled mellem kildesystemerne og brugere. Så langt så godt. Problemerne synliggøres for alvor, når virksomheden vokser, og problemerne beskrevet i artiklen Risici ved Excel begynder at udgøre en væsentlig risiko i virksomheden. Samtidig begynder flere afdelinger at trække tal ud og lave deres egne udregninger af nøgletal og rapporter. Vækst og timing Når en virksomhed vækster, bør master data management og en god datastrategi blive centrale begreber for at sikre, at man får udnyttet sine data både nu og i fremtiden. Business Intelligence er dog stadig så nyt et fag, at dette langtfra altid sker i praksis. Timing kan også være en udfordring her. En investering i en server og et data warehouse kan være en stor udgift, som samtidig kræver udvikling og vedligehold. Her kan det være en god idé at tage en snak med en konsulent omkring mulige løsninger. Selvom man ikke er klar til et data warehouse, kan det alligevel være aktuelt at forbere- Før data samles i data warehouset, gennemgår de en proces, hvor de renses og ensartes, så de arbejder med samme definitioner og kan bruges til analyser på tværs. Arbejdet med at opsætte et data warehouse er således ikke blot en it-proces, men en vigtig optimering af forretningen og processerne. Det betyder for eksempel, at man én gang for alle får skabt én sandhed på tværs af forretningen og idet denne er centralt defineret, kan den også hurtigt ændres. Fordelen er en central administration af definitioner og data, som giver høj sikkerhed og effektiv rapportering. Ulempen er, at man mister lidt fleksibilitet i forhold til ad hoc-rapportering. Men det er der råd for.

12 En vigtigt ting her er også, at efterhånden som flere systemer tages i brug i virksomheden, kan data warehouse-løsningen udvides og skaleres uden yderligere risiko. Det kan bestemt ikke siges om Excel. Automatiseret rapportering Et data warehouse er rigtigt godt, når man vil automatisere de faste rapporter. Typisk vil man foretage en analyse af forretningens behov og lave nogle faste nøgletalsberegninger, som målrettes det informationsbehov den enkelte bruger har. Herefter opsættes et direkte flow af data fra kildesystemerne til slutbrugeren. Nøgletal kan leveres på denne måde fx i faste rapporter på en mail eller i fx Pivot-tabeller, så modtageren kan interagere med dem, dog stadig inden for de rammer, der er opsat i rapporten. Skal brugeren have adgang til andre datasæt, kræver dette et andet setup. Det vil typisk være fx controllere, som vil foretage mere eksplorative ad hoc-analyser. Her er der mulighed for at lave en separat self service-løsning. foretages i Excel (evt. med Microsoft Power BI) eller et andet velkendt værktøj. Ofte kombinerer vi løsninger, så controllere og analytikere får stillet data til rådighed i særskilte værktøjer, mens de faste rapporter kører automatisk og leveres i andre værktøjer eller bare som en graf i en mail i det interval, der er nødvendigt. Det er der mange fordele ved, da hver bruger får de data, de skal bruge hverken mere eller mindre. For stor detaljeringsgrad kan være en stor tidsrøver for brugeren, som kun skal bruge overskrifterne. Self Service-løsning En self service-løsning betyder, at vi stiller datasæt til rådighed i et værktøj som fx Power BI, hvor brugerne kan rode rundt i tallene, som de ønsker. Data skal dog stadig igennem data warehouset. Til gengæld er de ensartet, og der er ingen risiko for at korrumpere dem. Det betyder, at meget af forarbejdet allerede er foretaget, så fx controllere kan gå direkte til analysedelen. Dette arbejde kan så

13 BI Governance Når man opsætter en self service-løsning kan man med fordel i samme ombæring sørge for at opstille nogle effektive procedurer for BI Governance. Dette kan også med fordel være en del af datastrategien. BI Governance skal dels sikre, at de rapporter og nøgletal, virksomheden opererer med, fortsat er de rette, samt at de vigtigste rapporter fra self service-løsningen bliver implementeret og tilgængelige på tværs af virksomheden. Udover at det er en fornuftig tilgang til styring af data, giver det også nogle konkrete fordele i forhold til udnyttelse af interne kompetencer. Med en god self service-løsning udvikler brugerne selv de analyser og rapporter, virksomheden skal bruge. Det minimerer udviklingstiden og mindsker dermed virksomhedens brug af eksterne konsulenter. Samtidig sikrer det, at løsninger bliver afprøvet, før de bliver stillet til rådighed for andre brugere, så man kun udvikler de løsninger, som faktisk anvendes. En styrket forretning Skiftet til en data warehouse-løsning styrker datakvalitet, databehandling og rapportering. Det er også en god lejlighed til at strømline forretningen og sikre ensartede definitioner og automatiserede processer. Uanset om timingen er rigtig til at implementere et data warehouse, bør man som minimum lave en datastrategi og et road map. Governance er ikke just det mest sexede ord, men ikke desto mindre er det vigtigt. Det er en del af et smidigt setup, som understøtter forretningen bedst muligt. Når man tager sig tiden til at udføre arbejdet, skærer man ned på fejl og skruer op for den tid, medarbejderne har til analyser og handling. Alt i alt giver det en styrket forretning, som er klar til vækst.

14 Decentralisering af data Inden for data management har vi i årevis søgt at centralisere databehandlingen for at sikre ensartetheden på tværs af virksomheden. Modsætningen hertil har været dataanarkiet i de enkelte afdelinger og den usammenhængende tilgang til virksomhedens data. En tredje mulighed er dog ved vinde frem: den decentraliserede arkitektur, som giver mulighed for at skabe unikke systemer ude i afdelingerne og integrere dem med en samlet løsning. I enterprise-arkitektur har der engang været en tendens til at betragte organisationers systemer og data som et konsistent og entydigt system, der skulle organiseres i hierarkisk opbyggede modeller. Hermed kunne man centralisere datamodeller og forretningsansvar, så hvert stykke data ville være entydigt repræsenteret i hele virksomheden. I praksis kan denne tilgang dog være svær at få til at fungere. At presse en rigid hierarkisk arkitektur ned over en dynamisk og agil organisation kan skabe problemer. Ofte vil vi se, at visse dele af organisationers data i stedet sagtens kan behandles centralt, mens andre med fordel kan decentraliseres. Det vil sige, at man kan beholde et centralt ERP-system og supplere dette med mindre, agile enheder, som kan tilpasses afdelingers databehov. I denne artikel ser vi nærmere på, hvordan data kan behandles decentralt. Et eksempel Lad os tage et eksempel: En kunde. I en tilfældig virksomhed taler man om "en kunde", og alle er enige om, at en kunde er en, man sælger noget til. Men lad os nu prøve at beskrive en kunde via de (fiktive :)) egenskaber, som de enkelte afdelinger tillægger denne kunde: CRM-afdelingen: Her registreres firmaets kontakter sådan, at man kan pleje det professionelle forhold ved at sende julekort og chokolade mm. Her interesserer man sig for kundens ID, kontaktoplysninger, kommunikationslog, kontakter, osv.

15 Salgsafdelingen: I salg ringer man jævnligt til kontakter ved modpartens indkøbsafdeling og tilbyder dem ting og sager, som de måske køber. Her er man interesseret i kundens ID, historiske salg, telefonnumre og -adresser på indkøbere. Økonomiafdelingen: I økonomi står de for at sende fakturaer til kunderne efter et mønster dikteret af en kontrakt. I denne afdeling er man interesseret i kundens ID, konti, kontrakt, kredit, faktureringsoplysninger, osv. I dette tilfælde ses det, at de forskellige afdelinger i virkeligheden har et meget forskelligt syn på, hvad det (datamæssigt) indebærer at være en kunde. Det eneste, de allesammen er enige om, er kundens ID - men denne egenskab har jeg markeret med fed, fordi det er en surrogat-egenskab, hvis eneste formål er at identificere kunden på tværs af de vidt forskellige opfattelser, som de forskellige afdelinger har. Der kan naturligvis være egenskaber, som ved første øjekast synes at være de samme. Det kan f.eks. være kundens adresse, som formentlig vil være associeret med kunden i CRM-afdelingen, sådan at man kan sende en æske chokolade, når det bliver jul, og som samtidig er associeret med kunden i økonomiafdelingen, sådan at man kan sende en masse fakturaer. Men ofte skal fakturaer adresseres til kundens regnskabsafdeling, og hvis kunden er lille, er "regnskabsafdelingen" måske i virkeligheden kundens advokat eller revisor... pludselig er det ikke nok med en enkelt adresse på kunden! Derudover har jeg begået en lille potentielt fatal antagelse: Vha. kundens ID har jeg antaget en kardinalitet på tværs, som gør det umuligt for salgsafdelingen at handle med f.eks. uafhængige underafdelinger af kundens firma! Måske er det i virkeligheden kun CRM, der skal betragte noget som en "kunde", eller er "kontakt" ikke et mere beskrivende ord? Måske hedder det "modpart" i salgsafdelingen og "kontraktindehaver" i økonomiafdelingen? Det er ikke svært at forestille sig, at det ville være svært at opbygge én central datamodel for alle aspekter af en kunde, som skal tilfredsstille alle afdelingers behov for oplysninger - ikke desto mindre så er det altså det, man har forsøgt at gøre med de såkaldte "kanoniske modeller", hvor ambitionen er, at hver ting (hver "entitet") i virksomhedens domæne har én kanonisk repræsentation, som alle systemer er enige om. Min egen erfaring er, at sådanne projekter fx kan medføre ringe evne til at skalere og desuden stå i

16 vejen for it-projekter, som skal flytte forretningen ude i afdelingerne. Min opfattelse er også, at flere og flere virksomheder er ved at indse dette, og løsningen er egentlig forholdsvis ligetil: Man skal omfavne det organiske i stedet for at bekæmpe det! Med andre ord, så taler dette for, at man bør decentralisere systemer og decentralisere data, på samme måde som man formentlig i virksomheden er opdelt i selvstændige enheder (afdelinger, teams, individer), som interagerer med hinanden, og alle arbejder direkte eller indirekte for at opnå et kollektivt mål. Omfavn decentralisering af data Hvis vi nu accepterer, at vores data ikke længere udelukkende ligger i én stor model af hele verden, men at vores data nu ligger mere spredt rundt omkring i virksomhedens systemer, fysisk adskilt - hvilke fordele og ulemper giver dette så? Der kan være ulemper Denne måde at tænke systemer på er ikke en simplificering, men en anden måde at håndtere kompleksiteten på med nogle andre fordele og andre ulemper. Af ulemper skal nævnes, at der bliver større krav om integration mellem systemer - f.eks. kunne man forestille sig, at en markering som "dårlig betaler" i økonomiafdelingen skal medføre en advarsel i salgsafdelingens handelssystem, når en sælger er ved at tage kontakt til den pågældende kunde. Dette kræver enten en form for datasynkronisering (med risiko for den kan være ude af sync) eller en anden måde at integrere oplysninger fra ét system ind i et andet. En anden ulempe er, at det samlede billede bliver mere uoverskueligt. Der er større krav til at definere betydning og formål for de enkelte oplysninger rundt omkring i de enkelte systemer, sådan at man kan være forvisset om, at de pågældende oplysninger er korrekt placeret. Driftsmæssigt får det naturligvis også konsekvenser, idet DBA'erne måske skal vænne sig til at tænke på drift af databaser på en ny måde....men der er heldigvis også fordele Decentralisering af data gør de enkelte komponenter langt mere autonome. De påkrævede integtionspunkter vil, hvis man gør sig umage, være små og veldefinerede, og det enkelte system kan fungere uafhængigt af resten af organisationen, hvilket har mange gode konsekvenser. De enkelte systemer kan herefter udvikles uafhængigt af hinanden og opdateres, uden at andre systemer behøver opdage det. Et problem i ét system vil ofte være lokaliseret til blot det ene system og vil ikke påvirke andre.

17 Det enkelte system vil være langt nemmere at overskue for udviklere ved udvikling af nye features og fejlretning - så længe kontrakterne til de andre systemer er overholdt, kan de tilføje funktionalitet og refaktorere eksisterende kode med langt større sikkerhed for, at de ikke kommer til at spænde ben for noget andet. Det kan desuden være befriende, at man i den ene afdeling kan bruge SQL Server til datamodellering, fordi man i den pågældende afdeling primært skal gemme tabulare data med en rigid datamodel, mens man i en anden afdeling kan bruge RavenDB, fordi man gerne vil benytte sig af en rig, objektorienteret domain-driven design-inspireret datamodel. Den opnåede fleksibilitet kan desuden udmøntes i en radikalt anderledes tilgang til opbygningen af den enkelte applikation, f.eks. kunne det tænkes, at en applikation egnede sig virkelig godt til event sourcing og CQRS, hvorfor det ville være naturligt at benytte sig af en specialiseret event store-database, og arkiveringssystemet til arkivering af al historik vedrørende kundeforhold, udvekslede dokumenter osv. kunne tænkes at være baseret på SharePoint eller ElasticSearch på et cluster af Ubuntu-maskiner - der er mange muligheder! Konklusion Der er mange fordele at høste ved at betragte organisationer som organiske størrelser, som i langt højere grad skal understøttes af et "levende system" frem for et "planlagt system" (læs evt. Pieter Hintjens om "The Power Of Living Systems"). Det levende system opstår ved en form for organisk vækst, hvor løst koblede komponenter samarbejder på kryds og tværs, og decentralisering af data er en naturlig konsekvens af denne tankegang. Decentraliseringen af data vil, som alle andre beslutninger, være et tradeoff, hvor ulemper og fordele naturligvis skal opvejes i forhold til den mere hierarkiske og systematiske tilgang, men det vil ofte være gavnligt at forsøge at følge organisationens kommunikationsstrukturer frem for at kæmpe imod dem, og det medfører med stor sandsynlighed krav om en vis grad af autonomi i den enkelte komponenter.

18 SQL or NoSQL NoSQL is a term used to describe a set of databases, which are not modelled as the relational databases most people know, e.g. SQL. The NoSQL databases are particularly suited to creating distributed systems and decentralized architecture. In this article, we take a look at the main differences seen from a technical perspective. Any application, regardless of how simple, will eventually need to persist information. There are two major ways of storing information: durable and non-durable. Durable means that information is persisted in a non-volatile fashion and can be retrieved in the exact same format at a later date. Durable persistence is usually achieved by storing the information on a physical medium (hard drive, compact disc, etc). Non-durable information persistence is, as expected, the opposite of the durable one: it stores information in a volatile manner and is most likely affected by computer power cycling (aka reboot). In this post we will take a small dive into durable information persistence, and the existing software paradigms achieving this persistence type. The History of SQL At the very beginning of computers, there were no database systems, there were just a bunch of smart people achieving incredible results in the form of software programs, with little to no tooling at all. Basically, the programmer was not only concerned with capturing the business needs and encoding them into programs, they were also responsible for creating the infrastructure that we, today's programmers, take for granted.

19 There were no database systems, there were no standards on how to structure your data, and programmers had to constantly re-invent the wheel with each project, learn from their mistakes, and re-invent the wheel again. At this point, another smart person, Dr. E. F. Codd, wrote an article, "A Relational Model of Data for Large Shared Data Banks", in which he committed to find a generic, machine independent, solution to data persistence. Fast forward 44 years and you will find that his theory was put into practice in the most used database systems today. His principles formed the basis of relational databases. The set of instructions used to interact with such systems is known as SQL (Structured Query Language). Make no mistake, even though relational databases might seem old and deprecated to the untrained eye, they are still a viable solution to data persistence, manipulation, and query. Keep in mind that relational databases have been around for more than 4 decades now, that means 4 decades of improvements and fine performance tuning. If SQL is cool enough, why the need for NOSQL, and what is NOSQL in the first place? NOSQL stands for Not Only SQL and it represents a category of database systems that do not embrace the relational model proposed by the relational databases. The main types that fall under the NOSQL category are: Key/value databases - the information is identified by a unique key, and the only way to access that information is by using that key. Document databases - the information is stored in documents, which are uniquely identified by a key. An extra benefit is that you can query the documents and you aren't constrained to retrieving the documents only by their unique identifier. Graph databases - the information is stored in nodes, edges, and properties. Column-oriented databases - information is stored as sections of columns, rather than rows of data. As previously stated, relational databases do a good job when it comes to handling data, however, they require that your data is stored in a structured format. This may not look like a problem at the beginning, but, as a project grows, so does the number of tables, and so does the number of programmers working at the project. This means that all programmers must be in sync when it comes to making changes to the structure of the database, and keeping people in sync is an activity that is best not to be practiced.

20 On the other hand, NOSQL databases are generally designed to easily cope with a changing data structure, and they are more than happy to accept any kind of information you throw at them (no predefined schema information is required). However, one can argue that it is a small price to pay for the benefits you get: fast I/O operations, referential integrity guarantees, cascade operations, etc. Because they are not confined to specifying a schema first, programmers are able to do fast iterations and, most of the time, only concentrate on solving the business needs, forgetting about keeping mapping files synchronized, generating database models, or any other hurtful operation from the SQL world. Transitioning from SQL to NOSQL Requires the programmer to be accustomed with at least the following: Eventual consistency SQL databases are consistent, meaning that after the database has accepted a piece of information you are guaranteed that you can query and retrieve that information right away. This behavior has direct implications to the speed at which the database can process commands. Take for example an insert operation, the time necessary to perform the operation is made out of the actual time needed to physically store the information + the time necessary to index the information (the more indexes you have, the more the time increases). To clear things out, an index is a data structure used by all database systems to speed up the retrieval process of information. In the quest for being faster some NOSQL databases have split the above described process in two distinct and asynchronous parts. The first step is performing the physical actions (storing data), and the second one is indexing (making sure that the information can be queried). What is important to notice here is that indexing doesn t happen at the same time as the physical operation; indexing happens later on. Apart from allowing the database to have a high number of data mutation operations per second, the deferred indexing strategy has another side effect, known as stale data. The phenomenon of stale data occurs in the following scenario: 1. You have a database with a lot of mutation requests 2. The database accepts all your requests and processes them quickly 3. Usually, priority is given to mutation requests and this causes the indexes to become out of date for slight periods of time 4. If you attempt to query the index in those periods of time, you will be querying data which is not up to date