I run a software company and I design and build an enterprise strength content management system called RecFind 6 which among other things, handles all the needs of physical records management.

This is fine if I have a big corporate or government customer because the cost is appropriate to the scale of the task at hand. However it isn’t fine when we receive lots of inquiries from much smaller organizations like small law forms that need a records management solution but only have a very small budget.

A very recent inquiry from a small but successful engineering company was also a problem because they didn’t have any IT infrastructure. They had no servers and used Google email. However, they still had a physical records management problem as well as an electronic document management problem but our solution was way outside of the ballpark.

Like any businessman I don’t like to see business walk away especially after we have spent valuable consultancy time helping the customer to understand the problem and define the need.

We have had a lot of similar inquiries lately and it has started me thinking about the need for a new type of product for small business, one that doesn’t require the overhead and expense of an enterprise-grade solution. It should also be one that doesn’t require in-house servers and a high overhead and maintenance cost.

Given our recent experience building a couple of iOS (for the iPhone and iPad) and Android (for any Android phone or tablet) apps I am of the opinion that any low cost but technically clever and easy-to-use solution should be based around a mobile device like a smart phone or tablet.

The lack of an in-house server wouldn’t be a problem because we would host the solution servers at a data centre in each country we operate in. Programming it wouldn’t be a problem because that is what we do and we already have a web services API as the foundation.

The only challenge I see is the need to get really creative about the functionality and the user interface. There is no way I can implement all the advanced functionality of the full RecFind 6 product on a mobile device and there is no way I can re-use the user interface from either the RecFind 6 smart-client or web-client. Even scaled down the user interface would be unsuitable for a mobile device; it needs a complete redesign. It isn’t just a matter of adapting to different form factors (screen sizes), it is about using the mobile device in the most appropriate way. It is about designing a product that leverages off the unique capabilities of a mobile device, not trying to force fit an application designed for Windows.

The good news is that there is some amazing technology now available for mobile devices that could easily be put to use for commercial business purposes even though a lot of it was designed for light weight applications and games. Three examples of very clever new software for mobile devices are Gimbal Context Aware, Titanium Mobile SDK and Vuforia Augmented Reality. But, these three development products are just the tip of the iceberg; there is literally a plethora of clever development tools and new products both in the market and coming to market in the near future.

As a developer, right now the Android platform looks to be my target. This is mainly because of the amount of software being developed for Android and because of the open nature of Android. It allows me to do far more than Apple allows me to do on its sandboxed iOS operating system.

Android also makes it far easier for me to distribute and support my solutions. I love iOS but Apple is just a little too anal and controlling to suit my needs. For example, I require free access to the file system and Apple doesn’t allow that. Nor does it give me the freedom I need to be able to attach devices my customers will need; no standard USB port is a huge pain for application developers.

I am sorry that I don’t have a solution for my smaller customers yet but I have made the decision to do the research and build some prototypes. RecFind 6 will be the back-end residing on a hosted server (in the ‘Cloud’) because it has a superset of the functionality required for my new mobile app. It is also the perfect development environment because the RecFind 6 Web Services SDK makes it easy for me to build apps for any mobile operating system.

So, I already have the backend functionality, the industrial-strength and scalable relational database and the Web Services API plus expertise in Android development using Eclipse and Java. Now all I have to do to produce my innovative new mobile app is find the most appropriate software and development platforms and then get creative.

It is the getting creative bit that is the real challenge. Wish me luck and watch this space.

Over the last 28 years of running this business I have had hundreds of conversations with customers and partners about integration. In most cases when I have tried to obtain more details about exactly what they wanted to integrate to and how I have drawn a blank. It is as if the word ‘integration’ has some magical connotation that everyone is supposed to instantly understand. Being a very logical and technical person, I guess I fail the test because to me it is just a general term that covers a multitude of possibilities.

I have also designed and/or programmed many integrations in my life and I can honestly say that no two have ever been the same. So, assuming that you have a requirement for two or more of the application software products you use to ‘integrate’ how should you go about defining what is required so it is as clear and as unambiguous as possible to your partners, the people you will ask to do the work?

Integration is usually about sharing information and importantly, not duplicating effort (i.e., having to enter data twice) or duplicating information. Having to enter the same information twice into two different systems is just plain dumb and bad design. Maintaining duplicate copies of information is even dumber and dangerous because sooner or later they will get out of step and you will suffer from what we call a loss of data integrity. This is usually why we need integration, to share information and to avoid duplicate effort and duplicate information.

For our purpose let’s assume that we have two application systems, A and B, that we need to be ‘integrated’; both use a SQL database to store data. Applications A and B are produced by different vendors that haven’t worked together before. The first fact to face is that in the normal course of events each vendor is going to want the other vendor to do all the work and each vendor is going to want the other vendor to utilize its proprietary integration methodology (e.g., Application Program Interface (API) or Software Development Kit (SDK)). This is your first big challenge; you need to get the vendors to agree to work together because no matter how this turns out both are going to have to do work and contribute; you can’t complete an integration using just one vendor. That is, the most important thing you have to do is to manage the vendors involved. You can’t just leave it up to them; you need to manage the process from beginning to end.

The second most important thing you have to do is to actually define and document the integration processes as clearly as possible. Here is a checklist to guide you:

1.    Will application A need to access (i.e., read) data held by application B?

2.    Will application B need to access data held by application A?

3.    How often and at what times is access to data required? All the time, once a day, once a week, only when something changes, only when there is new data, every time a new record is added to either application A or B, etc. What are the rules?

4.    How is the data identified? That is, how does application A know what data it needs to access in the application B database? Is it by date or special code or some unique identifier? What are the rules that determine the data to be accessed?

5.    Will application A need to transfer data to application B (i.e. write data to the B database)?

6.    Will application B need to transfer data to application A?

7.    How often and at what times is a transfer of data required? All the time, once a day, one a week, only when something changes, only when there is new data, every time a new record is added to either application A or B, etc. What are the rules?

8.    How is the data identified? That is, how does application A know what data it needs to transfer to the application B database? Is it by date or special code or some unique identifier? What are the rules that determine the data to be transferred?

9.    Does application A have an API or SDK?

10.What is the degree of difficulty (expertise required, time and cost) of programming to this API or SDK? Rate it on a scale of 1 to 10, 10 being the most difficult and most expensive and most time consuming.

11.Does application B have an API or SDK?

12.What is the degree of difficulty (expertise required, time and cost) of programming to this API or SDK? Rate it on a scale of 1 to 10, 10 being the most difficult and most expensive and most time consuming.

13.Is the vendor of application A happy to assign a suitable qualified technical person (not a sales person or pre-sales person) to be the interface?

14.Is the vendor of application B happy to assign a suitable qualified technical person (not a sales person or pre-sales person) to be the interface?

15.What is your timescale? When does it have to be completed? What is the ‘driver’ event?

16.What is your budget? Basically vendors work in a commercial environment and if they do work then they expect to get paid. As a rule, the size of the budget will depend directly upon your management skills and the quality of your integration specification.

Please keep it in mind that there are always multiple ways to integrate; there is never just a single solution. The best way is always the simplest way and this is usually also the lowest cost and quickest way as well as being the lowest cost to maintain. Think about the future, the most complex solution is always the most difficult and most expensive ongoing maintenance solution. Think KISS; minimize your pain and expense.

As a guideline, the vendor with the most work to do is usually the best one to be the ‘lead’ in the integration (remember, both have to be involved or it won’t work). So, if for example vendor A needs to read data from Vendor B’s database and then massage it and utilize it within application A then vendor A is the natural lead. All vendor B has to do is expose its API and provide the required technical assistance to vendor A so vendor A can successfully program to the API.

However, in the end it will usually be the vendor that is the most cooperative and most helpful that you will choose. If you choose the vendor you most trust and work best with to be the lead then you will maximize your chances of completing a successful integration on time and on budget.