Summer holiday and Symbian Foundation

Finally sweet summer and holiday are here! Long days and nightless nights take thoughts away from mobile issues, don’t expect many postings during July!

Before holiday, a couple of minor notes about the recent Symbian Foundation news.

Symbian developers available. When Nokia has merged, reorganized and streamlined development process of UIQ, S60 and Symbian there will be bad news for developers. UIQ already started this by announcing to close down two of their three offices and this - I’m afraid - is just the beginning. However, Symbian related development work will not disappear, it will just move to different companies. The resources needed for platform development will be reallocated for application level development.

The return of the user interface. Many years ago Symbian’s former CEO Colly Myers admitted in an interview that Symbian shouldn’t have spent time on UI development because UI has such a strategic meaning to phone manufacturers. Phones had to be differentiated somehow and UI had to pay the price - companies have spent much time and money to create different UI’s on top of Symbian and the results have been...well, you know. Now UI will become part of Symbian and hopefully we will see it improving when best parts of different UI’s will be put together. For typical phone user UI is one of the most important things; having efficient memory management doesn’t help if you cannot easily use your phone to do everyday tasks.

The return of UI will raise Symbian from OS level to platform level.

Symbian will become open and free, is that important? Yes and no.

It is important because it will put all developers to same line. So far there have been 1st class developers who have had access to Symbian internals and then the rest of us who have been told that some things are just not for us. Innovation needs fuel and this is it.

The phone’s success is determined every day at the retail shops. There phones are nothing else but consumer electronics, evaluated by many properties and operating system is not one of those. Phones are like cameras - or do you know which OS your digital camera has and what were the licensing terms? Would it matter?

Have a nice summer!

//Harri

Solutions for system integrators

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.

//Harri

S60 optimized Picasa

Remember by old rant about iPhone getting all the attention and nice optimized application versions whereas the rest of the mobile community must beg for support? Now it appears that at least Google's Picasa has become S60 optimized. This can be a good start, I wish. 

//Harri

Email as SMS replacement?

Those who use GMail with browser might have noticed that there is a new Lab-page available where Google has put some new features for users to test. Nothing spectacular, I must say.

These new features put me into thinking about GMail's strengths, especially in mobile use. One nice feature is the Push Mail feature that works just great. In fact it works so well that sometimes I have wondered could it be used as a cheap replacement for SMS messages. As everybody knows, SMS's are great way to send user quick information, but the drawback is that every message costs real money to the sender. If you send lots of messages, that will have economic importance although cost for one single message is negligible.

Some time ago I was looking for a solution that could alert me by SMS when some important RSS feeds are updated. I can understand that the lack of these kinds of solutions is just because nobody wants to pay the price of sending SMS messages to users. My idea was essentially not about receiving SMS's, it was about receiving alerts to mobile terminal and that requirement could quite nicely be implemented with mobile GMail. What this would mean is that Google team should add feature to Reader that would allow user to request an email alert when an important feed is updated. If user wants, he could redirect an update message to his GMail inbox and if that account/folder is subscribed to mobile phone, we would have a free RSS alert without any SMS's.

BTW: did you know that you can append tags to your GMail address, just write + after your email address, like firstname.lastname+rss@gmail.com. After you have tagged your address like that, it is easy to create filters and it is also a nice way to track who has leaked your email address to spammers.

//Harri

Old technologies’ last gasp

I found an interesting article by Daniel C. Snow from January 2008 Harvard Business Review. In his article “Beware of Old Technologies’ Last Gasp” he explains what are the reasons behind the phenomenon that it will take longer than expected before new technology will replace the old one and hence it will take longer than expected before the new technology companies will become profitable. I feel that in mobile business this problem is not as big as in some others, because mobility seldom replaces completely the old process. Mobility is both-and; not either-or. Another possibility is that mobility enables something that hasn’t been available before, therefore there’s nothing to replace.

First reason why old technologies survive longer than expected is that new solutions replace old ones first from market segments where the old technology was already poorly suited (“A retreat to defensible ground” as Snow puts it). This gives better position for old solutions to compete at segments where they are at their best. This gives a temporary improvement to their performance and delays the expansion of the new solution.

Second reason for the last gasp of old technology is that old solutions can learn something important from the new ones and sometimes even use parts of the new solution to gain quick improvements.

These observations are important for both parties: new players must prepare to wait a little bit longer before their business projections will become true and the old solution providers must not make the mistake that they believe the “last gasp” to be a sign of successful and sustainable improvement.

//Harri

New channel to access Mobilitics

Today I made Mobilitics accessible also from Nokia's Widsets solution. If you want to give it a try, just click this button  and add the feed to your mobile desktop.

Also the good old m.mobilitics.net is still there to access the site from your mobile browser.

//Harri

Customer oriented device management

Have you ever wondered why such a great thing as mobile device management is so rarely used, at least in smaller companies? After all, when new terminals are deployed to customer, the major problem is how to get the settings configured and applications installed. If end-users are supposed to do that by themselves, you can say goodbye to productivity and finally majority of the users are not able to use the new terminals for any other purpose than making voice calls. This is just the point where device management comes to the picture and customers are ready to buy the solution but...is there anybody to sell it?

Every time I have seen device management solution productized, result has been the same; monthly fixed price subscription. Customer wants to solve a one-time problem and salesman tries to sell a subscription; you want a glass of milk and are supposed to buy a dairy. What if device management were productized from a customer’s point of view, what would the problems look like? I would list something like:

• how to move data from old terminal to new one?
  
• how to deploy settings to new terminal?
  
• how to install the corporate applications to new terminal?
  
• how to fix the terminal settings if user makes an unwanted change?
  
• how to remotely wipe the terminal if it is lost?
  

If we forget the subscription model we can create new products that technically use device same management protocols like OMA CP and OMA DM but speak language that customers can easily understand. A customer oriented device management offering could sell services like:

• Move contact and calendar data from old terminal to new one
  
• Deploy initial network and email settings to new terminal
  
• Install x applications to new terminal, additional installations cost ?€ each
  
• Restore initial settings
  
• Wipe lost device
  
• Create application inventory report form terminal
  

If you run a device management server, you probably can easily give a price tag for every feature above. Subscription model is a valid business model for companies who continuously make changes to terminals and want to keep device management contract as an insurance for the rest of the terminals - just in case something goes wrong. For other customers a simple pay-as-you-use business model that solves understandable problems really would make sense.

//Harri