ommended by internal champions,
vendors, and industry gurus but could
not seem to make them work or make
them stick. Perhaps they reached for a
package-driven solution but could not
tune it sufficiently to make it a market
differentiator. But some companies
simply threw up their hands in despair
and chose to pay vendors to build their
This outsourcing approach amounts
to an abdication of the task of extending and operationalizing their vital
business knowledge. In the face of
the increasing challenges of complexity, technology, market speed, and the
perceived difficulty of acquiring skilled
staff, these companies are giving up.
This seems to be most prevalent in
large, hierarchical enterprises where
cost and profit are the driving forces
coupled with a lack of understanding
of the knowledge economy and what
these systems really mean.
This is sad and it is dangerous. In
their pursuit of a low-cost “solution”
or perhaps in pursuit of an easy management life, these companies may
be surrendering their key assets and
At the other end of the spectrum, there
are companies that, intentionally or
accidentally, slip into the practice of
building systems they have no busi-
ness building. While they are boldly
stepping up to the challenge of speci-
fying, designing, and building the sys-
tems that operationalize what they do
for a living, they are also being side-
tracked into building things that are
not vital knowledge, that are way off
their mainstream business functions.
Developers may argue they need cus-
tom “bespoke” infrastructure, 2 test
management systems, development
environments, data access methods,
even programming languages. They
convince the business resourcing de-
cision makers of the inadequacy of
available solutions and are given the
go-ahead to build their own.
This approach is seductive. The bespoke solution theoretically supports
the core business function, it seems to
leave the development group in charge
of their own development destiny and
the hope is that the solution will be optimal for the business. But it can be a
misguided and expensive investment
and it is often driven by a quite different and more personal agenda.
Learning and Creating
Software development is both a learning and a creative activity. These two
forces—to learn and to create—are
among the strongest motivators of
software engineers, particularly if they
have the chance to learn and create
something “new.” New to them that
is. The fact that others have already
learned and created the executable result of that learning may not be a big
consideration to the developers as they
pitch this idea to their executives.
This “grow-your-own” approach
seems to be most prevalent in organizations that are technology driven,
particularly those that have had innovative technology successes in the past.
But when it deflects from operationalizing the primary business knowledge
it is a bad thing.
The differentiation into vital and supporting knowledge is not as simple as it
might seem and I will explore this issue
in more depth. But as companies navigate their way into this new era of executable knowledge, they surely need to
know what they need to use and know
what they need to own and manage accordingly.
If they want to survive in the Age of
Knowledge, that is.
1. Drucker, P. F. Post Capitalist Society. Harper Business.
2. Spinellis, D. Bespoke infrastructures. IEEE Software
31, 1 (Jan./Feb. 2014), 23.
Phillip G. Armour ( firstname.lastname@example.org) is a senior
consultant at Corvus International Inc., Deer Park, IL,
and a consultant at QSM Inc., McLean, VA.
Copyright held by Author.
is both a learning
and a creative
availability of resources to match those
needs, and synchronizing these needs
and resources. In a rapidly changing
event-driven marketplace, the optimization of these functions was the key
to servicing customers and the key to
profitability. Even slightly better optimization could pay off handsomely and
would allow the company to outperform their competitors and to thrive.
To do this optimization they used a
combination of experienced schedulers and sophisticated computer systems driven by linear programming
algorithms. Around the time I worked
with them, this company was seriously
looking at outsourcing its HR systems.
Fair enough. But it was also looking at
outsourcing the development of the
next generation of its equipment leasing optimization systems. The first option was ok—they needed to use an HR
system and it made no sense to spend
scarce company resources to build one.
The second option was not ok—leasing
equipment optimization was what this
company did. It was their key skill and
their market differentiator. Outsourcing this development would essentially
be paying someone else to learn their
business better than the owners. It is a
very dangerous strategy. Ultimately the
company chose to enter into a collaboration agreement with a small development firm to build the next-generation
optimization system and so retained
some ownership of its vital knowledge.
But not all businesses do this.
Twenty or more years ago many businesses bravely stepped up to the challenges of the day and built large,
complex, and valuable systems that
operationalized their vital business
knowledge. Now those systems are old
and they are running out of gas. They
need to be updated to incorporate the
knowledge of the modern marketplace and technology infrastructures,
to make the systems extensible and
scalable, to incorporate new distribution channels and strategic partnerships. Long-established companies
are struggling with this challenge and
some are retreating from it. Perhaps
they have tried revamping these vital
assets but were unsuccessful. Maybe
they attempted the software process
and productivity improvements rec-