Should I get a specialist to build my ArcGIS Enterprise?
I remember building my first ArcIMS implementation back in about 2006. The setting up of Tomcat was challenging, but eventually, I got it to work, and it did well. Then, ArcGIS Server (9.2) came along, and I implemented that in about 2007. At the time, I was working in Central Government in the UK. I didn’t know this, but those applications were typically installed under a professional services engagement and not by the customers. I was a developer at the time, techy, and with a can-do attitude. Everything was HTTP, intranet-based, not many users, and anything that looked like web services was a good thing. My boss was happy!
Since then, my career has specialised in the server-side components of Esri. However, it often feels that I get called in when things have gone wrong! In previous workplaces, I would often hear, “Scott, we’re just going to helicopter you in to sort this out..” (Disclaimer: Helicopters were figurative, and I wasn’t afforded that luxury.)
So would I encourage people to install ArcGIS Enterprise themselves? Yes, give it a go. However, if you plan on it lasting for years to come, then you’re probably going to be frustrated in the not too distant future.
There are many consultants out there who are fantastic with all things Esri, but they’re not specialists in this area. So will you get the best solution from them? The Esri partner community in NZ talks, and we share about technology and opportunities. I have worked with one such partner over the last couple of years. In that time, we have both distilled our service offerings down to our specialisms. When I’m engaged with a client, I want the best for them. If I’m not the best and there’s an alignment with partners’ specialisms, I introduce the client. Equally, my partner has done the same or sub-contracted me to support them.
Having a specialist in their field means that all of their experience is brought to bear for your project. So, for example, you could implement ArcGIS Enterprise, and a particular function doesn’t work. I’ve seen customers spend days trying to resolve it, and very often, there’s a quick solution. The root cause is sometimes related to your IaaS/Cloud rather than Esri itself.
Frankly, ArcGIS Server (as a component of ArcGIS Enterprise) has never been hard to install. Making that implementation secure and gett the best performance from it as a whole different matter, however. The performance aspects can be taught, which I typically do in each new client engagement. It’s a part of the geoworx mentoring philosophy.
Unfortunately, there has been a common tendency to say my ArcGIS Server supports everything, so I’ll use it for everything. As a result, I’ve seen ArcGIS Servers with map services, hosted feature services, image services, geocoding services, and geoprocessing services. I’ve even seen someone throw GeoEvent on there as well. Each type of service is like a different toolkit. Hosted feature services are lightweight and only need a tack hammer to drive them through. Image Services are much heavier in terms of computation and need a sledgehammer to make them move through the system. Ultimately we don’t smash concrete with a tack hammer, and we don’t put picture hooks up with a sledgehammer. We should choose the right tool for the job.
The most common non-functional requirement I see is “My maps must be as fast as Google Maps, i.e. sub-second”. What they’re saying translates to “we want our ArcGIS Server to be a Ferrari”. Most customers don’t have a Ferrari budget, however! If we imagine that we’ve just bought a lifestyle block and we’ve got some money to spend on vehicles (yeah, right), then would you buy a Ferrari? Can a Ferrari:
· Go over rough terrain?
· Carry hay bales and fencing posts?
· Pull farm machinery?
No? If you’re going to throw all of these different tasks on it, you need to compromise. Choosing a single vehicle is the wrong choice. Instead, we may need a Ute, a quad-bike, and a runaround for the family. None of them is as fast as a Ferrari, but we can cover more bases. It’s a compromise. The runaround will go pretty quickly on the road, but as soon as you throw some boggy ground in the mix, then the 4X4 or Quad Bike will get the job done.
If you’re using an ArcGIS Server for Hosted Feature Services, it’s like being on a straight urban motorway. As soon as you start adding map services, you start throwing some curves at it, and it slows down a little. Some more power will help you pull out of those curves. Add a print service into the mix or a long-running geoprocessing service, and it’s like hitting a traffic jam!
I guess what I’m trying to say here is that we choose a hammer or a car to meet a particular. We don’t just have one hammer in our toolbox, or as a farmer, have one vehicle to do it all. So designing your ArcGIS Enterprise upfront is an excellent choice to ensure you’ll get the best from it.
Another way of looking at this is the analogy of building some flat-pack shelves. Again, if you follow the instructions, you’ll get something that looks like the catalogue picture. However, many bits do you get leftover at the end of the process? That usually means it’s weaker than it should be and won’t last as long. However, if you get someone experienced to do the job, they’ll know the areas that are likely to be weak. So they’ll add some extra thought and strengthen that build. That’s literally what geoworx is all about.
Securing an ArcGIS Server is a whole different ball game. How many GIS allrounders know how to prepare your ArcGIS platform to get through a penetration test or a Certification and Accreditation review? Is it fair to ask your Senior Analyst to deploy ArcGIS Enterprise and get it right on their first attempt?
In the preceding discussion, I’ve been specific to talk about ArcGIS Server and not ArcGIS Enterprise. A standalone ArcGIS Server uses two software components. An ArcGIS Enterprise is a minimum of five software installs. They are all independent of each other and have to be configured to work together. If you follow Esri’s installation instructions, you’ll get it to work. However, with no disrespect to Esri, the instructions are a bit light. They cannot cover every deployment scenario. They’re a great reference point, but there are many detailed options, and it’s not clear which to choose or the downstream impact of making that particular choice.
Having implemented many ArcGIS Enterprise solutions, I’ve learnt a lot. One of the things I learnt quickly is to work with your IT team. Something often commented upon is my ability to create a bridge from the GIS team to the IT team and act as the glue in the middle to make your GIS work in your IT environment. Sitting in that gap means I can learn about your wider IT Enterprise environment, tune your deployment to what is available, discuss limitations and offer solutions.
I appreciate that having a specialist involved isn’t cheap, but I try to be economical. Project managers talk about the project triangle (cost, quality, and time), where you can only pick two. If you want quality and to save time, then speaking to geoworx can be a good choice.
Reaching out and talking about your existing or proposed ArcGIS Enterprise doesn’t cost anything. So what have you got to lose?