After arriving a little late on Day 2 due to needing to push updates to an application we’re building for an NGO, I was able to catch most of the session about deploying ArcGIS Server in the cloud. James was sitting in the front and has already blogged that session so I won’t go into detail about it here. One thing that did jump out at me came during the Q&A, when someone asked about certification and accreditation (C&A) of AWS deployments.
If you work in the Federal space, you know that C&A is a huge issue for the deployment of any information system, regardless of platform, for the Federal Government. Since hosted deployments essentially mean outsourcing your physical infrastructure, information security types have understandably proceeded with caution here.
To be quite frank, C&A is an issue that ESRI has historically treated superficially at best. It has been viewed as something for integrators to work out despite the fact that there are FISMA implications at the platform level as well. I am happy to say that seems to have changed. As I mentioned toward the end of my previous post, ESRI seems to possess a much more mature and holistic understanding of the issues that drive Federal IT acquisition. This was on display here as the ESRI staff running the session provided intelligent answers regarding levels of FISMA compliance as well as the existence/creation of baseline C&A packages that can help jump start DIACAP accreditation. Due to time constraints, they didn’t get into a lot of detail but it was clear there is now a deeper understanding of C&A issues within ESRI.
I also attended the DevGeo segment on ArcGIS Runtime. This technology, which is different than I had expected in many ways, seems to finally plug a gap that has existed in the ESRI platform since the sunsetting of MapObjects. There is once again an easily deployable way to embed ESRI mapping capability into an application. The reality is that there’s still a huge demand for desktop applications out there. Over the last two years, I have personally seen increased demand for various desktop tools as the majority of the development community has moved to the web. The ArcGIS Runtime demo I saw during the session already demonstrates that it can plug a serious performance issue that one of my customers is currently having with an in-vehicle application.
The quick hits that jumped out at me: easy deployment model, lack of COM dependencies, native 64-bit support on Linux and Windows while also retaining 32-bit support on Windows, Linux support, and the ability to safely deploy Runtime applications side-by-side with older versions of ArcGIS. These reasons alone move it ahead of ArcGIS Engine in my consideration of tools to use when developing ESRI-centric applications.
I also attended the session on the HIFLD working group. This was something of a 10-year retrospective on the group that included a series of lightning talks about current efforts across participating agencies. I was in the room for the first meeting back in 2002 and my company continues to support it to this day. Today, it’s primarily noted for for coordinating requirements for HSIP (video link). HSIP does have some issues, fairly accurately portrayed here, but the support team is making a good-faith effort to move to a more collaborative model while also trying to balance the often-competing priorities of the various stakeholders. It’s not been easy and progress has been incremental but it’s been a quiet, if qualified, success story so far in terms of applying GIS to homeland security issues.
After that session, I headed out to the social. By this, I don’t mean the official social at the Air and Space Museum. While this was an ESRI conference, ESRI tools are not the only ones I use. Due to the fact that the Federal GIS Conference draws an increasing number of geospatial users from around the country, an informal gathering has taken place at RFD over the last few years. This gathering typically includes not only conference attendees but also people with other DC-area geospatial companies such as GeoIQ. Some people attend the ESRI event and drop by RFD later. What usually results is a good mix of discussion. I have come to realize that I value these types of gatherings as a way to reconnect with people I don’t get to see often, meet new people, and generally recharge my batteries. This informal gathering gives me a chance to throw a lot of different things into my melting pot and let them stew for a bit. I have come to view it as being almost as valuable as the conference itself.
I didn’t attend the last day because two days out of the office leaves a lot to catch up on. I was happy to catch up with everyone (far too numerous to name here) and look forward to the chance to do so again in the near future. For those who had to travel to DC to attend, I wish you safe travels home.
Sorry to have missed you and others at a RFD, we got there early but left in anticipation of a dinner meeting, which, eventually got cancelled. I hear it was a great time with plenty of geotalk, geobeers and geomusings! That may be the only aspect of next year’s ESRI FedUC I get to enjoy! #winning
Sorry to have missed you at RFD as well, but it was good to catch up at your booth. Hopefully, we can meet up when you’re in the area again. I hope Spatial Networks sees some benefit out of attending this year and there’s always a table for you guys at RFD!
I would love to see vendors getting to the point of security being almost like LEGO blocks. The various sections of security to be addressed in a FISMA-compliant risk management framework deal with controls and items inherited via various pieces that the vendors are responsible for. For example, AWS would be responsible for a number of things dealing with the actual infrastructure, physical security and physical access to servers; some controls would be a function of the OS, whether Linux, Windows et cetera – some would be a function of the software running, i.e. ArcGIS Server – and if vendors got themselves into the mindset of being able to provide those relevant sections and how the appropriate security controls are addressed, it would greatly streamline the process for technology adoption and deployment in federal space.
I agree and I think many vendors are starting to wise up to this. I’m starting to see more of them taking these kinds of activities in-house, rather than leaving them to integrators. It’s a mutually beneficial thing in that the government can benefit from streamlined accreditation and the vendors can benefit from streamlined acquisition. These are issues that, of course, are independent of whether the technology in question is proprietary or open-source. Companies that are building their businesses around supporting open-source tools should probably be looking at these kinds of issues as well.