Earlier this year I wrote a checklist to use before a potential mobile project, a tool to verify if the proposed mobile project would make sense. Then later I wrote second question set that you could use after you have decided to create an installable mobile application. This is the third checklist, aimed for projects that want to ensure that their solution is easy to sell, easy to buy and easy to productize as a service. My aim is to remind you that although the mobility issues are important, your solution might also need features that operators and/or system integrators appreciate. Some might say that these topics are self-evident, but I’ve seen that sometimes all development focus is put to mobility and these basic requirements are forgotten.
I like your solution and I want to sell it to my customers. What should I do?
After you have done some serious marketing and customer has accepted your proposal, next thing is to give detailed instructions how to setup the solution’s environment. What kind of server setup is needed? How many users can typical server configuration handle? What happens when the user limit is reached?
Mobile (enterprise) applications are almost always connected to back-end servers and processes. For that reason designing the server side architecture together with smartphone architecture is an important task to ensure successful project completion. Of course there is no single right answer for server architecture, but at least following subtopics should be kept in mind.
Think about the situation that your application becomes really successful and your current server setup is overloaded and customers are getting frustrated as operations are getting slower every day. What would you do? Buy more hardware, I guess, but then what? If you haven't thought about this before, you might experience problems if your application isn't really scalable. Just replacing the old server with new one isn't enough if you cannot balance the load between multiple servers. Remember also that being able to distribute processing between multiple servers increases fault tolerance.
Also remember that scalability must be implemented so that you can explain and verify to the customer that it really can be done. This is an important selling point, because of course you and your customer both believe that this application will become a huge success, right?
Surely you don't code everything from scratch by yourself, but build system architecture using some "building blocks" from various sources. When selecting those components, pay attention not only to technical aspects but also to popularity and familiarity of those components. Developing software is expensive, but maintaining and supporting it 24/7 is even more expensive. If you select verified and common application components, you probably make life much easier for your hosting and training partners. After all, a major part of solutions costs occur after the deployment because support and maintenance are expensive tasks. Check my posting about the cost of mobility for reference.
Is this a service?
If you don’t sell your solution as SaaS (Software as a Service), I’m quite sure that one of your partners will do so. They will then be very interested if they can host multiple customer organizations from a single server installation securely and easily.
Multitenancy may be somewhat unfamiliar term for a very understandable requirement: you should be able to run multiple independent instances of your application using single hardware. Independent instances mean that they have private data areas and instances can be managed separately. This is an important requirement for companies creating applications to be hosted by other companies: if new hardware must be installed for every new customer organization, installation and system maintenance costs become too expensive and your systems is not as competitive as it could be.
Also you should remember to think early about user accounts and billing. Being “easily billable” means that the solution must save auditing data that can be used for billing users. What that data really is depends on your business model, but in optimal solution you would have multiple options for this. Some of your partners can prefer monthly subscriptions whereas some other partner can find charging based on data amount better, for example. Here you can also think that if your terminal application always requires server access, it is much easier to distribute the terminal application freely without license codes, because the application is useless without a valid server license. Implementing licensing and billing is much easier on the server side, compared to solution where you try to do that on the terminal. Also it wouldn’t be a problem if users want to change their terminals as license is bound to user account, not to a piece of hardware.
Is your solution secure?
If you forget security issues, you can say goodbye to customers - very simple rule. Minimum requirement is that you should be able to explain how security is handled in your solution and why customer should feel safe. During solution development you must balance between application’s usability and security; make your decision and be prepared to explain that to customers. Security is also about understanding the potential risks and an important task is to be able to explain the solution’s security model so that the potential customer can do risk analysis - small known risk is much better than not being able to do risk analysis at all.
Especially enterprise solutions must allow hierarchical user model. This means that user management can be delegated to different sub-organizations so that organization’s all user management is not done by one superuser. Add proper auditing to this and you will get solution that can also create a report about who has done what and when. In some cases you will be asked if your solution complies with the Sarbanes-Oxley Act, meaning (simplified!) in practice that solution must include auditing and data integrity must be maintained - also with mobile devices.
One interesting aspect of security with mobile devices is co-operation with 3rd party security applications like anti-virus and encryption software. For example, when data encryption application is installed into the terminal, the files might not be readable when you try to access those. Especially with older devices security applications created problems by slowing down the terminal and consuming a large percentage of free RAM.
Finally: encrypt all communications. Always.
No comments:
Post a Comment