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.

Monday, June 12, 2017

Why I'm After SharePoint

Similarly to the conclusion of several commercials, my reply could be: "Because I deserve it". I consider that SharePoint is Microsoft's best bet after Office, a solution in which the user's needs of sharing a high diversity of files have met the integrity and traceability offered by employing a server process for safeguarding those files.

While "cloud" is a marketing wrapper for high standard hosting services rather than a particular technology, Sharepoint is a very specific integration based on Windows Server, IIS, Asp.Net, MS SQL Server and other Microsoft products, addressing the needs of medium and high risk business processes.

If you can organize your processes in a manner that people are sending to an assistant all their requests for updating the company's shared documents, then SharePoint might not be a necessity for you.

If your processes require only shared read access to files, and it's fine for you to establish strict rules in order to prevent the same file to be updated by more than one person during a couple of hours, then SharePoint might not be a necessity for you.

If you need the same document to be updated by more than one person during a given time interval, then SharePoint is a necessity for you.

Of course you can have your private SharePoint installation, but for a small company in most cases Office 365 is the way to start using SharePoint, and Office 365 is running in Azure.

 Azure is a winning cloud hosting solution for those who want an easy to manage, always up and running system, and it has multiple alternatives for those who consider more appropriate to combine bare metal cloud hosting with the services of an IT&C company assuring the configuration, tuning and good functioning of their system.

But again...why I'm that much after SharePoint? Because I've spent many years with various software products based on plain file sharing, and respectively SQL engines with plenty of threading issues ...and I'm tired of the many problems, complaints, disputes, claims, vaste of time and money resulting from misusing those software products.