Tuesday, October 7, 2014

Build versus Subscribe in a Platform World

Among the many attributes that are different in the world of running a business as a platform, one factor gets brought to the table with increasing frequency:  what’s our new investment framework for proprietary capabilities?
Think about it. The Build-versus-Subscribe decision for a business’ operating capabilities previously led to the creation and nurturing of large organizations of technical and business staff to conceive and implement new functions.  I remember one global bank during the Y2K “event” which cataloged its applications and concluded that over 80% of its operating capability was built in-house. This was a common profile.
The coin is flipping.  Most companies cannot afford to maintain large internal, dedicated staff to develop proprietary capabilities.  Further, they know that innovation comes from a “built for purpose” mindset, and that’s a characteristic of organizations that are serving markets, not unique situations. 

Companies are re-defining the decision criteria for investments in proprietary functionality.  Build-versus-Subscribe requires much more foresight than ever before.  I particularly like the vision of one forward-thinking client who uses a nice taxonomy of future-state traits to help inform the decision making around what his company needs to build for itself versus subscribe to a service.
The criteria for investing in the building of applications functionality centers on five fore questions:

ü  There is an absence of this capability available in the market.  Specifically, is there truly no Service available to which we can subscribe to achieve the functionality we need?

ü  The capability provides distinct competitive differentiation.  If not, then the functionality is common to others and we can gain access to it without carrying the burden of full ownership. We may need to prompt the creation of a market offering, but we don’t need to build the capability for ourselves.

ü  A proprietary capability will be distinguishing for our company over the next N years.  The time horizon varies by business circumstance, but this question forces a consideration of the time and cost to develop functionality in a market of fast-paced innovation. Absence of a market capability today might warrant some form of investment that is external rather than to build for oneself.

ü  The characteristics of the “ecosystem” are aligned with our business strategy.  This recognizes that no business functionality operates in isolation and that dependencies surround virtually every technology-enabled business process – whether built or bought/subscribed. If the source of a capability introduces undue risks or conflicts with the architecture or operating principles of the organization, this may be a significant factor in the decision.

ü  We have the opportunity to monetize our investment at a future date.  This is a speculative question, but one which is becoming more common as companies look to commercialize their innovations in a world of apps-on-demand.  In the past, investments in building application functionality used to be considered the cost of doing business.  Now, those spends are considered opportunities to generate returns more directly than just via improved business performance.
The implications of this move towards subscription over proprietary building of applications are many.  One of the most profound is around the talent required within the enterprise.  I think we will see the skills associated with integration, dev/ops, and risk management take a more prominent place in the organization of the future.  Core development skills will shift with greater pace to the service industry.



No comments:

Post a Comment