Mobile Architectures

Enterprise applications follow certain architecture guidelines to deliver the business needs on functionality, TCO and ROI. To achieve this, trade offs made often tend to sacrifice asynchrony and flexibility in favour of assembly-lining of processes to deliver maximum bang for the buck spent and IT security. Large enterprise applications work on the philosophy of FTR ( getting things first time right). Efficiency, effectiveness and cost-control are derived from FTR theme. Any incremental and/or dramatic changes to the systems are mellowed down against the need to keep things familiar, avoid employees going thru a learning curve. Hence most changes are never dramatic, on a floor shop where most processes are simplified and assembly-lined. The pressure to avoid drastic changes is high in order to keep re-learning cycles low (to realize efficiencies from changes faster and at lower cost). In such environments, you would find IT systems architected in a fabric of synchrony when it comes to processes and events. In such environments you will find human resources avoiding the complexity of multi-tasking on mutually exclusive process threads.

Architectures for mobile apps need to deliver on different goals. These goals being asynchrony, multi-tasking and usability. Events arranged in a tight sequence will not work in the real world as the real world is a very different place when compared to the controlled environment of back-office and enterprise shop floors. This is true for sales processes as well. If you really look at the retail sales processes and the events as they unfold on the ground, they are seldom in tandem with the way the processes in the systems have sequenced events, implemented controls and designed the processes. This is one of the many reasons for change requests budgets and exceptions being sought for on mandated process. This is one of the reasons why systems have the facility to request for exceptions and an approval authority workflow for their approval.

When I look at some of the mobile apps from the enterprise that are either customer facing or sales force facing, I have found these apps tightly stitched from an enterprise operations viewpoint, backend to the front. While in reality the mobile app needs to be de-linked from the enterprise backend to avoid the trap of synchrony and the trap of irrelevance between sequence of event play-out in the real world (there are no fixed sequences here) and the fixed sequence of processes manifested thru screens and logic on enterprise applications. How often have people got into BPR exercise initiated as and when these gaps are experienced at a medium to high frequency.

Cloud plays a big role in delivering asynchrony and de-linking from backend to keep the app behaviour relevant to the way events play out in the real world. Windows Azure Mobile services provides some fantastic platforms on the cloud to make this happen.

As an approach the mobile developers should focus on usability and architect the app to handle each fundamental unit event in entirety without stitching the code to create dependency on another event's initiation and/ or closure. Enterprise IT need to provide for multiple entry points for data from mobile apps into  processes on the backend systems, without imposing the synchrony that is inherently built into the backend systems. For those who believe that this is an expensive change to make on the backend, it could be and again it may not, if one leverages the cloud queues and service bus to hold the data till all the pieces fall in place for a backend process to consume the data. This will require constant polling from enterprise network to the cloud / a mechanism for the cloud to let the enterprise network know that data is ready to be consumed.

The mobile app, writes to the cloud. Depending on the need, this could be a table (no-sql table) , cache, queue or a service bus. Build the processing logic on the cloud and not on the mobile app itself. On the cloud you would have two roles. A web role, typically the web app executes in a web role and a worker role which typically are cloud resources such as cache, queues and tables which the web app uses. The mobile app is stitched for usability to cater to various events as they play out in the real world. The processing happens on the cloud. The backend systems consume the data to process and give an output back to the cloud. The mobile app takes this output from the cloud to display on the mobile screen and wait for consumers next request, rather than initiating the next sequence for the consumer.

In the traditional development approach, a developer would sit down to create table structures and database schemas , normalise the database design, design screens, write processing logic to read and write data, logic for integration points with the enterprise database and so on. In the new normal, the developer will just focus on UI design, use Azure no-sql tables to store data. The Azure tables, create the structure depending on incoming data. The processing logic is held on the cloud as a web app in a web role. Session data persistence is managed by azure cache. If one needs to capture images or videos ( surveyor capturing data for car insurance claim processing), this can be held on the cloud CDN. Interaction with enterprise systems (for synchronous processing) can happen thru the service bus on a publish/subscribe model.

For example while shopping in a real world brick and mortar store, as I see what I like, I could take my mobile out, invoke the store's mobile app, read the bar code off the merchandise on display, attach credit card from my m-wallet and leave a delivery address and walk out. While different stores will have their own respective mobile apps, the bank could just publish a web app on the cloud, cloud storage (no-sql table) to which different apps could write credit card data, create three different themes on the service bus :

- Shopping Item theme

- Payment Approval Theme

- Item delivery theme

..and publish/subscribe to these themes depending on the context of the transaction. The store app would publish item details and price to the first theme, the bank could subscribe to it for it's records. The bank would publish credit card authorization decision to the service bus , to which apps could subscribe to. As the item is delivered to the customer, the enterprise apps of the stores could publish these details for the bank's systems to subscribe (in case there is a dispute later). The enterprise systems could have web services for interaction with the service bus on the cloud and the web app on the cloud.

Its clear from my above explanation that the app developer can create magic while being completely ignorant of the underlying enterprise systems that come into play. The developer need not worry about database design and structure and can focus only on UI and logic. The enterprise IT teams re-use the existing processing and business logic on the system by directing the data from the cloud into the right systems thru a SOA layer, they build and manage. Welcome to the new normal.

written for: