Which mobile platforms will businesses embrace?

July 31, 2010

Each day it seems like there are 10 new applications for your iPhone, iPad, Droid-phone, etc.  And as you might expect, Windows-based tablets, according to Steve Balmer of Microsoft in a recent CNET article, are due out later this year (2010) with a bigger push early next year.

Then there is the continued growth of e-readers from a variety of sources such as Amazon and Barnes and Noble, with some people projecting that they will replace paperback books in the near future.

And while each new platform may be attractive to one or more market segments of consumers — the real opportunity may be the level of adoption of a platform by businesses.

If you are a company like Airbus, Boeing, John Deere, Whirlpool or any other large manufacturing company, you have many thousands of employees and suppliers.  You depend on digital devices to communicate product design information and to facilitate the collaboration of your personnel — especially across geographies.   Today, the primary device is a personal computer, usually a Windows-based laptop.

But as we all know, laptops have their limitations and may be overkill in a number of situations.  For example, if you want to know whether a part is positioned correctly inside an airplane fuselage, you may want to refer to a digital image of the drawing (or 3-D model).  Trying to hold you laptop in one hand while you position the part with the other hand is awkward at best, especially if you have a large laptop.

What type of device is best (and most cost-effective) for this type of situation?

A laptop?  An iPad?  An e-reader?  Or perhaps just a Smartphone?   Many people would argue that “any of these might work, depending on the situation”.

However, since sharing digital data within a corporate environment requires secure high-speed communications, I believe the bigger question is “How many of these digital platforms will businesses decide to support?”

And given the cost of deploying internal networks with ever-increasing bandwidth and the costs of distributing and maintaining each platform — I believe that devices that can easily connect to existing internal networks and can quickly download content from existing servers through web-based clients are most likely to be adopted by companies.

In other words, I think that the corporate “hand-held device” market could easily be dominated by Microsoft — IF they are able to produce high-quality, high-performing, and easy-to-use products and get them to market in sufficient quantities in a timely manner.

What do you think?


Creating Product Features Instead of Feature Elements — a Key Agile Environment Challenge

July 11, 2010

Ever have one of those situations where multiple events all pointed you in the same direction?   Recently this happened to me on the topic of “feature elements versus product features” in an Agile development environment.

First I had a discussion with a potential client, then a friend was lamenting about incomplete features in his company’s latest sprint, and then there was the presentation by David Hussman on this topic at the July meeting of the Agile Bazaar.   So this is what I learned…

One of the fundamental ideas behind the Agile development methodology is that your development process is divided into small cycles or sprints.  The idea is that each sprint is sufficiently well-defined to allow it to be delivered to your customers.  And then your next sprint could focus on refining previously completed or new capabilities — depending on what the market (and your customers) need.  In this way, your product is theoretically ready to go to market at the conclusion of any sprint, so you don’t have to wait until all of your “planned development” for a given release has been completed (and tested).

However, this approach doesn’t accommodate situations where your product must include a certain set of related features (we’ll call them “feature elements”)  which cannot be completed in a single sprint and which your product really must include.

For example, assume that you are creating a word processing application which will allow users to create, save, edit, format and print documents in a variety of ways.

Your product MUST have the ability to “create a new document”.  Likewise, without the ability to “save” your changes and then “load” or “open” a previously saved document — the value of your product will be minimal.   This is why, most applications that deal with “objects” provide feature elements for performing “CRUD” (Create, Read, Update, Delete) operations.

Yet, some of these feature elements are much more challenging to implement and thus take longer to complete — often requiring multiple sprints — which is at odds with the Agile concept of being able to deliver the results of any sprint to your customers.

A modified Agile approach known as Kanban appears to resolve this conflict, because the focus is on delivering complete product features and not just feature elements.  In essence, a sprint is not suitable for delivery to customers unless all of the key elements of a product feature are completed.   Thus, to return to our word processor example, you might implement “Create”, “Save”, and “Open” in different sprints, but your product would not be distributed to potential customers until all of these product feature elements had been completed.

This development approach seems nearly ideal to me — but few companies seem to be using it and some strong Agile proponents seem extremely reluctant to embrace it.

So what do you think?   Is Kanban simply too new for many people to have tried it?  Or is it better in theory than in practice? Or is it simply not “Agile enough” for you to consider?

Do you have any experience with Kanban or know of any companies that have used it?  If so, what did you (or they) learn?

Would you trust your cloud provider to provide anti-malware protection?

July 4, 2010

The popularity of cloud services continues to grow.  The key players are companies like Google, Amazon, and Microsoft who are each spending a ton of money improving and promoting their services.

For companies who do not have the ability (or desire) to build and support their own web-based applications, a cloud-based architecture offers many advantages, including:

  • Scalability
  • Integrated database services
  • User authorization and permission services
  • Pay for what you need

However, there are a number of risks with a cloud-based application, including:

  • Large, visible, popular systems can attract malware attacks from bad guys.
  • Proprietary services make it difficult to change cloud providers.
  • Little visibility into how the internal services actually work and even less control.

And now there are a number of advocates for anti-malware capabilities in the cloud, including Phil Wainewright’s recent column and John Viega’s latest book  “The Myths of Security: What the Computer Security Industry Doesn’t Want You to Know“.   Their argument is pretty simple — the threats are in the cloud, so that is where the threat protection should be.  Frankly, I think their argument makes a lot of sense.

However, if your company has acquired cloud services from one of the key players — THEY decide what services are available to you.  And given the history of these companies and their propensity to build their own capabilities, it is very likely that they would develop their own anti-malware tooling and integrate it into their cloud platforms.

Thus the key question — Would you trust your valuable data and the future potential of your company to a cloud platform provider who has little, if any, history in successfully protecting its users from malware attacks?

I think that this issue has the potential to severely impact the growth of cloud-based computing, but will probably be ignored until the first major breach of a cloud — then the lid will come off and the finger-pointing will begin.

What do you think?

%d bloggers like this: