April 2008 - Posts

Mobility Opposing Forces - Be Prepared!
25 April 08 01:12 PM | dsamuilov | with no comments

No matter how prepared you are or how well laid out is your project, you could find some opposing forces to progress. This is something you may encounter in some though not all "old-school-type" businesses. Change, specifically aimed at progress is always something that might be feared by some people. Just be prepared to hold hands and guide through the process and get armed with a killer training program so that changes are well received.

Some of the opposing forces to mobility could be counted as concerns which might as well be perfectly reasonable, just have in mind that a good implementation will address all concerns with smart and appropriately budgeted solutions.

Some of these concerns include:

  • User Adoption
  • Total Cost of Ownership
  • Common IT Infrastructure
  • Network Concerns
  • Security

User Adoption

This is the most common concern when you are implementing a new solution. You will find that there are certain company members that will find the most bizarre excuses not to implement a new solution. While this is a very strong force to be opposed by, you already have the tools to beat it outright. Expose the logical process by which you came to the conclusion why this (and not other solutions) happen to be the best one available. The training materials, could explain why it is convenient to jump into this solution as opposed to any other or even remain with status quo. With tougher crowds, you may want to implement presentations that show the benefits of using this solution. These presentations are usually a good warm-up session to the actual implementation because they highlight incredible features along with what it means to the business in terms of revenue, profit and cost reduction.

Total Cost of Ownership

Concerns regarding TCO are usually centered in lack of experience with the platform. While it is true that the first time implementers will incur into a much higher cost than the experienced implementing teams. On the other hand, TCO with Windows Devices remains more flat than an equivalent implementation with laptop computers. Not even to mention that TCO with Windows Mobile has a much, much shorter implementation span, a more extended life span and simpler applications to develop.

Common IT Infrastructure

Windows Mobile devices can be administered remotely, they can access the same infrastructure as networked computers. Servers, services and applications only need to be slightly tweaked to support these devices on top of the existing computers they currently support. Worst case scenario, a new service and administration application may need to be implemented. Such as the tools for remotely administering WM devices. Best case scenario a website or an intranet application does not even need to be tweaked because Pocket Internet Explorer already can browse any website and intranet available through its network.

Network Concerns

Windows Mobile devices can access the same networks that laptops can. They both can use WiFi at any hotspot when equipped with WiFi connectivity and they both can access Internet through cell phone specific connections (laptops would require a carrier-provided USB dongle). On top of those physical connections, VPN's can be easily configured so that devices can access all internal resources that will be made available to them with the security added by the appropriate encryption.

Security

Finally, security concerns can certainly be addressed by encrypting the connection (VPN, encrypted protocols such as HTTPS, etc) or using encrypted data when data is stored in the device. There is a complete selection of encryption standards that I have addressed in a previous post that you can read by clicking here.

 

All in all, opposing forces to a mobile implementation can always be contained, just have your training, presentations and one-on-one explanations that would justify going one way instead of the other. A well though out mobile system should find its way to production easily if the strategy to create it is sound.

Is Your Company Thinking About Mobile Solutions?
21 April 08 03:59 PM | dsamuilov | with no comments

If it's not, then it should. Let me explain why. Every company wants at least their executives to have work email access on-the-go. They may not have it already but if they don't they are certainly craving for it. We live in a business world that is globally managed 24/7/365. A good and timely decision right now can save millions. Smart business requires companies to take a similar approach with other groups such as the sales force to what they do with their executives. Sales force team members could make that extra sale a day just by having access to the information needed whenever and wherever they need it.

Most companies don't really have specific mobile needs as long as their people have mobile email access. That is why most companies out there have email capable devices that can be configured to their corporate email system. Some companies even have a mix of Treos with Palm OS, Blackberries, Windows Mobile Standard, Windows Mobile Professional, etc. This can turn out to be a mess to manage, deploy and maintain. Turning the seemingly simple idea of providing email access into a self-defeating process.

Why would an IT department choose to have multiple OS's to manage, configure and deploy? Analyzing the economics of mobile devices in general we will end up getting to the conclusion that regardless of the platform of choice: Palm OS, Blackberry OS, or Windows Mobile; having a single platform would definitely increase the IT department's productivity and provide better support to their internal clients. The cost would be greatly reduced as well because their server-side-software would have to be purchased for a single platform as opposed to multiple platforms. A single platform would make so much more sense for a company. Additionally, we could also conclude that having a single platform would help develop any mobile applications in the future if they were ever needed. Multiple platforms would force a single application to be developed in multiple languages increasing time to project completion and adding unnecessary deployment complications. Not to mention the madness of maintaining not one, but multiple executable versions, bug fixes and costs.

Hopefully you will agree with me on these issues, if your company already has Visual Studio know-how or at least one of the VS programming languages know-how, it would certainly make sense to take advantage of it. And while it may be true that you may not need any mobile applications in the immediate future, in the longer term there might be a need for such applications. If that happens to be the case, you should not tie yourself down by having the wrong platform. If you find yourself having to implement a solution with multiple hardware platforms and mobile OS's, you would have to have multiple development groups with very different skill sets in order to achieve the same/similar goal than on your desktop corporate applications. You would most definitely be better off leveraging the know-how your teams already have for the desktop and using it all to power a Windows Mobile development team that can do desktop and mobile development tasks interchangeably and in the same language.

If you are looking at potential for growth and you have a large warehouse, traveling sales team members, distribution and delivery and even administrative employees; then this should be the best way at looking into potential ways to increase returns by optimizing the current business process.

...Is Your Company Thinking About Mobile Solutions Now?

Who Should Decide on Implementation Details?
16 April 08 06:40 PM | dsamuilov | with no comments

There seems to be different positions in this matter. There are people that think that IT Management should have final say in these matters and people that are convinced that once the general specifications for the architecture and methodology are laid out, the development team (or the development leadership) should follow with the decision on how to implement the solution. While some people will argue to death one way there are people who will argue to death the other way. I say: It depends!

According to SDLC methodology; the feasibility study/discovery phase/analysis will tell us "what" needs to be done. The "what" is comprised of all business requirements gathered in this phase; the scope of the project and any constraints that we may find as determined by the business areas and listed by the Analysts.

The design phase will determine high level "how", or the technical architecture, the system model, and the test conditions. This is where the second group of people mentioned above decide to stop making decisions. The reason they claim for this is well founded and refers to the fact that they may not know the technical details of how to move forward with the next phase or that they will leave the decisions of the next phase to the people that know them much better than them: the development team leads or even the developers. This is a reasonable stopping point for IT management, but sometimes there will be conflicts.

The development phase is where all the programming happens. The final "how" to implement a solution happens at this point. All the technical details and minutiae are implemented here. Unfortunately this is the exact point of disagreement between both groups of people and the first one will suggest that because they are well versed in technical matters and they have seniority, they should have final say in the details being implemented in this phase. While the most novice developers would appreciate some direction from their management/mentors, the most experienced would prefer to be allowed to make those decisions themselves.

While both positions seem to make sense; it is my opinion that each case would be appropriate if certain conditions are met. The obvious examples are:

  • For IT management with technical expertise; novice development teams require more leadership participation if they are well versed in technical matters.
  • For IT management with technical expertise; experienced development teams and experienced development leaders can be left to operate under their own judgment with little supervision if they show good judgment. Experienced developers that show good judgment will know when to ask for clarification to their management.
  • Non-technical management should try not to get involved with the detailed technical decisions.

So far it can be seen that both positions seem to be correct and could coexist without problems. However; not all IT managers are conscious of their technical limitations, and some are even convinced that they are just as good a developer as anyone in their development team. While most IT managers have a strong technical background, not all have been keeping up with the latest technologies and methodologies. Having a strong technical background creates a false sense of security regarding one's technical skills. Managers who are no longer keeping up with technical issues may fall prey to this false sense of security and may not even be conscious of their situation. On the other hand; a technically savvy manager would keep up with technical expertise and would participate as part of the development team. An IT manager would know how much participation he should provide as part of the development team. Too much and the administrative portion of the management duties will be left unattended. IT managers participation in the development team's duties is a double edged sword: while technically savvy IT managers may gain their developers respect by doing this; technically challenged IT managers may lose the respect of their development team if they make too many bad technical decisions.

Suggesting and ordering to make a particular technical decision are two completely different things. Managers who are not conscious of how up to par they are will create conflicts if they force developers to implement the wrong technical decision into code or to implement their code in a way that is not technically correct.

Developers may know what and how it needs to be done, they may even raise the issue to their managers; but some IT managers, too mistrusting of their team or not fully aware of all the technical implications may choose the wrong option which unfortunately makes them bad managers no matter how they see it.

I am not saying that all developers should have a confrontational attitude. But if you feel that the wrong technical decision is made, it is the developer's responsibility to raise the issue and get the technical issue resolved before it becomes too costly to fix. By the same token; I am not saying that all managers should stay out of the developers way, quite the contrary, their suggestion will most likely be received with gratitude when given as a solution to resolve the right technical issue. Even if an IT manager is technically savvy, they should still know when to stand on the sidelines and let their team shine by letting them make those decisions. The result will shine back on the manager. As mentioned above, these two positions can coexist depending on when it is appropriate to take one stance or the other.

There are several morals to this story:

  • IT managers should keep up with technical developments.
  • IT managers should keep an open mind and at the very least research appropriately when their senior developers raise a question on their technical decisions. These situations should also be used as a flag for the manager to get the appropriate technical update.
  • There is nothing wrong when a developer knows more than an IT manager about a subject, use this as an opportunity for learning from the developer.
  • Developers should try to raise the technical issue in the appropriate manner, otherwise they may not be taken seriously.
  • Last and foremost: IT managers should be open-minded and humble enough to know that there is always something new to learn from someone else, even if they are the new guy with little or no experience at all.
How Secure Is Your Mobile Application Data?
09 April 08 09:13 PM | dsamuilov | 1 comment(s)

When developing mobile applications we usually think in terms of a single user; doing only a few tasks in a small device. However, this may no longer be true. We are now faced with devices that have large screens (for a smartphone, that is) such as the HTC Advantage 7501 with a 5" screen and a decent size keyboard. Some of them are quite frankly borderline-UMPC sized. This means that not only the usage paradigm will shift into more desktop-like functions while keeping the mobile form factor.

For corporations, this could mean that there is a higher risk of exposing sensitive data or even trade secrets. Even with precautions and OS-security features as advanced as they are today such as Compact Framework provided encryption APIs and the ability to wipe a whole device from the Admin's desk by using Exchange 2003 SP2 and SMS Device Management Feature Pack a user could take a while to report the loss of a device. This could potentially open a window of opportunity for someone looking for a security gap. So, having said that; your application's security setup is now more than critical. You application could be quite at risk of exposing secure data if not handled adequately.

So what can be done to secure an application? Well, the amount of security is a function of how much time, resources and budget you have on top of making the application user-friendly enough. Basically, the more money, time and effort you put into security the safer/more secure it could potentially be. However, because of the human factor involved in usage and programming (yes, developers are included in this equation) there is no such thing as an absolutely secure application, it is always a matter of risk, and how much the business is willing to risk/invest into securing the data. On top of all that there is a matter of meeting the appropriate user-friendliness for your application to be adopted easily.

Visual Studio comes with some pretty cool security features; but again; it depends on the developer to implement, the analysts to design into the application and the business areas to budget their needs accordingly.

Windows Mobile and Compact Framework already come with the following features that you can take advantage of:

Crypto API - Encryption: any piece of data can be encrypted by using some simple calls to the System.Security.Cryptography API or Crypto API for short. There are several different types of encryption you can use such as Symmetric vs. Asymmetric encryption Algorithmic vs. Hashed data. The ones that are included in the Compact Framework are:

  • Digital Signature Algorithm (DSA)
  • MD5 hash algorithm
  • RC2 and RC4 algorithm
  • Cryptographic Random Number Generator (RNG) algorithm
  • RSA algorithm
  • SHA1 hash algorithm
  • Data Encryption Standard (DES) algorithm
  • Triple Data Encryption Standard (TripleDES or 3DES) algorithm
  • Rijndael (AES) algorithm

All these different algorithms cover a pretty wide range of security levels and process complexities. With all these choices, you are definitely bound to find the one algorithm you like, that fits your requirements and your compliance needs. For example: Rijndael (AES) is used as a US Federal Government Advanced Encryption Standard.

Let's say you have to store data in the registry, you could make your application safer and more secure just by storing its data encrypted so that anyone snooping around the device registry would not be able to figure out what you stored under those registry keys.

The same example is valid for storing data in plain text or under an XML file which is nothing but a plain text file with tag formatting. If you encrypt the data before you store it, then you would be protecting the data from any curious user or unauthorized access.

SQL CE Encryption: One common method of storing information in Windows Mobile is SQL Server CE. Even though SQL Server CE does not support logins and their respective passwords, it does support 128-bit encryption of the data in the SQL Server CE database with a password that only your application would know or even better the user would know; therefore giving you a secure way to store information in it.

Access to Networked Data: You can also access services over secured networks. If you do not want to store information in your mobile devices, you can use a web service-like application. You could secure your communication channels to the target service. Your application could be using tools such as:

  • Network Authentication
    • NTLM versions 1 and 2
    • SSL Basic and TLS Client Authentication
  • Wireless LAN Security
    • WiFi 802.1x user authentication using
      • Protected EAP (PEAP)
      • EAP/TLS (certificate-based)
      • WPA
  • Native VPN support
    • PPTP
    • L2TP
    • IPSec

You may establish a secure connection between your device and the target by using any of the mentioned tools and protocols.

Encrypting Data Streams: There might be a similar way of implementing your encrypted security if you access a web service by encrypting only selective pieces of critical data that you send or receive and not using the encrypted protocols that may pose a larger overhead for performance when everything going back and forth is encrypted.

Finally remember that too much security may also work against you degrading performance or extending your development time frame. Also have in mind that applying one encryption method and then another on top of the first one does not necessarily make your application more secure and it will surely add more overhead to your application.

No matter what your needs are and even though not perfect; the tools provided by the Compact Framework are great for establishing a custom cryptographic solution for your applications needs. So take your time learning them and using them to your favor.

Windows Mobile 6.1 Emulators Out
08 April 08 10:19 AM | dsamuilov | with no comments

With the release of Windows Mobile 6.1 and some models already announced, it was only logical that we would see the WM 6.1 emulators out for Visual Studio 2005 and Visual Studio 2008.

Just like their predecessors, the emulators are stand alone and can be used outside of Visual Studio. They seem to work like a charm (so far no bugs to report).

One new feature to report is that since there have been a few devices with new resolution screens, the emulator now supports those as well.

 

Windows Mobile 6.1 Standard

  • 131 DPI - 320 x 320 px
  • 131 DPI - 400 x 240 px
  • 131 DPI - 440 x 240 px

 

Windows Mobile 6.1 Professional

  •   96 DPI - 240 x 400 px
  • 192 DPI - 480 x 800 px

 

Download them and see for yourself here:

http://www.microsoft.com/downloads/details.aspx?FamilyId=3D6F581E-C093-4B15-AB0C-A2CE5BFFDB47&displaylang=en