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.
Peter