Sunday, June 18, 2017

Do-It-Yourself Apps

There are countless tools out there for building mobile apps, from frameworks designed for developers to SaaS solutions targeting non-technical users.

While "cross-platform development" is a commonly abused term referring to designing an app and building its corresponding app packages for various devices, "do-it-yourself app" is an even more confusing denomination.

For a teenager, who already knows some html, JavaScript is a natural option for getting started with the basic programming concepts, such as memory variables, conditional statements or loops. Using a basic framework for packaging his/her first bytes, and running it on a mobile device can be incredibly motivating for digging deeper in the IT world.

For a student, who already knows about servers, document sharing, databases and server-side scripting, putting together a mobile app for employing those server resources is going to be his/her first architecting experience.

For a non-technical person, who handles documents via Office, SharePoint or Google Drive, using an online wizard for generating a mobile app could be a positive initial experience, followed by various scenarios down the road.

If a team of non-techie persons is using the services of an IT&C company, who is taking care of hosting their documents and data, and is also offering the possibility of generating apps for accessing that data, then good chances are that things will keep working as expected.

If our team of non-techie persons is using a SaaS solution including an online app generating wizard and a middleware for wiring together the generated app with data in a database hosted by a third-party, then everything can happen.

In case their database consists of Excel or similar workbooks on Google Drive, OneDrive, DropBox etc., the scenario is plain file sharing, which works ok while those files are set as read-only, or are accessed by one person at a time for writing.

In case their database is a SQL engine, they will certainly need an IT guy for setting up the connection between the database and the middleware, and advising about the DOs & DON'Ts of the database engine they have.

In both cases the response time will always be very slow, because the middleware is accessing a third-party system instead of a data store situated within the same data center.

In my opinion the middleware itself represents the weak chain of a SaaS solution offering access to a wide variety of data stores and/or file formats.

Since the difficulties caused by migrating data between dBase, Access, MySQL, MS SQL Server etc. tables, there is known that there are no shortcuts, no "one size fits all" automations for working with data. The more types of storages are handled by a software, the more bigger the software grows, and the more error conditions occur.

In other words, the more types of files a middleware is handling, the bigger and slower and more error prone is getting.

IMHO a SaaS solution generating apps might be suitable for small companies having low-medium risk business processes and sharing a couple of tables with limited write access, or for projects with urgent data sharing needs, until the project owner acquires a more customized solution.

No comments:

Post a Comment