Developing a GeoStack
From time to time, someone will stand up and proclaim themselves above “stacks“. I’ve done it and I’m sure you also do it. The reality is that we apply our preferences on our own GIS Stacks. Should you fear a stack? As I often like to say, the best solution for the best problem. This might mean an ESRI stack one morning, a GeoServer stack in the afternoon and maybe a Microsoft stack at night. The term stack seems to be getting a bad rap in the geo world. I suppose being close minded about solutions (even within proprietary and open source stacks) can cause you to implement the wrong solution at the wrong price. I like the idea of the problem dictating what solution stack you’ll go with in the end. I’ve got preferences to my solutions, but I rarely enter a project exactly knowing what the whole stack will look like (beyond the OS). As I begin to prepare to kickoff a project next week with a client, I’m thinking tonight about what I’m working with; ArcSDE 9.2, Apache with Tomcat and Oracle 10g. Beyond that I’m free to work with whatever solution best meets the customers needs. Do we go with ArcGIS Server 9.2 or 9.3? Do we go with the Java Web ADF or the ESRI REST API? Do we go with GeoServer or MapServer? Do we go with the ArcGIS JavaScript API or OpenLayers?
I can’t wait until next week to find out our stack.
Will it be the stack behind door number 1, door number 2 or door number 3?
Very often, the choice of components inside the ‘stack’ is lead by non technical questions.
The first question, while thinking at a new distributed GIS infrastructure (may I say SDI – Spatial Data Infrastructure ?), should be something like ‘Can they afford the (impressive) price of ESRI licences for ArcGIS Server, ArcGIS Desktop, Geoportal Toolkit, etc?’ If the answer is ‘Yes’, and if the scale of the project justifies it (e.g.: would you realy ask them to pay those licences for hosting a single WMS service that is never updated?), then the ESRI stack is a good option, as it provides – i think – better productivity for less efforts.
But another parameter has to be taken in account by external consultants: Open Source will generate more consultancy days, and more ad hoc developments, so more work for them, at comparable project price! Maybe this reasoning can look strange, but I suspect this happens, as we are in a market economy
Yeah, in all my years of GIS/Imagery, etc it comes down to having a blank check, and if I have to walk into an existing IT structure and fit the GIS in (ex/ “We already have all our other company’s data in Oracle, so you will use oracle for your GIS data”) or a few years ago I was lucky enough to have an “empty office” with a large budget, so I could build the stack from the ground up (“large budget”.. not gonna see that again anytime soon).
..so James, as you mentioned we claim to be above stacks, but usually we end up (sub)consciously pushing our favorites within the budget.. I guess we all want to strive to actually leave our biases/loves/hates at the door, really listen to the clients needs, and build the best solution for THEIR workflow…
…and world peace would be nice too
Good luck with the new client.
Cheers!
GT
Er…what’s the problem? Sure, “stack” has become a bit of a buzzword, but as a GIS-newbie with 20 years in IT, I find it’s as useful a term as any to remind us that a multi-tier GIS application can be built using a variety of components for the individual tiers, rather than as an old-style all-or-nothing ESRI “stove-pipe”, for example. Out in the mainstream IT world, we’ve been using “stacks” of components for n-tier web applications for years, and it’s good to see GIS joining the rest of us in the 21st century.
So if you want a “stack” of high-end/high-cost ESRI components, integrating and operating smoothly and seamlessly as only ESRI can, go for it: the “cheque” will probably be more of a factor in your decisions than the “stack”, after all.
But if you want to mix and match components according to your budget/needs (I dunno – GRASS + GeoServer + PostGIS, MapGuide + Oracle, Manifold + SQL Server, or whatever), what other term would you use to describe the…er…pile of components you need to put together?
Maybe a “crock”. Or is that just me…?
By the way, the GeoServer WAR (huh – what is it good for?) will drop very easily into your Tomcat server (but you knew that already, right?). Dunno about MapServer. Good luck anyway.
As vendors support interoperable standards and the same non functional requirements (i.e. DB, OS, App Servers, etc), customers will soon be capable of essentially “picking” the correct software that has the “feature” the client needs and performs the customers use case the best!
Interoperabilty and compliance with standards will commodotize GIS software. It really doesn’t matter “what” softare is in the stack, you can use the software that “works best” rather than being required to dive headlong into an “all or nothing” proprietary solution.
In the long run, it will also greatly reduce the development costs to customers by reducing the need to “bind” API’s of different softwares with middleware (usually developed by consultants).
THE ONE VENDOR STACK is dead…
Open source software has too many issue with non functional requirements, stability and ability to get a timely response on production stopper bugs and improvements that push IT decision makers away from it. NOTHING IS FREE!!!! If you require support, training, responsiveness in fixing bugs, stability and a “say” in the direction of the product, you must buy commercial. In the end, the consumer ends up paying more for the customization and integration than they would have from buying a COTS, interoperable software.
Hilarity. I would agree that proprietary products usually provide more features on zero day, and certainly more formal training and beginners documentation, your other items (responsiveness in fixing bugs and a “say” in direction) to me fall solidly on the side of open source.
You can get a bug fixed and patched on your systems with open source in days, just apply money. The same is not true in proprietary — if the vendor isn’t interested, no amount of money will change their mind. They have other priorities.
Similarly with “having a say”. The price of “relevance” to an open source community is so much lower. Employ one full-time developer, and pow, you’ve got a pretty strong say in direction. Thats no more than $100K. How big would your account with ESRI have to be before Jack starts sitting down with you and asking “so, what do you really need from us?”
You’re right, nothing is free, but the cost of entry and achieving the things you enumerate is far lower with open source than with the “leading brand”.
Hi Paul…good to hear from you. I would say that we are both biased towards our positions here
That would be great if that was my experience with open source.
Whatever you contribute to open source, you should plan on having to “own” and maintain that forever.
The majority of RFP’s require COTS software. There is a reason for this…and it’s reliability and the expected support and continued velocity into the development of the software. COTS vendors also have the capability to greatly reduce the eventual cost by collecting requirerments and developing features into the core COTS software cost rather than requiring the development cost to satisfy the customer needs. I’m sure you’ve run into that scenario before.
100K and one year to get what you want and then the continuous support of that feature for life??? Sticker shock!!
As stated above, consultants love open source because of job security once clients vest into it
I would say these things are a matter of scale Shawn. If you’re dealing with smallish IT budgets, then making sure an open source project meets your needs on an “as is” basis would be a good pre-condition (of course, same pre-condition applies to proprietary).
Once you are dealing with installations where your maintenance is exceeding $100K a year, you should be looking extremely seriously at the open source alternatives, because have the opportunity to have a great deal more control over your infrastructure and responsiveness for core problems using a dedicated in-house resource. This is what Affilias did when they chose PostgreSQL to run the .org domain registry, they hired two developers. This is why Google runs on either in-house or open source software — when your business depends on software, you can’t afford to be limited by your vendors constraints, schedule or priorities.
The kinds of business demands that Affilias or Google have don’t apply to everyone. But it doesn’t take much to run up a $500K bill for Oracle, and that kind of money can buy a lot of ad hoc open source consulting and support over a lot of years. There are no panaceas.
I’ll echo Chris in saying that merely talking about possibilities of different “stacks” is progress since it promotes the idea that there is more than one way to skin the geospatial cat. Add in Dave Bouwman’s post on hybrid approaches and I’d say the case for open standards and interoperability is fairly strong in our little corner of the IT universe.
And we consultants will always have our annoying lingo–it’s part of the job description.
Brian Timoney
I had pretty much the same stack to begin with (Oracle/ArcSDE/JBoss/Tomcat) a few months ago. Choosing the right stack is all about understanding what GIS and IT capabilities are needed, both present and future. It’s exciting to start a new project where the architecture is wide open. To say that a stack could be picked in a week to me is an aggressive time frame, unless its a smaller implementation. I could tell you what stack I ended up with, but it really wouldn’t help because there are so many factors involved.
We have put some analysis into the problem of which stack to go with so it isn’t like we’ll be pulling it out of a hat. This is the go time though where we have to make our final decision.
The PCness of software agnosticism feels sooooo right. But, really, whose brain can wrap around every solution at an expert level? At three or more stacks your skills dilute and so does your value to clients. Be an expert at one, deeply know another, and be aware of the alternatives. Do the right thing – either convince your client on the technology you know (there’s a reason you love it so much / spent so much time building a career on it) or refer them to someone who is an expert on the technology they require.
That is why I rely on my networking to get people to fill “stacks” that are outside my expertise. I can’t do everything, so when the ESRI Flex API comes up with a client, I am able to put a team together to deliver a project to them that meets their requirements.
[...] just keep what works and replace what isn’t. OpenGeo has a nice roadmap to follow. I talked a little last month or so about geostacks and I like the idea of plugging different things in depending on [...]