Mobilizing Existing Application Architecture

When we say mobilizing existing enterprise applications, we just don’t talk about creating a mobile client that connects or communicates with the back-end enterprise systems for data. But often requires modifying and/or extending the existing enterprise application architecture with many components working together to support multiple platform devices.

Following high level architecture represents the logical view and can be used as reference architecture in extending the design of the existing architecture to a mobile based application for the enterprise world.




Enterprise System Tier:

Enterprise System Tier may constitutes the existing enterprise applications. Many flavors of enterprise applications such as Content Management Systems (CMS), Customer Relation Management (CRM), Enterprise Resource Planning (ERP), Business Intelligence (BI), Web Enterprise Architectures exists today that can be extended to mobile devices.

Web enterprise applications within itself may follow a three or N tier architecture (presentation tier, application tier, database tier) with one or more layers (presentation layer, business layer, data access layer) within each tier.

Middle Tier:

Middle Tier constitutes the middleware that integrates the client application to the EIS tier. As most of the enterprise application architecture does not directly work with or run on devices, there comes the need for a middleware (mobile middleware) that makes the enterprise application data to be accessed by the mobile devices. They serve as an abstraction layer between the mobile device and the enterprise application.

They are typically services/web services (may be restful web services) or can have its own service oriented architecture (SOA) and also contain mobile templates that can be used to extend the enterprise applications like CMS, CRM, BI, and ERP with the data transformed/rendered into the mobile interface. They contain the content adapters, framework wrappers, content processor/transformers that connects the enterprise data and the mobile application.

For Web based enterprise applications, we can actually enhance the existing architecture within its abstraction layer to support data sharing to mobile devices instead of this separate middle tier.

Client Tier:

Client Tier constitutes the actual mobile client applications and the run times. They are typically the software or programs that run on the mobile devices. The client tier itself may have either no layers or one to three layers of application code based on the platform needs of the mobile application.
There are three client application architecture options that can be chosen based on requirements and other factors.

There are three client application architecture options that can be chosen based on requirements and other factors.

Thin Client Application Architecture:

This architecture can be chosen when we have to do deal with developing online applications. It is useful in situation where connectivity is guaranteed. Here the client software/program is normally the browser and has no custom application code and relies completely on the enterprise systems for data.

• Typically has no custom application code


• Cannot operate independently from server as it completely relies on server for functionality


• No dependency on the mobile OS and typically use web/wap browser to display HTML, XML and WML contents

Pros:

• Easy to maintain/support since there are no application code or data on client side


• No distribution mechanism or application code release needed for any kind of enhancements as the application business logic resides on the server

Cons:

• Always should be in online mode wherein to have constant communication with the server. So mobile application will not work without connectivity.

Thick/Fat Client Application Architecture:

This architecture can be chosen when we have to deal with developing offline applications. It is useful in situation where connectivity is not guaranteed. Here the client software/program is installed locally to the device that holds all required data either completely independent of any servers or for most duration and synchronizes data with server at a pre-configured time period or at the end of day whenever connectivity resumes.

• Typically have one to three layers of custom application code. So native application has to be developed that depends on the mobile OS.
• Can operate independently from server either completely or for certain period of time

Pros:

• Application will work even there is limited connectivity or no connectivity

Cons:

• Distribution mechanism or application code release can be difficult as it heavily depends on the mobile OS
• If we have multi-versions of the application, it would be difficult to maintain or provide support for all versions

Interactive/Smart Client Application Architecture:

This architecture can be chosen when we have to deal with developing occasionally connected application. It is useful in situations where connectivity bandwidth is not used all times but whenever required. Here the client software/program is installed locally to the device like fat client, but the application can update or refresh data anytime as against any pre-configured time even though the connectivity is on. That is, synchronizes data with server on need basis only when required.

• Typically have one to three layers of custom application code. So native application has to be developed that depends on the mobile OS

Pros:

• Application will work even there is limited connectivity or no connectivity but the difference here as compared with fat client architecture is that data synchronization happens on need basis when required or whenever there is a update on data is available

Cons:

• Distribution mechanism or application code release can be difficult as it heavily depends on the mobile OS but comparatively easier as against fat client models as we can control on what needs to be coded on server and what on client.
• If we have multi-versions of the application, it would be difficult to maintain or provide support for all versions

Design Considerations:

As most of the enterprise web architectures currently available were implemented long before even mobile applications existed or were considered, the need to accommodate the extension of enterprise application to the mobile has the following considerations while design an architecture

• Connectivity Type: Mobile devices can operate on three connection modes namely 1: Always Connected, 2: Partially Connected & 3: Never Connected. This will play a key role in defining the architecture as only based on this factor; we will have to decide on how the mobile client application would be out of the three thin, fat and smart client models. This affects the way in which data is synchronized between the enterprise app and the mobile client.


• Data Synchronization: As described above, data synchronization between the mobile client app and the enterprise app plays a key role as well in defining the architecture. It is achieved in either of two ways.
  

1. Continuous Synchronous/Asynchronous Communication: Data synchronization between the mobile client and server is continuous where in case of synchronous communication, all data is completely stored before server acknowledges the receipt of data and in case of asynchronous communication, all data need not be completely stored before the server acknowledges the client (ie., server acknowledges immediately when the request comes to it and later carries the store request)
   
2. Store-and-Forward Communication: Whenever there is no connectivity, data gets stored within the mobile client local data store and then upon connectivity, data synchronization takes place between mobile client and server. In case of the data retrieval from server, the server uses push-to-messaging to push notifications/messages from the server to the client whenever client is online and rest of the time uses the local data during offline.
   

• Abstraction Level: Level of Abstraction of existing application should be considered before an architecture solution is achieved. If there is a clear separation of presentation, business, and data access logic, then it would be easier to mobilize the application as reuse of the existing business and data access components is possible as compared against the writing lot of code/work if the existing application is not well-abstracted.

• Application Version: Modified version of the application or new application should also be considered while defining a mobile architecture. If we go with a fat/smart client based architecture, then the mobile application we develop will be a scale-down version of the actual server application as some part of the server logic will be developed within the mobile application.


• Location Based Content: Location based content delivery provides targeted content such as advertisements, information, maps, news to devices based on current physical location. So while defining a architecture, gather information on or clearly separate the different contents that are generic and location based.