Selecting A Platform: Part 3

This is the third part in a series of articles related to platform selection for software startups.

In this article, we’ll look at how target customers and users might affect the choice of platform.  As always, there are no easy answers, but I find it helpful to look at some broad generalities that might sway the decision towards one platform (or the other).

Lets assume we can divide customers into three broad categories:  large enterprises, small/medium enterprises and consumers. 

Today, it seems that many large enterprises (particularly financial services institutions) have a learning towards J2EE (WebSphere/WebLogic).  Without going too deeply into the rationale for this leaning, suffice it to say that this is a fine choice and these types of customers have a lot at stake when picking a platform.  Its less a matter of individual products (and how they exploit a platform) and more a matter of the how their various “portfolio” of products can be made work together and how they can leverage resources (hardware, people, infrastructure).  Large enterprises are concerned with TCO (total cost of ownership) and will generally lean towards a platform that they believe will minimize TCO.  In many shops, this means J2EE – as the platform is already proven, they have internal resources that can support it and often large relationships with application server providers (IBM, BEA, Oracle, etc.) that they can leverage.

Small/Medium enterprises have a different set of challenges (and needs).  Often, these customers value simplicity (and short-term convenience) over any kind of perceived long-term benefits.  These customers also seem to have a larger volume of client/server applications, desktop applications (as they have not made the investment in switching everything over to the web).  As a result, Microsoft and its related technologies (Windows and .Net) seem prevalent here.  Many of the applications these customers buy also need to “integrate” with existing applications they own (like Microsoft Office).  As such, there seems to be a leaning towards .Net (and even classic Win32) for these shops.  They need something that the “IT guy” (possibly the nephew of the CEO) can install on a weekend.

On the consumer front, things get a little trickier and a lot depends on the deliver mechanism (hosted software vs. “packaged” software).  If you are planning on delivering a hosted application (using some type of web application), then the platform choice is not impacted as much by the customer – other variables will more strongly influence the decision.  If you are delivering a desktop application, the choice comes down to picking which operating system you want to support.  If its Windows (which in a large majority of cases it will be), then Microsoft ..Net is the clear path.  If its exclusively Apple’s Mac (which has a smaller, but more loyal set of users), then you would use any of the great Mac development tools.  If you’re looking to support both (Windows and Mac OS) you should look at frameworks/libraries that support elegant cross-platform capabilities (like Qt).  Be careful here.  If you build a cross-OS product using emulation or virtual machines (like Java) though in theory you should be satisfying both your user bases, you will often serve neither.  The windows fanatics will sense there’s something “not quite right” about the interface and the Mac fanatics will find that its not really a Mac application (and their dogs will bark at the screen indicating there’s something wrong).

Note:  If you are building an application that will be sold to large enterprise customers, but the users of the application will be departmental folks running the application on the desktop, and a rich-client is called for, the decision looks more like the consumer platform choice.

In the next installment, we’ll look at how the stage of the company might influence the platform decision choice.

 

Related Posts