Infosys Microsoft Alliance and Solutions blog

« Expression Studio 4 Available | Main | Small but effective points to notice during implementation in Cloud- Part 3 (Cloud drive) »

Defining the Application Portfolio using the "EXIST" framework

As the wise-men saying goes - "Do not put all your eggs in one basket" - it is prudent to diversify the application portfolio like the investment portfolio to reduce the risk arising due to dependence on one technology, vendor, consultants and architecture model. The reason why investments are diversified is the element of uncertainty and the risk of assuming that everything will go well with the investment I choose. Besides that there is an element of individual financial goal and the outcome (duration, amount, and criticality) which drive the instrument (along with its associated risk or lack of it).



It's a high risk high return scenario even in the case of application portfolio. However, since the entry barriers are large and the level of involvement is much greater (with multiple business teams and CXO level leadership involved), it may not be that simple a comparison.

What got me thinking?
In one of the recent discussion with a client, I realized that they had limited themselves to one application over the last 8 years. They kept on extending the application (read customize as per whims and fancies of business users) without a proper control or need to get answers to few basic questions -
·  Does this business process need to be build into the application?
·  Is there a business need to invest on existing application for meeting this need?
·  Is this a temporary business need or process would be used on an ongoing basis?
·  Who will own this new development for future?
·  What will be the impact on the product - its stability, performance, upgrade path?
·  Does it impact any other aspect - overall governance, reporting, BI, integration, and backup?
Now, they were at cross-roads when the vendor company put this product out of support and newer technology and business trends along with environmental challenges were forcing them to move away from this investment but the burning question is where?

But isn't this approach against the common belief - Centralize & Reap Profits?
It has been a common recommendation over years from several 'big' vendors that there need to be  a single, robust, scalable, integrated application that can be managed with a common roadmap, support staff and technology leading to a simple IT environment. Needless to say that these were primarily due to -

  • Vendors acquiring niche companies and trying to incorporate these solutions in form of some loosely coupled solution architecture under a common brand name
  • Vendor applications having a lot of investments over time which led to product being bulky and integrated in such a manner that the nimbleness to adapt to business was lost (this is also called - "My Way or Highway")
  • License revenues are something that no vendor would like to lose. This has led to ERP spreading their footprint from simple applications to extending in all directions to cover niche processes, collaboration, optimization and intelligence.

Many of the clients who approach us come with problems because of this mindset. This is very much responsible for the mess that several companies are in! The reason is simple - any changes to the system need a tremendous amount of resources (time, effort, investment) with longer RoI durations. Sometimes by the time the business gets to use the application - either the requirements have changed or the environment in which the business operates has changed.


Is there a way out?
Several service companies today focus on application portfolio services and advise the clients on the way forward around defining, implementing and maintaining the right-mix of solutions/products that need the meet of business without leading them to a situation where they are bound by the choice they made and these choices defining the business strategy rather than the other way around.

I am not proposing a breaking new model or a revolutionary framework.  The idea in this blog is to share and invite feedback from esteemed peers around this topic. We do use it to sensitize our clients on this aspect and help them achieve the end goals by focusing on the application portfolio and its balancing as per their business needs.

The "EXIST" Framework
The 'EXIST' framework simply classifies the application needs on the basis of 'purpose' of the application. This helps in laying down some standard decision making criteria while choosing on the application types. This does not mean that there are solutions or packages that do not cut across this segmentation.


What this simply says is that recognition of these needs leads to a more informed decision with a solid business case backing the decision making process. Some of the factors that can vary across this classification are sponsorship, business needs, goals, benefits envisaged, duration of use of application, legal & regulatory constraints, Local/Country level regulations, Language needs, extent of change in process, uniqueness of the business need and the impacted line of business & user base. This also decides the mode of delivery of these applications - On Premise, On Cloud, Hybrid.
The framework, essentially, breaks the applications into 5 categories based on the "purpose" for which they will be used.


Application Purpose


Typical Business Need

RoI horizon

Mode of Delivery


Essential (E)

They are the 'core' of transactional processing and manage the day to day operations for internal processes

Finance, Asset Management, Reporting, Sales and Purchase Order Processing

Long Term

On Premise


External (X)

Needed to respond and connect with Government/Regulatory bodies, compliance,

Imports/ Exports, Government Reporting, Taxation, Bank Reconciliation

Mid-Long Term

On Cloud


Initiatives (I)

The processes may not be defined for such business needs and actually this may be to meet an emerging market need (new business line, new geography)

Campaigns, Event Management,

Short Term

On Cloud

Business Heads / Line Managers

Set-Apart (S)

These are the USP of business and the uniqueness of the process is what sets them apart from competition. Any improvement or optimization can lead to great business value to the organization

Planning, Scheduling, Workflows, Cost Accounting

Long Term

On Premise

CXO / Business Heads

Trade (T)

To collaborate in the 'new' economy where real time connection is needed with Vendors, Partners and Customers

Extend on 'core' system to help in real time availability of data like VMI, Real time order status updates

Mid Term

On Premise / On Cloud

CXO / Business Heads


Is this the solution?
No...this is the beginning of an exciting journey of facilitating a decision making process that looks at business case, external needs, what is available on hand, what is the optimal way ahead and where do we finally put all our eggs. Are you strengthening the basket that somebody else made or rather choosing the right set of baskets to put the eggs....???




Hi Sachin

I have different opinion on this as i think of following Points :
1. Incase of ERP applications are designed in such a way that they can handle nearly all business needs whetehr they are long term or short term on the top of it there are vertical solutions available which provides the specialised solution specific to the business needs. Further ERP 's are being developed or owned by the product companies which have a long term product plan which ensures that the applications continue to run for years to come and the patches are released by the organisation on time to time basis to support any new requirement/ limitations / bug associated with the application.
2. Even the product when it is going out of the support from product company Users ( Currently it is 8 years ) in most of the cases which is avarage life time of ERP in SME space the new versions are available to customer as onestop option at a cost. Upgrading costs & efforts for the customer to new version will be much cheaper and lesser since he is managing the single technology stack of system, and he need not worry for other issues apart from implementation like Training,integration, Complexities. Apart from this he will have better ROI of existing investment he has made,
3. Apart from that all the components of single stack of technology are not replaced in one go and new versions are designed to be compatible to support backward applications
How ever you have righlty pointed out that Several service companies today focus on application portfolio services and advise the clients on the way forward around defining, implementing and maintaining the right-mix of solutions/products that need the meet of business without leading them to a situation where they are bound by the choice they made and these choices defining the business strategy but the difference here the application portfolio services looks all these requirements first and come up with a solution which is in best intrest of the customer which could be single stack of technology in most of the cases especially where ERP applications are considered how ever the case where a set of multiple applications are running in the client environment EXIST Framework definitlely applies.


Pankaj Kant

Thanks Pankaj for your insights and feedback. I really appreciate the details.

On point 1, I feel the ERP were never meant to be customized beyond what they can do best (back office processing). The extension to CRM/SRM and Collaboration is what is being done and is in product roadmaps, as you rightly said. Problems comes in areas which are in XIT areas of EXIST for which there are much leaner, faster to install and industry standards available from SaaS vendors on the cloud. Due to dynamics nature of the XIT components and dependency on external parties/regulations (for XT part) – the ‘nimbleness’ is missing. Most of the XIT areas are not addressed even by big ERP vendors.

On Point 2, in almost 5 to 6 new prospects, we have seen the cost of upgrade is ‘not always’ lesser than cost of replacement. This is specially so in case of heavily customized applications. Also, there is one important point that we miss while computing the TCO. In case of XIT components some of the processes are actually on the cloud; so there is no technology investment and time to market is reduced. We are not talking of multiple ERPs in this scenario; but possibility of ERP, Niche, BIC and Best of Breed solutions working together as per need. I agree that this would not be true in all scenario and hence an element of consulting is needed to define the ‘optimum’ application portfolio.

On Point 3, while the product vendors do talk about backward compatibility, it is the ‘level of customization’ of the original product that can make or break this promise. Of course an upgrade is the first choice, but again EXIST framework can give an opportunity to prove/try to evaluate and suggest an alternate strategy which should aim at reducing the TCO in the long run for the client.

The problem today is that many of the consultants are still proposing one stack/single-ERP-fit-all solutions which are lead to problems 5-6 years down the line. They work well today; lead to lower upfront cost – but the cost of maintenance and upgrade along with the opportunity lost (due to delays and longer time needed to build all these in one ERP) is something that is not given a due consideration. Developing anything is possible in an ERP, but frequent disruptions to production environment, longer time to market, greater stakeholder management, greater change management are some of the challenges which also have to be factored in once the application portfolio is decided.

Once again, I really appreciate you bringing forth the other point of view which has made the discussion stronger and I am sure there are scenarios where what you have mentioned would be the best way ahead while defining the application portfolio. Looking forward to your thoughts. Thanks!

Hi Sachin

Thanks for taking my feedback on positive node

We tend to face such situations where in our discussion with stake holders we encounter such scenarios. The client is running a version of enterprise application integrated with multiple systems of his vendors & clients He had given the option either to upgrade to newer version of the same application or to replace his current application set to newer platforms .The client immediately tells they are pretty happy with the application which currently they are running but it has certain shortcomings which they foresee will be available with newer version.
Also these days The applications architectures are now being defined in such a way that custom code resides on altogether separate layer so its easy when migrating the code & merging it with newer versions.
In one such discussion I had with my client they out rightly rejected the idea of changing the platform as they had their own fears:

1) They had their own limited no of people in their IT Team to manage the systems and they feel it will be problem to have multiple skill set people to manage the system due to budget constraints.
2) They did not want to be dependent on the service providers for each & every issue
3) The wanted a simple and yet robust solution which can be managed effectively by in house IT team without having worry for complexities involved in managing, implementing & integrating disprate technologies .
4) The end users are pretty familiar with the application running for years any change in that will pose serious issues with their day to day operations efficiency.
5) Training end users will be additional issue with the Client Stake holders .
6) The new Applications are not tried and tested in their business environment and they have fears how it will work. And whether they will be able to achieve their objectives
7) Integrating with their business partners / customers/ vendors will be another issue since they may/ may not support the change.

Further in case of any new business specific requirement the first call comes up from the client to make change in the application because of given fact adding a specific functionality to the application will not be as high as implementing a new system altogether . As you agree the average time frame of ERP solution is 6-8 Years which is good time to justify ROI of the solution also the business dynamics is changing such rapidly a technology tends to phase out by the time it matures . and having multiple systems being phased out to maintain the business running will be much more tedious, costly, complex and time consuming specially with SME’s

But now to some extent i can visualise that EXIST Framework is much beyond the concept and definitely can help stakeholders to select right solution for thier business needs



Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter