We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

What's better, custom or packaged apps?

Vote 0 Votes
As Mike Gilpin says in this Forrester blog, Packaged Versus Custom Apps: The Debate Rages On," It wasn't that long ago that packaged apps ruled the application delivery landscape and custom development was decidedly the second choice. Today, the decision is not so cut and dried, as firms struggle to find the right balance between the quick time-to-market of packages and the competitive distinction custom development can create." So what's better, custom or packaged apps?

11 Replies

| Add a Reply
  • user-pic

    Packaged apps are a result of evolution of custom apps. If five people are developing the same custom app with the same features, a packaged app appears. Since the mid-50's the custom apps always came first and then packaged apps evolved out of them. Even with large packaged apps like Oracle applications or SAP applications companies have realized that it does not pay to customize those to any extent. When a new release appears they have been hit with million dollar expenses getting the customizations to work with the new release! There will always be custom apps for unusual new business needs (like an innovative startup company) but eventually there will be packaged versions of them if they are needed in enough number. The new and exciting thing that is going to happen in five years time are that the majority of custom applications will updated themselves like iPhone apps!! No need to worry about migrations and such. That means that it better be highly packaged and zero customizations!

  • The simple answer is neither is better. An enterprise needs both. The question is akin to asking "what's better - peanut butter or jelly?" How often have we heard of just a peanut butter or just a jelly sandwich. Definitely not as much as we hear about a "peanut butter and jelly" or "PBJ" sandwich. Similarly, it would be rare to find an organization that did not have both custom and packaged applications weaved together. Make no mistake however that this by no means implies that both custom and packaged apps are the same. There are different reasons why a situation might warrant one over the other. For example, a core strategic business process most often requires a custom application in order to create and maintain maximum competitive advantage. Packaged apps typcially standardize "best practices". Since packages apps can be bought and used by anyone, they (and therefore standardized best practices) rarely yield a true competitive advantage. But if a business process (such as billing your customers) is routine (i.e. is not the source of your competitive advantage) then by all means leveraging a packaged app and customizing it makes perfect sense.

    The moral of the above is that one thing is rarely better than another in the absolute sense. It's the situation that might make one solution more appealing than the other.

  • Firms will definitely need a mix of custom and packaged in order to be successful. It all depends :) on the relative maturity of the business/function and the correlation between that automated function and business objectives.

    A critical business function that differentiates one's business from another may require a lot of custom application work. On the other hand, commoditized back-office operations can be fulfilled with packaged applications (on-premises or SaaS).

    For packaged apps, yhy reinvent the wheel when you can take advantage of all the years of experience, bug fixes, and "running with the herd" to get updates and such? Firms can then devote its energy and resources to building differentiation.

    A former boss of mine said (in effect), "buy for parity, build for differentiation". I think that is a great approach and can be applied to a variety of businesses.

  • Definitely packages/products for the common stuff that needs to be done. If these packages are truly open, they will (or should) deliver interfaces that can let you modify them as necessary. A truely Service Oriented Package/Product should do the basic things well and give you sufficient flexibility to modify it around the edges for what you required.

  • I'm glad Nari raised the issue of mobile app stores. We've been working with a number of our clients, advising them on their strategy for mobile apps. But don't think that just because an app in an app store is "packaged" from the point of view of the consumer using it, that this makes the "packaged vs custom" issue moot. Rather, the company providing that app still has to decide how to create it. Liberty Mutual custom-built a great app for its customers using the iPhone, that they can use in the unfortunate case that they have an auto accident and need to file a claim - they can do that right from their phone, including using its camera to take pictures of the damage.

    That app is clearly *better* than what Liberty Mutual could have achieved by using general-purpose mobile "middleware" to "mobilize" a packaged insurance claims app. The packaged claims app was probably designed at least ten years ago, perhaps 20 or 30, and has a user interface that lacks any concept of the workflow that the insured needs to follow at the accident site, because it was designed assuming a contact-center operator would be taking down the information when the insured calls in later on.

    So in this case, the right strategy for Liberty Mutual was to custom-build that app. To Nari's larger point, though, it's entirely possible that a few years from now the vendors of insurance claims apps may provide an iPhone app "front-end" that is "good enough" for many insurance companies, and at that point Liberty Mutual will be faced with that classic choice of whether it makes sense to try to sustain the competitive advantage their app gives them - assuming they invest to keep its capabilities ahead of what the vendors can provide - or to take the risk of migrating to the packaged option.

    Now that software is finding its way into more and more parts of our lives - so many more household devices and entertainment systems, transportation systems, and myriad mobile devices - this situation is just happening a lot more often, for those companies that provide those products that contain, or are, software. That's why we see a substantial proportion of the new custom software development our clients are doing today being for the mobile channel.

    So, even as the long-running trend Nari cites will continue - custom flowing to packaged - the "bow wave" of innovation sweeping through the market today is driving an increased level of custom development, in those areas that present new opportunities for differentiation through improved customer service, greater access to products and services, or faster creation and delivery of digital products and services. It's an exciting time, and that's driving a real shift in the dynamics of this choice for these enterprises. Throw in the effects of cloud, and it just gets even more interesting.

    Mike Gilpin is a Vice President & Research Director at Forrester Research. He will be speaking about custom vs. packaged apps at Forrester's IT Forum, May 25-27 in Las Vegas. Read Forrester's recent blog on using custom or packaged apps to deliver customer value.

  • Usually, both of them are necessary.
    I try to mix them via an enterprise pattern Platform-Enabled Agile Solutions (PEAS) - see http://improving-bpm-systems.blogspot.com/2011/04/enterprise-patterns-peas.html


  • I think the answer is increasingly open for change in two dimensions.

    I've often responded to questions on this forum by stating my view that the larger opportunity is in companies outsourcing whole business capabilities to partners and pursuing specialisation strategies.

    In one dimension, therefore, such a market means that only custom developed apps make sense since each specialised provider is delivering a discrete business service consisting of people and IT-enabled business processes (i.e. 'applications') that represents their differentiation.

    In the second dimension companies will do far less custom development overall as they will have acknowledged that most capabilities don't need any differentiation and have therefore outsourced them completely. In this context it's just that these standard services will be at the business not application level.

    Whilst SaaS is currently a big draw you have to consider the historical purpose of software packages - essentially to deliver best practice in a form that can be distributed to many organisations for whom that functionality doesn't represent a differentiating capability. As we're increasingly able to integrate complete business services as a result of falling transaction costs, however, why maintain a bunch of people doing non-differentiating work in the same way as everyone else through the leverage of packages?

    As a result my answer is that custom development will become far more critical even though the context in which it is applied by organisations will become much more narrow (as they outsource non-core capabilities and thus don't need custom or packaged apps for that capability any more) and integration focused (as they will exist in extended, cross-organisational value webs).

    I expanded on this a few years ago in the context of big, unwieldy packages such as SAP.



  • None and Both. The answer is Enterprise specific. Most enerprises will use both.

    The following key factors influence the decision of an enterprise:

    1. Gap between pre Packaged Applications and requirements.
    very large gap: do not even think about Packaged Applications.
    small gap: Packaged Applications could be the preferred alternative.

    2. Agility or high rate Change.
    Traditional ERP applications were build for Operationalpurposes not for change.
    Look for other alternatives such as Custom Applications or SaaS based Applications.
    Read Future Applications SaaS or Traditional

    If you still prefer Traditional ERP wait for a SOA based generation. Some but not all ERP Components, will be broken to Services and therefore will be more Agile.

    3. Long Term considerations - You will need to Develop, Maintain and Evolve Custom Applications. Packaged Application will be evolved based on other enterprises new requirements.

  • There will be both as long as both are offered by vendors without a lack of alternatives. Customers and analysts choose and rate based on what is broadly offered and not on what is needed. These are market decisions.

    One thing is however clear. The AppStores are a great thing and they will proliferate the use of packaged Apps in the mobile and PC world. That will also bring forward broader use of standard interfacing, which by the way has a good chance of killing SOA, because the much simpler REST is definitely the primary choice right now.

    The cost of delievery however is going to explode for SW vendors as they need to support multiple completely incomaptible platforms. The complexity of pushing Apps through the AppStore sign-offs and the different platform usage and licence rules will be another source of trouble.

    I propose that the future will be cloud-like backend services (even in the Enterprise) that can push model-driven process APPs to the platforms of choice. The Net-A-Porter Magazine that is also a content-driven WebStore and does not require new apps to change the complete layout is a good example of that.

    So in the long-term both packeged APPs and custom-coding will go away. They will simply be not affordable once an alternative takes grip. The APP-Cloud will for business-use not use hard-coded APPs, but drive consumer-interactive adaptive processes into a single APP frontend that executes the same way on all platforms.

    Remeber, you heard it first here!

  • I can't believe nobody asked for a "hybrid" model yet. It's the go-to way IT people avoid decisions.

    • I'm interested in what this 'hybrid model' might look like.

      For me, an example of the hybrid model can be seen in the comment from Forrester above: Liberty Mutual decided to build an iphone app to improve the way auto claims are submitted. The iphone app was a piece of custom development but it only captures the claims information and perhaps provides status updates.

      Behind the scenes, that iphone app must integrate into a claims management system (probably a packaged app or set of enterprise software tools) that will process the claim and make the payment.

      For me, I think too much emphasis is put on how difficult it will be for packaged application vendors to support standalone apps for different platforms (mobile or otherwise). They should all focus on building a top-quality API so anyone can customize the user experience of their underlying application. This would let customers, business partners and system integrators to create tailored solutions on top of their software. Over time, they could also build their own apps using the API or buy up third party applications built by business partners.

      This strategy, broadly speaking, worked for Twitter so it might be a good opportunity for enterprise vendors to learn a trick from the consumer web.

Add a Reply

Recently Commented On

Monthly Archives