The realm of applications for business has changed significantly because almost every business objective must now factor in mobile work.

When I first began to develop complex business applications, platform choices were few and conventional wisdom helped to narrow down the possible approaches to data management and integrated services. Back then – and by “then” I mean the technology era prior to functional mobile device availability (~2008) – the requirements for business applications were relatively simple. Today, this is not the case.

Since the advent of useful and powerful mobile devices such as iPad and iPhone, I have seen a sharp increase in the demand for business-centric solutions that are predominantly cloud-based and crafted with lightweight scripting environments such as javascript. These are applications that leverage server infrastructures such as Google Drive and which can be instrumented to provide very effective automation processes and integration with other wed services.

Few people realize that it’s possible to build significant operational processes on a platform that was previously regarded as a woeful and substandard attempt to replace Microsoft Excel. I’m referring to Google Docs of course, considered by most Office users as a distant fourth place finisher in the race to attract millions of very satisfied Excel business users.

But there’s another element of modern business applications that is impacted by mobility; SQL database systems. While SQLite emerge on iOS devices early, advances in connectivity and bandwidth availability has dampened the demand for device-level storage and data manipulation. Business users – by and large – don’t want their data on their devices any more than they want the data on their desktops. And to be clear, the number of devices per business user is growing for many, shrinking for very few of us.

And there’s the case for the new frontier of business apps – information and processes must be freed from the personal-centric devices to live somewhere else.

Enter Mobility

Excel and SQL databases continue to be the go-to applications for managing data if (and only if) the information:

• … doesn’t require collaborative activities between personas that are mobile and stationary
• … doesn’t need to integrate with other processes
• … doesn’t participate in automated processes

Information that aligns with these attributes is unlikely to be mission-critical in the context of a modern application. In my view, these are the attributes of the new definition of legacy data processing. Modern business apps are driven by exactly the opposite of these attributes.

Collaboration, Integration, and Automation

 

A modern business app that embraces mobility and the capacity for operational computing performance in the field, typically recognizes collaboration as central to processing and utilizing critical information artifacts. We tend to get the sense that business applications are creating more distance between users and demands for interpersonal interaction are waning in the face of highly integrated systems. However, the opposite is true if you factor in the increasing opportunities to perform work at a mobile level.

This alone has created wholly new application systems that require new connective tissue between people who previously had no capacity to compute at a work site. A surgeon can access critical patient data from her phone. A rescue team can fully document an accident on site with an iPad Mini. These were never possible until mobile devices matured and connectivity and bandwidth reached a tipping point.

Automation is the glue that connects processes, while collaborative capacity is pathway that enables operational efficiency.

Platform Selection

I’m highly sensitized to the biases that come from knowing specific programming languages or those influenced by conventional wisdom.

In light of the recent advances in modern browsers, mobile application development, and the forthcoming Swift language from Apple, consultants need to be wary of the religious debates that typically sustain a degree of ignorance. For my own decision processes involving platform recommendations, I like to set aside all that I may have known to focus on business requirements. Before recommending any particular strategy, I spend a fair bit of time imagining the total set of process and automation requirements in the context of the functional specifications. We tend to focus on functional specifications but there are also process and automation requirements to consider.

In a mobile climate, it’s now extremely important to develop platform specifications that encompass collaboration, integration, and automation. This is not easy to do and typically clients are not inclined to fund such efforts. However, the efforts of this exercise can often pay big dividends for both consultant and client.

Little Things that Add Up

Recently a client came to me with a business intelligence application she wanted to build. Conventional wisdom of her IT staff suggested that a MySQL server was the right place to collect and manage all the data and that the ideal language to implement the process and rendering requirements was PHP. This is not an uncommon choice for web apps.

I took a look at the requirements and setting aside the mobility piece, the BI charting services, and the collaborative needs, I was inclined to agree. But when I factored in those three little parts, I started to notice a pattern – lots of little requirements that could not be easily created in PHP began to mount up.

Here are some high points concerning this project but which are also very likely to be common among many business apps in the new frontier that encompasses mobile work.

• Email processes – both inbound and outbound require that we craft and send automated email notifications and that we also parse inbound messages for key data and collaborative activities.
• Document processes – the ability to create reports and other documents that can be converted to PDF format and distributed to other users.
• Charts and graphs – the ability to generate and embed charts and other operational data into documents and email messages.
• UI and UX – the ability to provide user access to a wide variety of tabular data in a spreadsheet format; the added ability to create ad-hoc tables based on user-defined calculations and formulas.
• Big Data – the ability to automatically align operational data with large industry-segment data sets  and plot relationships and other BI-related displays.
• Content organization – the ability to store related document artifacts that created internal to the process as well as externally generated content.
• Search – the ability to easily and effortlessly find data stored in documents, email messages, and tables.
• Security context – the ability to create specific share rights and accessibility in a secure environment.
• Local sync – the ability to freely move content artifacts to and from local systems and mobile devices while also embracing the ability to contribute to the application externally generated documents.

Imagine building all of this stuff in a variety of systems and then integrating it – very costly. But ALL OF IT comes almost for free in a platform such as Google Apps. Every one of these requirements is addressable with the Google Apps APIs and SDKs available with its various email, document and drive services.

Try to create a PDF report like this from MySQL data and PHP. The data in this example was collected via a Google form, stored into a spreadsheet, drawn from the spreadsheet and combined into some analytics, and then transformed into a word processing document, and then conveyed for collaborative purposes through a shared folder.

Circling back to the pieces covered by conventional wisdom – PHP and MySQL – is Google’s platform able to accommodate these essential needs as well?

Google Apps Script (GAS)

The scripting environment known as GAS is a variant of javascript designed to provide extensions to the many data types supported across the Google platform. For example, there are methods to locate a row in a spreadsheet, or save a paragraph into a document. The SDKs and methods available to manipulate Google artifacts are numerous it’s a very large collection of programmatic helpers designed and implemented to make it swift work to craft scripts that manipulate common and well as unique data types and content.

This is a formidable development environment that keeps pace with all Google services enhancements. Why? Because Google [itself] builds a number of it’s own services with this same platform.

Data Management

Anyone with MySQL development experience will be reluctant to consider storing data in a spreadsheet; a Google Docs spreadsheet no less. However, it’s inaccurate to think of a spreadsheet in Google Docs as just a spreadsheet. Certainly, it is not capable of extensive relational data representations, and it’s a spreadsheet for heaven’s sake! Um, yeah – a “spreadsheet” capable of storing millions of rows of information – and all with a user interface that everyone understands how to use.

So lets be realistic – a spreadsheet? Seriously?

Yes, you can build business apps that rely on spreadsheets as the data storage model. Business do it all the time; Excel has a long history of businesses running everything from a spreadsheet. However, there are three observations we need to consider before blindly assuming that’s what I’m advocating.

1. I’m not suggesting that business information that flows through a Google Docs sheet remain in a Google Docs sheet indefinitely. I’m not ruling it out, nor am I ruling it in. The basic premise of data storage in a spreadsheet provides significant advantages to developer and users alike. However, they must be considered in the grander context of managing all business data and storing it for the long run.
2. The Google Docs spreadsheet UI is an application sitting atop a very powerful data model; indeed, the same data model that powers Google Fusion and other data services in the Google Platform. In that sense, it is not really a spreadsheet. And given that you can apply SQL queries against it suggests that it possesses a far different technological underpinning than most would conclude based on a cursory glance.
3. Integrated into the Google Apps scripting model is a noSQL database engine (ScriptDB). Moving content to and from noSQL tables from the “spreadsheet” tables is simple and easy to implement. Lastly, Google provides a cloud SQL database system – Google Cloud SQL – with methods for easily transforming the data storage of spreadsheet information.

And while there are no specific relational capabilities in spreadsheet tables, there are ways to overcome this through script as well as formulas.

Summary

It’s wise to consider new models in crafting today’s business solutions. Doing so in context to the full and complete requirements will open new pathways to achieving rapid development outcomes that shorten time-to-market while also mitigating costly management of servers and other infrastructure components that require attention and maintenance effort.