When building apps these days, there are a number of well-known and reality-proven guides to follow. Amongst other aspects, one of the most important is to keep the app as focused as possible. Why focusing? Focusing on something helps to differentiate the important things from the not so important ones. It helps to ensure that you build exactly what is required and avoid building everything that is possible, so the app is presented in its most useful and usable form. That is what makes apps apps, and not large applications. But focusing on what? We build apps for a purpose (or at least we should), and this purpose can be of many kinds. In a professional context, the purpose is normally to solve a concrete problem, whereby the app provides a problem/solution fit. An app that has a specific, focused purpose can be optimized in many aspects: tools, content, device support, means of interaction, etc., etc. That leads to simple, easy to use, non-generic but very concrete little apps.
Figure 1: Single-purpose apps to provide an optimized problem/solution fit
Now let’s think about how the world works, in enterprises specifically. Doesn't the concept of focused, simple and easy to use app's fit in this world anyways? They do! Why shouldn't an approach that has proven to be very valid and successful in the consumer world not also work in the enterprise? The people that are sitting in front and using the stuff to fulfill their purpose are the same, they have a professional and a private life. They don't change their expectations and preferences just because they are sitting behind a work desk and not at home on the sofa.
There is a value in building enterprise solutions following the notion of single-purpose apps. The point is that enterprise solutions tend to try to cover a lot of purposes. Building a single app for every purpose will lead to many apps. If you mix-and-match technologies, frameworks, products, solutions, etc. you might even find yourself in a zoo of apps that will than become your enterprise solution. A nightmare to create, extend, maintain, operate, update and finance. When building the product map.apps, we were challenged with this from the beginning, as we have many customers in private enterprises and government that tend to have large solutions. We have taken some means to allow them to develop multi-purpose solution apps for enterprises. By taking the example of the favorite places solution we did build for the Esri user conference 2014, a few of them will be explained briefly in the following paragraphs.
The goal of the solution is to let the public gather favorite places and spots in and around San Diego, the city where the annual Esri user conference takes place, and share them with others. This is a sample, a demo we had to build in very short time. So it is far from perfect, but it can stand as a place holder for "real" solutions, because even this rather simple solution has some variety in terms of aspects:
- three purposes: submit new places, crawl through existing places, approve and manage places
- two user types: public users and authorized editors
- two runtime contexts: a whole lot of touch enabled, mobile devices and the desktop with mouse, keyboard and stuff
There are only slight differentiations in terms in content related to purposes: approve & manage places works on all places, approved and unapproved whereas only approved ones should be used in the crawling. Also approve and manage includes the ability to edit places if required. Therefore this purpose also benefits from additional basemaps like aerial imagery. Summing up, we decided to come up with a 2-app solution:
- an app for the public, to allow them to submit new places and crawl through existing and approved places; these app needs to work very well on mobile (that’s where it is used, on site) with touch in particular but should also work on desktop browsers. Figure 1 shows this "San Diego Favorites" app.
- an additional app for authorized editors to check, approve and manage reported places; these app is normally used from the working desk and requires mouse support for the spatial editing stuff; therefor it needs to be optimized for desktop browsers, mouse and keyboard interaction. For manually reported places the app also needs to allow for creation of new places and crawling through existing ones. Figure 2 shows this "Favorites admin" app.
Both have enough differences to justify the split but also enough commonalities to not justify two separate implementations. Also, both need to be maintained and upgraded over time to works with new versions of the base technologies, maybe get content updates or functionality enhancements.
Figure 2: "San Diego Favorites" app
Figure 3: "Favorites admin" app
With map.apps you can use a single web app installation. This installation handles the complete app runtime & operation infrastructure and it offers fine grained building blocks that you can use to compose apps. In map.apps, single apps get downsized to be just configurations of building blocks, called bundles. Everything is a bundle, including layouts, contents, functions, etc. Instead of implementing two separate apps, just the missing blocks had to be build. Functionality-wise everything is covered by the core product bundles. Just the two layouts had to be implemented, not from scratch but as customizations from the existing ones. The responsive rule engine in map.apps (part of the app runtime infrastructure services) allow the flexibility to arrange optimal for landscape/portrait mode on mobile. Bundles to search, find and display had to be taken and configured plus a purpose optimized version of create-new, drilled down to cover specific types and a specific input dataform only and offered as "add a new place". Whereas the "favorites admin" app is a simple layout using the standard functionalities to create/update/delete places, an extended dataform (including an "is approved" switch) and security enabled (authentication and authorization is offered also as part of the app runtime infrastructure services). Both apps use the same data source: an ArcGIS Server powered FeatureServices for the places and ArcGIS Online powered basemaps. Both are configured in the same way. As all non-authorized users should only be able to access approved places, a security filter powered by security.mananger was applied on top of the ArcGIS Server FeatureServer. All un-authorized access will have returned features limited by a filter that checks for the "is approved" flag.
That’s it, done. The following figure shows the setup. Just one single web app installed, two app configurations applied, very tiny bundles added to fill the gap, one common database and access service with a security filter applied.
Figure 4: Solution Architecture
This approach and technical framework has proven its durability and fitness to build even large enterprise solutions as a series of interconnected apps and as such deliver three major benefits: easy to use app's, easy to maintain and operate IT infrastructure and a way to deliver new functionality (or new problem-solvers) in fast time-to-market cycles at a low investment/risk level. It allows you to migrate existing large scale systems to a single, unified solution that can be stepwise implemented and extended by focusing the investments and other efforts on creating little building blocks and sharing/reusing them in the app's all along the complete solution. What in case of updates? With this setup, it is only required to update bundles once. No matter in how many apps they are used. How about incompatibilities, dependencies internally and to external libraries and APIs? The app infrastructure can handle dependencies between bundles and to external APIs automatically. A bundle repository allows the use of different versions of bundles, APIs and libraries in parallel, etc. All that is doable through a web management interface and fully cloud ready.