Innovation: Creating a New Pattern

© ExcelsisDeo

When faced with an opportunity, applying commonly used patterns often creates an effective solution. Sometimes inherent inefficiencies limit effective solutions from being optimal. Enter innovation. Innovation creates a new pattern and applies it to an opportunity. When the new pattern beats the old ones, embrace it. When it does not, discard it. Just don’t avoid it. Only with new, innovative ideas do technological revolutions occur.

We applied that philosophy to enabling mobile access to our systems. Three common patterns exist in the mobile app development world: ignore it, build everything from scratch, or use a code generator to assemble and generate it. Each of these contains flaws or inefficiencies. Ignoring the mobile app world creates a risk to the business as customers look to competitors who better meet their needs. Building everything from scratch requires an army of developers trained in the various mobile technologies. This duplicates the amount of effort needed. Consolidating the effort within a shared team alleviates some of the duplication. Doing so may also cause a slowed response as projects compete for resources. Finally, most code generators require the adoption of a full ecosystem and teams trained to use and support that ecosystem. While code generators reduce the effort to build apps, they fail to reduce the duplication of effort.

Instead, we approached the opportunity by looking for a way to isolate the system teams from having to learn much about the mobile environment. We set data and actions available to the data as the foundation. We are creating an app containing a mobile suite of components that adapt to data and actions associated with that data. So when the app receives the data, it routes the data to the appropriate type of presentation which adapts to the data along with the actions available. The system teams focus on the data that they want exposed and the actions available on that data instead of on the details of the mobile environment and its usage paradigm. Since the components adapt to data and actions on the data, additional functionality and systems may be exposed without duplicating the development effort on the mobile client.

For example, let’s assume we have a system that wants to expose customers. To do so, it creates a service that returns a set of customers and specifies a general presentation type such as a list. In addition, the data also contains actions that are available for the customers such as updating, adding, or removing them. When the app receives the data, it routes the data to a list presentation type. The list presentation type adapts to the customer data and presents it. It also adapts to the actions available on the customers and presents options to the user to perform the actions. The actions tie back into the system by way of additional service calls. Now let’s say that the system wants to add the ability to expose the orders placed by the customers. The system team creates the order request service that returns the order data along with its available actions. Then, they add an order request action to the service that returns the customer data. Now when the customer data is sent to the mobile app, the app presents the list along with new action to request the orders. When the user selects the new action, the app makes the service request and routes the order data to the appropriate presentation type. That presentation type adapts to the order data and the actions available to it.

This level of abstraction allows for app components to be upgraded, new ones added, and even new platforms for additional types of devices to be deployed without the systems having to make adjustments. In addition, systems can quickly expose new or modified functionality without being concerned about mobile app development and deployment.

Article by: 

Tim Hundt – Senior Architect for Capital Enterprise Architecture Team / Mobile COE