Platform or Application?

Platforms are often criticised when compared to applications for delivering IT solutions. They rarely offer the same richness of features and can often be more complicated to set-up. But that doesn’t mean they are without their own benefits

When introducing new or replacement IT solutions, one of the first questions when deciding on a suitable technology should be: Platform or Application?

Platforms provide shared services that can be re-used across multiple different solutions on a company network. The most common are identity management (providing login, authentication, access permissions), communications (email, diary, instant messaging) and file storage along with a common user interface and programming model for integrating applications. Platforms are designed to be used for multiple purposes. They compromise richness of features within individual solutions for enterprise performance and scalability, resulting in lower overheads and operating costs.

Applications focus on specific individual solutions. They can vary significantly in size and complexity, from niche functional solutions through to large-scale enterprise applications managing entire business processes. An application can be just as big, and bigger, than a platform deployment. The specific focus means features are usually richer than the equivalent capability provided by a platform. And the cost of building an individual solution may be lower than creating the same solution on a platform. However, any cost advantage can be lost when business requirements stretch beyond an individual solution. Each application typically contains its own set of services and interfaces with separate training and management needs, and requires different skills and expertise to configure or customise.

To give an example – building intranets…


IBM, Google and Microsoft are not the only platforms in the Intranet playground, but they have the majority of market share across all organisation sizes. Most organisations will have standardised on one of these three for the basics: login accounts, email/messaging, calendaring and basic file storage. All three platforms offer solutions for building Intranets: IBM Connections (formerly Lotus), Google Sites and Microsoft SharePoint.

On the right is an alternative scenario, using applications instead of a single platform. WordPress is an open source web content management system. This web site is built on WordPress. We are big fans of it. If you want to build web sites for publishing content with blogging capabilities and integrating various social media tools, it would be quicker and cheaper to do on WordPress than on SharePoint. But what if you wanted to move into file sharing and collaborative working? That’s not really what WordPress is designed for so you may need to consider other applications such as Huddle or DropBox. Want to move into social networking? On the application side, there are solutions such as Yammer. In all cases, richer in capabilities than the platform equivalents but you now have three sets of user credentials to maintain, on top of the platform that is still needed for the basics such as email.

And Yammer highlights another consideration. Applications have a tendency to get acquired. Yammer was acquired by Microsoft in 2012 and is now in the process of being integrated into the platform. That’s great if you’re an existing Microsoft customer. But what if your base platform is Google? Do you stick with Yammer or look to migrate to something else? Has your platform evolved to the point it now includes the capability?

This is why the business vision and technology strategy should drive the decision between platform or application when introducing new solutions. Organisations may be willing to sacrifice ‘best of breed’ features in return for the reduced complexity and operating costs offered by a platform. Equally, an organisation may decide that competitive advantage can only be achieved by using the best available application for a given solution and any additional costs are more than justified. For some organisations, IT simply isn’t given the budget to cover all requirements and has a remit only to provide core services using a platform. In which case, departments may have their own budgets and freedom to deploy and manage additional applications appropriate to their needs.

In most cases, the choices come down to three options: platform, enterprise application or niche application and the following table gives a rough outline of the decision criteria for an Intranet project:


The platform should always be the first consideration, simply because it is already in-place providing core services such as a network login account, email address and file storage. It is prudent to first examine whether or not existing technology investments can satisfy the requirement. Platforms include a common user interface and common programming models meaning existing skills and expertise can also be leveraged. If the in-place platform is Microsoft, then the intranet capability would be served by SharePoint.

An enterprise application is more likely to be considered when the requirements will stretch the built-in capabilities of the platform and require extensive customisation – the ‘build versus buy’ argument. In this example, solutions like Interact-Intranet contain many similar capabilities to platforms like SharePoint such as: web content management, forms and workflow, search, user profiles/staff directory. But unlike platforms, enterprise applications are focused on a specific scenario enabling richer development of relevant features. The downside is that they usually require dedicated skills and expertise to configure and maintain. You don’t choose an enterprise application to save costs.

A niche application is the most likely choice when requirements are focused on a very specific scenario, for one of two reasons. 1) Features are needed that are simply not available in mainstream platforms or enterprise applications. Either because the features are very new – emerging trends that may offer a competitive advantage for early adopters – or because the features are highly specialised, often specific to an industry or market. 2) There is a need for a standalone solution without getting bogged down in enterprise demands regarding performance, security and scalability. Usually because there simply isn’t time and/or the risk is justified or because the solution is a pilot for evaluation.

I used intranet projects for this example because I have worked with clients where each of the above options has been appropriate under different circumstances. There is no single right or wrong answer when deciding between platform or application(s) for a new solution. But it is important to consider dependencies when making technology choices.

This article was originally published on