IS/IT customer overview/viewpoint:
One of the main issues that IT always considers during the purchase of new technology is how will this affect their current workload and what happens when the rollout is complete? IT groups have to support technology long after most of the project stakeholders and project managers have moved on to other things. As a seasoned IT professional they understand this and therefore they are notoriously skeptical of anything new because, good or bad, they are left with responsibility for the entire lifecycle of the product. One of the things that they learn early is that there are no easy projects, this is life in IT, but bad projects are to be avoided at all costs, additionally they would never willingly agree to the expansion of a project that was already going badly.
There have been few exceptions to this; usually they will only agree to go forward if they can be convinced of two things. The first is that the company providing the technology is as concerned about success as they are and will be long term. It is crucial that they have access to resources who have successfully managed a deployment of the technology that they are considering deploying. Secondly, if they are having an issue they want to understand what the issue is and what the vendor is doing to assure that this will not happen again and how they intend to work with them through the current issue. They would rather have a product that is less than optimal than one that they will have difficulty supporting.
This can be a larger issue than whether the technology has a great and undeniable benefit because if they determine that they cannot support the technology then the benefit is irrelevant to them. Often the benefit is irrelevant to them anyway.
Mitigation strategies- IS/IT concern over the difficulty of deploying new technology is especially sharp during times of challenge, this is never clearer that during initial deployment acceptance or during the process of moving from a small pilot to a larger much broader deployment.
Product familiarization- Obviously the way to overcome discreet product familiarization concerns, form factor, pen use, battery management, etc, is with a combination of product training and with the active involvement of the stakeholders and deployment people within the organization. Companies can usually assist with this through either structured training or ad hoc involvement of the sales person or the regional technical sales guys. This works marginally well as long as there are no external or product issues that cause additional concern.
Product ecosystem- This can be defined as the “terrain in which you are to be deployed” When describing this process it is important to understand that we are usually trying to either displace an existing technology or we are trying to differentiate ourselves from a competitive product. There are a number of issues that come into play with this process they range from minor to overwhelming depending on the severity of the problem. These are critical issues when determining how best to proceed with managing the customer experience.
These issues vary but mostly fall into three broad categories:
• Software issues like application compatibility, input modes, usability.
• Hardware issues like obvious product issues, input devices, form factor acceptance.
• Environmental issues like wireless, SSO or temperature or perhaps ESD related.
Traditionally companies have focused on VAR/Integrators and internal customer groups like IS/IT or perhaps the project champion to work with sales and to achieve successful acceptance. While this is not likely to change and is the most direct path to success it is important that companies also focus on making this easier for IT/IS to accept and therefore more successful.
What is “Mobility” and how is it defined?
Mobility has commonly been defined as the process of walking and standing while interfacing with an application. Therefore for a mobility solution a lightweight device with a different input mechanism from a keyboard is desirable and in fact probably necessary. Commonly it is assumed that if you have an application that you can use with a pen and/or touch, connectivity to the network via a wireless connection of some sort then “mobility” is achieved.
In a very narrow interpretation this would indeed be true, but if this is all that is necessary why is deploying and using the technology such a challenge to the people who are responsible for managing and supporting the devices?
The answer lies in the inherent issues that surround the hardware solution, most of these from an IS/IT perspective have nothing to do with the core end user application, they have to do with the IT systems that will need to be implemented to support the device. You have to make this simple and easy to integrate, A lot of times core product features actually exacerbate this problem rather than solve them. This is because they are not mainstream to the devices that they are already supporting.
How do you overcome these issues?
First you have to fully understand the “terrain in which we are deployed”, this means more than partnering with software vendors and developers who are creating mobility enhanced applications, and it is also more than assisting with the installation and development of high availability wireless networks. Companies need to focus on the entire mobility ecosystem. This will enable you to guide and provide assistance to the people that support the end user devices and guarantee successful long term integration of mobile products into the mainstream IT environment. Then internal staff can be partners and advocates rather than obstacles to overcome.
What do you need to do in order to make this happen?
1. A complete understanding of the entire environment that an IT group has to contend with. This will help us to provide guidance to the support groups and make them successful. This includes imaging, provisioning, authentication, physical and network security.
2. Partnerships with specialists who can provide these solutions. This is more than just a joint selling environment or one off co-development. It is the procurement of the resources that can actually provide guidance, deploy and configure technology in partnership with the end user support environment.
3. Constantly be looking ahead at where the IT/IS infrastructure is evolving and be able to turn this knowledge into solutions that customers can use and benefit from. You can not rely on local resources to figure this out, they may not be able to or may make decisions that are not in either their or ours best interest.
It is important to remember that you are not forcing change you are facilitating the transition to the inevitable result of end user mobility. In other words, you are providing thought leadership and behaving as partners rather than just one more product that the IS/IT group has to deal with. This can be a real differentiator for you and enable you to provide a more meaningful relationship with the groups that will ultimately determine device purchases. I truly believe that in the end it is not the CIO or the end users but an overworked desktop support person who will be able to dictate more technology purchases than not.
Wednesday, May 5, 2010
Friday, March 5, 2010
Overview
The functional line is being blurred between smart phones, ultra portable devices and PC’s. A couple of years ago smart phones were considered virtually unusable for enterprise applications other than e-mail and messaging and PC’s and laptops were considered unusable for real time mobile communication devices. This is starting to change as the market see’s the emergence of ultra portable devices that are able double as true enterprise productivity devices. This year at CES we are seeing a lot of devices that can be used as enterprise productivity devices but are primarily targeted at mobile communication and entertainment. This provides an opportunity to either build or repurpose these devices and use them for enterprise application presentation.
The opportunity extends both to the device and the application side of the solution set and is the premise for the rest of this document; that premise being that with the new class of enterprise devices opportunities exist for leveraging them against use cases that have traditionally been served by larger sized presentation devices and operating systems.
Examples of enterprise applications that would benefit from use of an ultra-portable device:
EMR applications
MRP applications
Enterprise deployment issues surrounding enterprise application adoption on smaller form factor devices:
Security – this includes security for both the data and the device
Accessibility – meant to indicate access to the IP transport layer and speed of same.
Supportability – Would the device be relatively easy for enterprise IT groups to support and maintain?
Cost – Is the feature / function benefit supported by a good efficiency improvement or revenue model?
Enterprise application usage:
In general if an application is written for use in production enterprises then they are usually meant to be run on a Windows based platform and they are meant to be rendered on a large screen, usually 1024/768 minimum. If they are used on smaller form factor devices then they either don’t render correctly or the screens are so small that they are unusable. This has been the case when trying to use enterprise applications on traditional smart phones and PDA’s. This is coupled with the notoriously buggy nature of these devices.
Issues with ultraportable devices:
Primarily the issue with ultraportable device use in the enterprise is centered around the following two main areas:
1. Input and presentation layer issues – these are varied but mainly center around screen size and input device, touch screen or virtual/real but tiny, keyboards.
2. Lack of ability to run enterprise applications - because of the way that the applications are being rendered, they aren’t viewable or aren’t usable on smaller screens.
3. Limited battery life, ,limited peripherals – batteries run out fast or there is a small amount of peripherals that are usable on these devices.
4. Power and storage space limitations - extremely limited and therefore causes the devices to be heavy and or overheat and or perform poorly.
5. Operating system limitations – They are either too lightweight or are too cumbersome to use on small devices therefore limiting both performance and capability.
Why Google’s Android may be the best answer:
1. The operating system has a base Linux Kernel and can be used easily in conjunction with or for development on many platforms that are already in existence.
a. Unlike
The functional line is being blurred between smart phones, ultra portable devices and PC’s. A couple of years ago smart phones were considered virtually unusable for enterprise applications other than e-mail and messaging and PC’s and laptops were considered unusable for real time mobile communication devices. This is starting to change as the market see’s the emergence of ultra portable devices that are able double as true enterprise productivity devices. This year at CES we are seeing a lot of devices that can be used as enterprise productivity devices but are primarily targeted at mobile communication and entertainment. This provides an opportunity to either build or repurpose these devices and use them for enterprise application presentation.
The opportunity extends both to the device and the application side of the solution set and is the premise for the rest of this document; that premise being that with the new class of enterprise devices opportunities exist for leveraging them against use cases that have traditionally been served by larger sized presentation devices and operating systems.
Examples of enterprise applications that would benefit from use of an ultra-portable device:
EMR applications
MRP applications
Enterprise deployment issues surrounding enterprise application adoption on smaller form factor devices:
Security – this includes security for both the data and the device
Accessibility – meant to indicate access to the IP transport layer and speed of same.
Supportability – Would the device be relatively easy for enterprise IT groups to support and maintain?
Cost – Is the feature / function benefit supported by a good efficiency improvement or revenue model?
Enterprise application usage:
In general if an application is written for use in production enterprises then they are usually meant to be run on a Windows based platform and they are meant to be rendered on a large screen, usually 1024/768 minimum. If they are used on smaller form factor devices then they either don’t render correctly or the screens are so small that they are unusable. This has been the case when trying to use enterprise applications on traditional smart phones and PDA’s. This is coupled with the notoriously buggy nature of these devices.
Issues with ultraportable devices:
Primarily the issue with ultraportable device use in the enterprise is centered around the following two main areas:
1. Input and presentation layer issues – these are varied but mainly center around screen size and input device, touch screen or virtual/real but tiny, keyboards.
2. Lack of ability to run enterprise applications - because of the way that the applications are being rendered, they aren’t viewable or aren’t usable on smaller screens.
3. Limited battery life, ,limited peripherals – batteries run out fast or there is a small amount of peripherals that are usable on these devices.
4. Power and storage space limitations - extremely limited and therefore causes the devices to be heavy and or overheat and or perform poorly.
5. Operating system limitations – They are either too lightweight or are too cumbersome to use on small devices therefore limiting both performance and capability.
Why Google’s Android may be the best answer:
1. The operating system has a base Linux Kernel and can be used easily in conjunction with or for development on many platforms that are already in existence.
a. Unlike
Overview
Wireless networks are evolving rapidly into very complex combinations of different services that are not inherently designed to work together in a seamless manner. Companies must rapidly develop strategies that will allow them to balance this range of services and still deliver a higher quality of service than ever before. This will require careful planning and the development of a long term strategy for managing both the infrastructure and the radio frequency space within buildings and campus environments. Radio Frequency spectrum management is a huge consideration that most companies do not really have a plan for. Development of an RF management and growth plan is essential as more services and layered network deployments are placed into the same amount of limited frequency space.
Develop a strategy for long term radio frequency asset protection
The fact that radio frequency spectrum is an asset that needs to be protected and managed comes as a surprise to even many seasoned network professionals. However, as an example; 802.11 wireless networks must coexist in a frequency space that is unlicensed and free for anyone to use. Devices coexisted in these frequency spaces long before 802.11 networks were deployed; devices such as cordless phones and microwave ovens are classic examples of this, but there are many more devices that are being deployed into networks with very little understanding of the ultimate impact on the overall network performance or long term needs. Therefore the planning and implementation of a strategy for the protection and management of this asset should be of paramount consideration to any organization that relies or is going to rely on it wireless infrastructure for delivery of mission critical services. The main issue is how to manage and plan for the current and future use of radio frequencies that are being used by more devices delivering more services with higher level of requirements and resource needs within the very real resource constraints that are available.
New definition of mobility
The classic mindset for wireless networks and wireless devices has been to consider them as an extension of the existing wired network. Mobility has been defined as the ability to move from place to place and use wireless networks as a point of use technology within these areas of defined wireless utility. This mindset has allowed wired and wireless networks to coexist but with limited wireless functionality. The new definition of mobility is the ability to take all the services that are currently being delivered with wired networking; including all voice, data and application services and use them while moving around and disconnected totally from the wired infrastructure. This definition is creating a real strategic as well as tactical dilemma.
Therefore, the development and implementation of an infrastructure strategy that includes the ability to leverage current and future investment into a cohesive plan that protects investment and assets allocation is imperative to any organization; or at least any organization that wishes to maintain its competitive edge as the industry move towards the inevitability of true mobility.
Wireless networks are evolving rapidly into very complex combinations of different services that are not inherently designed to work together in a seamless manner. Companies must rapidly develop strategies that will allow them to balance this range of services and still deliver a higher quality of service than ever before. This will require careful planning and the development of a long term strategy for managing both the infrastructure and the radio frequency space within buildings and campus environments. Radio Frequency spectrum management is a huge consideration that most companies do not really have a plan for. Development of an RF management and growth plan is essential as more services and layered network deployments are placed into the same amount of limited frequency space.
Develop a strategy for long term radio frequency asset protection
The fact that radio frequency spectrum is an asset that needs to be protected and managed comes as a surprise to even many seasoned network professionals. However, as an example; 802.11 wireless networks must coexist in a frequency space that is unlicensed and free for anyone to use. Devices coexisted in these frequency spaces long before 802.11 networks were deployed; devices such as cordless phones and microwave ovens are classic examples of this, but there are many more devices that are being deployed into networks with very little understanding of the ultimate impact on the overall network performance or long term needs. Therefore the planning and implementation of a strategy for the protection and management of this asset should be of paramount consideration to any organization that relies or is going to rely on it wireless infrastructure for delivery of mission critical services. The main issue is how to manage and plan for the current and future use of radio frequencies that are being used by more devices delivering more services with higher level of requirements and resource needs within the very real resource constraints that are available.
New definition of mobility
The classic mindset for wireless networks and wireless devices has been to consider them as an extension of the existing wired network. Mobility has been defined as the ability to move from place to place and use wireless networks as a point of use technology within these areas of defined wireless utility. This mindset has allowed wired and wireless networks to coexist but with limited wireless functionality. The new definition of mobility is the ability to take all the services that are currently being delivered with wired networking; including all voice, data and application services and use them while moving around and disconnected totally from the wired infrastructure. This definition is creating a real strategic as well as tactical dilemma.
Therefore, the development and implementation of an infrastructure strategy that includes the ability to leverage current and future investment into a cohesive plan that protects investment and assets allocation is imperative to any organization; or at least any organization that wishes to maintain its competitive edge as the industry move towards the inevitability of true mobility.
Monday, September 21, 2009
Wireless Wars
I don't think I have ever seen networking methodologies be so controversial as they are in wireless.
From a common sense point of view the use of non standard vs standards based 802.11 a/b/g/n make even less sense and the only reality that can be gleaned from this is the reality of the effectiveness of good marketing and network engineer ego.
If you couple this with the obvious lack of generalized understanding of what any of the acronyms really mean to device and end user performance you can very easily see how the FUD and confusion around this are allowed to persist and propagate. Bottom line is that you should NEVER sacrifice consistency for speed in production mission critical networks. The only excuse for this is lack of mission critical necessity, after all, if it is not important then use what you want.
But if it is important then it is important to make sure that someone besides the “wireless guy” make the call, also, that it be justified and in keeping with best practices.
I have yet to see anyone agree to use a beta patch on a production server, except under dire circumstance, most often these types of changes are coupled with a high degree of change control and a fair amount of approval.
Yet everyone seems very willing to be far more cavalier with wireless network design and authentication architecture, both of which are far more onerous and insidiously difficult to troubleshoot, diagnose and cause incredible end user dissatisfaction with the WHOLE network.
I would guess that this costs at least a billion dollars a year in lost productivity, wasted time and is a real talent sink because “if the wireless ain't working then I ain't working on anything else... “
KD5YDN
From a common sense point of view the use of non standard vs standards based 802.11 a/b/g/n make even less sense and the only reality that can be gleaned from this is the reality of the effectiveness of good marketing and network engineer ego.
If you couple this with the obvious lack of generalized understanding of what any of the acronyms really mean to device and end user performance you can very easily see how the FUD and confusion around this are allowed to persist and propagate. Bottom line is that you should NEVER sacrifice consistency for speed in production mission critical networks. The only excuse for this is lack of mission critical necessity, after all, if it is not important then use what you want.
But if it is important then it is important to make sure that someone besides the “wireless guy” make the call, also, that it be justified and in keeping with best practices.
I have yet to see anyone agree to use a beta patch on a production server, except under dire circumstance, most often these types of changes are coupled with a high degree of change control and a fair amount of approval.
Yet everyone seems very willing to be far more cavalier with wireless network design and authentication architecture, both of which are far more onerous and insidiously difficult to troubleshoot, diagnose and cause incredible end user dissatisfaction with the WHOLE network.
I would guess that this costs at least a billion dollars a year in lost productivity, wasted time and is a real talent sink because “if the wireless ain't working then I ain't working on anything else... “
KD5YDN
Monday, June 8, 2009
Monday, June 1, 2009
The pile up
I was fairly new to Ham Radio and lucky enough to have a good friend who was willing to help me "learn the ropes" as it were. In my first year of having my General license I was offered the oppportunity to do something really extraordinary. I was asked to go to the Island of Dominique and DX from there. It was an amazing experience. I had traveled around the Carribean a fair bit but this island was new to me and was a bit more of a remote experience than what I was used to. However I had a great place to stay, it was a one room shack out in back of a main house but the shack was surrounded by a quaint garden of native flowers including bouganvelia and other climbing flowering vines. The building did not have glass in the windows nor air conditioning but did have a nice breeze that flowed through most of the evening and was well kept and airy even in the heat of the day. I arrived at the airport and as is customary had to show my temporary radio operators license for the country as well as explain the equipment I was bringing in and the frequencies I would be using. All of this had to be arrange months in advance and sometimes deplending on where you go is quite tricky. After all, you have to apply for a radio operators license in a foriegn country and this can take time and effort. But it was all worked out and correct for the immigration and customs people and I was allowed to proceed with my two suitcases crammed full of radio gear and antenna's.
I set up the antenna and radio in less than 4 hours and with a little twitching and fiddling with an extention cord from the coffee maker, (everything was 50 Hz 220), I was able to convert and plug in a 110 outlet for my radio, power supply and PC, Magic!
I had carefully placed my log book and my pencil, fly tying kit for the expected boring times and everything else close at hand and was ready to go. I had managed to make one short QSL with someone in Texas and my radio seemed to be working well, therefore I was looking to talk to a lot of people that day. What happened was incredible, I was CQing and waiting for a reply when I talked to a guy who posted my call sign and frequency on a well used DX spotting site. I guess I had not realized that Dominique was a fairly desirable QTH because all of a sudden I was innundated with request for QSO. It was my first real experience with a pile up, which is what happens when you have so many people trying to talk to you at once that it is really tough to identify an individual operator to talk to, basically everyone talks over each other in a rush to get a QSO before the band changes and they cannot, or you cannot, hear each other. This was so frantic that I actually experienced some pile ups that went for over 6 hours without stop. I talked to over a 1000 different people over the course of 4 days of hard radio work. It was great fun. I made a lot of mistakes but everyone helped get me through it and everyone was patient and well mannered while we worked as many people as I could. I would wake up at 8am get on the radio at 8:30 and would not stop until 2:30 am. a fairly exhuasting schedule. But one that was worth every minute of it. In the end my ears were sore from the head set, my voice was tired and I was plain worn out. Great Stuff! I would do it again in a heartbeat. I talke to 1000 people in over 70 countries and the furthest was antartctica and China, Australia. Lots of Europeans and Russians as well as Kuwait and Saudi Arabia.
Truly a wonderful trip and one that I will remember forever.
Kd5ydn
I set up the antenna and radio in less than 4 hours and with a little twitching and fiddling with an extention cord from the coffee maker, (everything was 50 Hz 220), I was able to convert and plug in a 110 outlet for my radio, power supply and PC, Magic!
I had carefully placed my log book and my pencil, fly tying kit for the expected boring times and everything else close at hand and was ready to go. I had managed to make one short QSL with someone in Texas and my radio seemed to be working well, therefore I was looking to talk to a lot of people that day. What happened was incredible, I was CQing and waiting for a reply when I talked to a guy who posted my call sign and frequency on a well used DX spotting site. I guess I had not realized that Dominique was a fairly desirable QTH because all of a sudden I was innundated with request for QSO. It was my first real experience with a pile up, which is what happens when you have so many people trying to talk to you at once that it is really tough to identify an individual operator to talk to, basically everyone talks over each other in a rush to get a QSO before the band changes and they cannot, or you cannot, hear each other. This was so frantic that I actually experienced some pile ups that went for over 6 hours without stop. I talked to over a 1000 different people over the course of 4 days of hard radio work. It was great fun. I made a lot of mistakes but everyone helped get me through it and everyone was patient and well mannered while we worked as many people as I could. I would wake up at 8am get on the radio at 8:30 and would not stop until 2:30 am. a fairly exhuasting schedule. But one that was worth every minute of it. In the end my ears were sore from the head set, my voice was tired and I was plain worn out. Great Stuff! I would do it again in a heartbeat. I talke to 1000 people in over 70 countries and the furthest was antartctica and China, Australia. Lots of Europeans and Russians as well as Kuwait and Saudi Arabia.
Truly a wonderful trip and one that I will remember forever.
Kd5ydn
Wednesday, May 27, 2009
Wireless networks - Part One, The Dark Ages - Wireless and Bow Hunting
I have been working with wireless IP networking since 1994, my first wireless modem was a Ricochet Modem from Metricom, http://en.wikipedia.org/wiki/Ricochet_(internet_service), I was managing a network in Fremont and San Jose at the time and was constantly frustrated by having to dial in to Pacific Bell Internet Service in order to check on a finicky batch processing program for MRP that our company was using. I was looking for a way to do this wirelessly or at least on demand and started using this service. Looking back on it, it was actually pretty amazing stuff. I just happened to live in an area where they were deploying this service and decided to give it a try. I was trying to use wireless to solve a very real issue that I had and the service worked perfectly.
I am always facinated by the forerunners of actual mass adoption basically because it is often the case that we do not know what we have until it is gone. I remember that this service ran on 900 Mhz and had great range. It was very finicky to set up on Windows NT and required a serial port, Dial Up Networking Client and 3 toes of a rare south american bat to be put in the brew, but once you got it working, magic!
I bow hunt and had access at the time to a piece of property up by the Mount Hamiliton Observatory, I used to go up there very early and remember once sitting in my Ford Bronco in the dark and using my laptop to "dial-in" to the corporate network, check that the batch process had worked and then close up my laptop, put on my camoflage gloves, grab my bow and go hunting. I marvelled at how such brand new cutting edge technology could enable me to pursue such a base level and primative activity. Hey, it was not supposed to work, I was way to far from the modem I was using, but it did work through some environmental anomally that allowed the signal to bounce back and fore between my modem and the reciever on the other end, again magic!
One of the things that we need to remember over time is that it is the application of technology to enhance our lives that is important, not the technology itself.
KD5YDN
I am always facinated by the forerunners of actual mass adoption basically because it is often the case that we do not know what we have until it is gone. I remember that this service ran on 900 Mhz and had great range. It was very finicky to set up on Windows NT and required a serial port, Dial Up Networking Client and 3 toes of a rare south american bat to be put in the brew, but once you got it working, magic!
I bow hunt and had access at the time to a piece of property up by the Mount Hamiliton Observatory, I used to go up there very early and remember once sitting in my Ford Bronco in the dark and using my laptop to "dial-in" to the corporate network, check that the batch process had worked and then close up my laptop, put on my camoflage gloves, grab my bow and go hunting. I marvelled at how such brand new cutting edge technology could enable me to pursue such a base level and primative activity. Hey, it was not supposed to work, I was way to far from the modem I was using, but it did work through some environmental anomally that allowed the signal to bounce back and fore between my modem and the reciever on the other end, again magic!
One of the things that we need to remember over time is that it is the application of technology to enhance our lives that is important, not the technology itself.
KD5YDN
Subscribe to:
Posts (Atom)
