In this third post of my blog series about Design Considerations When Building Cross Platform Applications, I’m focusing on one of the most complex areas of design: Application Architecture. When a company or developer sets out to create a new application, whether mobile, desktop or web, many approaches can be taken to get things moving. More often than not, developers have a tendency to overlook the long-term goals and expectations of the application and wind up “painting themselves into a corner.” At SuperConnect, our technical leaders have been tasked with the challenge of being able to build applications that will run on almost all imaginable platforms: Android, iOS, mobile web browsers, etc. Additionally, we have had to deal with aspects of architectural design that is not usually faced by development teams when building for a single enterprise: customization and brand-ability of each enterprise’s subscribed version of our applications. The area of customization is invisible from the cosmetic design of the application and the end user’s experience. The real challenge sits on the back end of the systems that drive our applications.
When our architects began to design for a myriad of products for many different enterprise needs on nearly all possible platforms, it was easy to think that a “build it once, deploy it anywhere” approach might suit us best. While I have done research on many of those platforms and even implemented a couple of them (on small scale projects), they too provide their own challenges. Whether it is a Mobile Enterprise Application Platform (MEAP) like PhoneGap, MonoTouch or Appcellerator or a mobile web solution based in HTML5, the challenges seem to remain the same: the user interaction and design are still handled in many different ways behind the scenes unless the same exact application design is applied to all platforms. Developers still need to be able to handle the nuisances of each native device while developing in a single development environment (IDE). I do agree that being able to use that single IDE and programming language does provide some benefit, but in my opinion nearly every good-to-great developer that I have worked with can work in many different IDEs and with many languages. The single codebase that it provides is another positive, but under the covers, it winds up being a mess of “spaghetti code” due to different branches for the various targeted platforms within the same codebase. In the end, we chose to go native for our Connections application because we wanted a user to get a native feel on each device. I believe strongly that the majority of the work of the application should be done on the back end, and that decisions must be made to try and minimize the amount of logic that has to be re-invented on each platform. I like to follow a model where the majority of the “work,” approximately 70%, should be performed on the servers, 15% should be similar across platforms (e.g. writing queries, database schemas, etc.), and the last 15% should be truly native to provide the user with an experience that is expected on his/her particular device.
In addition to the need to handle cross-platform applications, our requirements were complicated by the additional need to provide a customer with the ability to customize the user’s experience within the features we provide in our application. Specifically, a customer is able to customize logos and colors throughout the application to make it feel like an enterprise solution that was created for their specific company. All of this metadata is handled on the server and sent to the devices to tell the applications how to skin the user’s experience. One example of how quickly this can be changed is shown in the images below where our designers came up with a themed design that was applied by simply changing the logo and a couple of colors in our admin panel for the Slalom LLC instance of Connections.
|Standard Theme||Halloween Theme|
The customer also has the ability to tailor the application to meet the data requirements of the organization. Based on our experience working with companies in different industries on the consulting side, we knew that the data stored and maintained for each company will vary based on the specific needs of the business. For instance, in the case of a consulting company like Slalom Consulting, the data the end user may want to see is very different (e.g. clients, colleges, projects, etc.) than a construction or labor organization where the user may be more interested in a contact’s specialties or recent certifications. We have designed our application backend using Microsoft Azure to provide a flexible interface for an administrator to customize how the data is pushed from a customer’s environment into the SuperConnect Software-as-a-Service (SaaS) platform for delivery and consumption within our mobile applications. (Note: In my next entry, I will detail out more information about how we are able to move data from our customer’s environment to the SuperConnect platform to the mobile applications.) Our service layer provides the devices with the metadata about how to display the data on the device as well as what actions can be taken on such data items. For example, in the case of the Slalom Consulting example, a consultant may have several contact methods available on their contact profile within Connections. The administrator can specify how these data fields can be handled on the device by informing the application (via metadata) if the data field is one that can be mapped, called, texted, emailed, etc. The application can use the metadata to take the appropriate action in a native-manner to utilize a streamlined user experience.
Overall, our application’s design strength lies in the application architecture by the way we have set up our back end service and data layers to handle the requirements of the applications and our customers. We have tried to push any complicated business logic off of the devices and back up to the service layer to keep our systems flexible in case these areas need to change. One of our most-used features within Connections, a calendar and scheduling component, is driven fully by backend services and logic with the applications simply showing the user that he/she can take action. This logic has evolved through several revisions since we have been in BETA and none of the end users have ever noticed a change. Lastly, we have utilized this same area to manage our security (authentication / authorization) in a way where we can make changes to our security methodology without changing our applications. With the ever-changing world of application security, this provides us with a way to grow as the security requirements of our customers change.
Stay tuned for my next post on Design Considerations, where I’ll speak to data flow and volume.