Project Breakdown Planning in GIS – an SOA approach

OK, so I’ve been asked to break down our components into a set for quotation purposes. Our project is looking to get going but needs quotes from analysis, development, testing, architecture, implementation, Project Management – the usual suspects.

Time I got my PRINCE2 guide out…

Actually, there are some great ideas in PRINCE that are good to implement without tying down too far. A PBS (or indeed, Work Breakdown Structure) is a pretty good way of starting off.

As our project looks to follow de-coupled services, I found that it broke down into component parts a lot easier because we’d already got our tiers sorted out. It’s a good example of where a technological approach maps pretty well to project planning approach, because you’ve managed to chunk-up discrete blocks of work, which are de-coupled pretty well.

Anyway I managed to go through each of the tiers and they fit nicely into Management, Solution and User products really well. The User Products then distilled into each of the tiers we’d identified.. which was nice. Keeping everything decoupled means that you can swap in and out various vendor solutions. You can even go with the idea of using a commercial package initially, and then move to open source, if you believe that you may not be able to meet the longer term licensing costs. Or even go the other way: go open source for a start to prove the solution, then swap-in commercial when you need need operational support.

Abstracting functionality into services is a great idea, but something pops out at you whilst doing this: aren’t there a common set of services common to all GISs? Don’t GISs all require a set of common elements: ‘identify things at this point’, ‘ jump to a location’, ‘search my database and select my record’. They form natural patterns. It’s true; and for this, it’s important to know that whatever solution chosen, it should be able to derive these pretty quickly, by wrapping up standard functionality into these common services.

So… once you’ve done that, how much of a solution have you got? Well, as you develop functionality, at some point, you’re going to hit that magical percentage of requirements where you can start to roll out the system. It doesn’t need to be 100%; but just enough to go beyond proving and into first iteration. You can probably satisfy the requirements of most users, before going into the ‘special cases’. For these, I don’t think that you need to go so SOA. That last 20% will inherently probably be non-generic; in which case, you don’t need the overhead of the SOA route.

So after all that – voila, you’ve got a solution where you’ve correctly created a suite of re-usable components, you can switch in/out components as improved alternatives come along, and, finally, you’ve developed a solution that is going to be of immediate use to your user population.