In 1985, I was a junior in high school and I got my first job at a local chain steakhouse. I ended up staying there for a few years and did everything, including management. This particular location happened to be the busiest store in the chain, which had a couple hundred locations at the time. Basically, we just unlocked the doors and people came in. We often had a line and managers from all over the country came to see how we did business.
Eventually, I transferred to another store that happened to be much slower. I expected this to be a something of a cakewalk compared to the store I had just left. Sometime during my first day, the long-time manager made a point to remind me to close the back dining room after lunch and turn the lights out. The dark room looked uninviting to me so I asked if we could leave the lights on. He replied that doing so would raise the electric bill and affect the store’s profits. Over the next few weeks, I learned so many new techniques for managing food inventory, staffing levels, and equipment that I realized my initial impression was wrong. So I told the manager this. He was not surprised.
He said to me: “It takes more skill to run a slow store than a busy one.”
He was absolutely right. At the first location, we would simply order enough food to fill the walk-ins and did enough prep every day to fill the racks. We quickly ramped our staffing up to max levels every day and just waited for the customers to roll in. There was a myriad of issues we simply never had to worry about because sales volume masked them.
It’s been many years since I’ve had to work in a restaurant but I have found this observation applicable throughout my career, during which I have worked primarily in the defense industry, designing and building various forms of geospatial tools and systems. Two weeks ago, I attended the Esri International User Conference. The Esri UC is full of opportunities to see more of these types of applications, from the Defense Showcase to the National Security Summit to many defense/intel/homeland security related paper sessions.
I attended almost none of them.
Over the past few years, I have developed the habit of attending sessions related to local governments, non-profits and other small organizations. These organizations tend to have budgets that are essentially rounding error in the defense world and I have become much more intrigued by the solutions they build to meet their missions with so few resources.
Of course, I was at an Esri conference, so everyone I saw was an Esri user. It’s no secret that Esri tools tend to be expensive and every dollar counts for small governments, so I am intrigued how these organizations arrive at the choice of Esri tools in light of so many other capable options. Too often, there is a misconception that these small governments simply choose Esri-based solutions out of a lack of understanding of alternatives. What I have discovered is, like the manager of the slow restaurant, some of the best business understanding and most cogent and well-reasoned justifications come from these small users.
They seem to take a much more holistic approach to evaluating their solutions; including the availability of support from the technology provider as well as the existence of a robust third-party community that enables them to effectively compete for value-added services, customizations, and consulting. What I found interesting has been the most consistent attraction of local governments and small organizations to Esri-based solutions: the seamless integration of the entire ArcGIS platform. From mobile to desktop to web, they find that Esri tools make it easier to move through the product lifecycle. This exposes a very business-centric way of thinking that is larger than any individual technology or its licensing cost.
As I indicated above, an Esri conference places a huge filter on the users whom you meet. As I attend less vendor-centric events in the months ahead, I’d like to continue this line of inquiry. While landing the giant white whales of large Federal agencies might be more satisfying for the short-term bottom line, it is important to remember that all levels of government are facing downward budget pressure. Learning the thought processes of organizations that have always had to tightly manage limited resources may be more valuable in the long run.
As alway Bill, interesting viewpoints. First thought, as a current poor local gov worker, I too always found interest in poorer entities, to see how they found a simpler solution to usually the same problem. One observation, while trickle down economics is debatable, “trickle down taxes” clearly is. In which locals get pass though money for ‘GIS’ from the top down but probably because of human nature “chooses” the same GIS practices as the funding source. Even if choices are available, but that could be as easy said for GeoMedia (assessors or revenue offices) as ESRI; they choose the same as money tree. But this is probably just one of many unexplainable factors. Chris
ps. it not to late to sign up for FOSS4G in PDX or sponsorship…
Thanks, Chris. Good points. I have FOSS4G written in pencil at this point. Autumn is an exceedingly difficult time for me to get away so I probably won’t decide until the last minute.
Excuse not valid. Try harder or BE THERE buddy
I have a brain cloud?
NOPE – NA is the result of your operation. Please submit your excuse in Portland at FOSS4G
I’ve long figured that if I were ever dropped into a county office and told “ok, now you’re the GIS manager, here’s your two staff” the only reasonable thing to do would be to Esri it up. Yet if I were dropped into a state GIS office, with more specialized IT staff and capabilities, I would tend to go a more open source route. I think the fit-and-finish of the Esri stack is both a curse and a blessing. The blessing is the fit and finish. The curse is the difficulty in repurposing it to unexpected ends, and running it at scale.
I don’t believe you can say: it works and is cheap and effective at the low end, therefore if we multiply 100, we’ll reap all these savings.
I once got to see how Ford Motor Company builds their maintenance manuals: it’s not with Microsoft Word. It’s SGML files and automatic publication pipelines and multiple output paths (paper, online, tablet, etc) and automation everywhere. You wouldn’t write a cookbook this way. But you would publish an annual collection of 100 manuals with ongoing errata.
Hi Paul,
I agree that practices that are effective in smaller settings don’t always (or rarely) scale linearly. That’s why we automate repetitive tasks and seek more efficient algorithms and the like. Your Ford example is an excellent case. I am also with you that Esri falls over at anything approaching scale. I think there are a number of reasons why open source is more suitable in these cases.
I’m going to leave it there for now. As I said, I know I was working with a skewed sample and I’d like to push down this path a little more. It’s something that has interested me for a long time and I’d like to see where it leads.
Thank you for taking the time to comment. I always appreciate your thoughts and hope we can cross paths soon.
Bill