Det finns naturligtvis många faktorer att överväga när man skall införa ett ”system” för geografisk informationshantering.
”Ett system är ett antal komponenter (delar av systemet) som tillsammans samverkar för ett gemensamt mål.”
– Wikipedia
Det är det här många glömmer, och börjar med en eller ett par komponenter, för att expandera från det. Det behöver inte vara fel, men risken är att delar inte passar ihop och man drabbas av att hela tiden försöka ”fixa” upptäckta problem.
Det dummaste man kan göra är att inte tänka igenom hur hela flödet av information skall fungera. Jag har varit med om att man designat system där det fokuserats på vad rena konsumenter av geodata vill ha och gjort ett supersnyggt (del-) system för dessa, bara för att inse att data måste ju komma någonstans ifrån, och att det finns användare som vill kunna göra mer än att bara titta på en ”dum” bild på en bildskärm.
Mitt första och kanske viktigaste tips för ett lyckat system för hantering av geografisk information blir därför att identifiera hela flödet av information, allt från hur data kommer in, till vilka det är som konsumerar information. Ur detta får man även identifiera vilket informationsbehov olika användare har.
När detta väl är gjort så kan man börja snegla på principiella tekniska lösningar och vilka krav man skall ställa på systemet och dess olika delar.
Efter detta så kan man gå åt många olika håll, men förr eller senare så bygger man en prototyp. Man skall dock inte vara för snabb med detta utan tänka igenom allt riktigt ordentligt först. Prototyper tenderar nämligen att utvecklas till det färdiga systemet och för många är det enklare att fokusera på den del av systemet där problem uppstår och försöka fixa det där, medan den enkla lösningen kanske är att byta en programvara eller ett format någon annanstans.
Mitt andra tips blir därför att man inte skall vara rädd för att tänka om helt och hållet om man stöter på problem i utvecklingsarbetet. Gå tillbaka till de ursprungliga modellerna för flödet av information och undersök olika alternativa lösningar. Det kan bli både enklare och billigare i slutändan, än att försöka ”fixa” ett svårlöst problem.
När man väl valt lösning och börjar implementera så dyker det nästan alltid upp sådant man inte tänkt på eller nya oförutsägbara behov. Det är därför en fördel om man även tar hänsyn till framtida behov och möjligheten till att utveckla systemet efter hand redan när systemet designas. Detta blir därför mitt tredje och sista tips (för den här gången).
- Identifiera hela det geografiska informationsflödet och informationsbehovet för alla användare.
- Ha en helhetssyn vid all problemlösning vid utformningen av systemet, den bästa lösningen finns inte nödvändigtvis där problemet uppstår.
- Designa för framtiden.