Communications of the ACM
The business of software
Owning and Using
Credit: iStockPhoto.com
Modern companies have systems they need to use and systems they need to own. But there seems to be some loss of focus in the management of these two categories of capability and this may be quite dangerous to the future of the enterprise.
In his seminal work Post Capitalist Society1 the late management guru Peter F. Drucker noted the world has left the era of capital and has now entered the era of knowledge. The cash and hard asset economy is receding and the knowledge economy is on the ascendant. Money is still important; possessing a mound of cash will assist you in consumption, but it may not help much in construction, in building things, in acquiring knowledge. According to Drucker, the critical success factor these days is knowledge: the ability to store and employ knowledge and the ability to create and operationalize it.
Trends and Means
In dealing with a number of situations, companies, and government agencies in the last few years, I have noticed a few trends that are quite disturbing. Two of these trends are contradictory and they relate to how companies build and use computer systems.
If we are indeed moving into the knowledge economy, where knowledge is the defining and limiting asset of the world, we are confronted with the issue of where to keep the stuff. As I have noted in my previous Communications columns,a we are now moving all the knowledge of the human race from the media of brains and books into an executable software form.
If knowledge is the key asset of the future, then the ability to create or discover that knowledge is the key wealth-generation activity.
If knowledge is the key asset of the future, then the ability to create or discover that knowledge is the key wealth-generation activity. Since that knowledge will be stored mostly in software, software development should (and will) become the driving force of the new economy. But do companies and countries understand this? If they do, then do they behave as if this capability is the engine of growth that will allow them to flourish in the future? In many cases, it appears not.
What You Use, What You Own
There are two kinds of operational capability that companies need. They involve systems that execute "supporting" knowledge and systems that execute "vital" knowledge.
Supporting knowledge is the operationalized knowledge that companies require to support their business. Companies must pay their employees and pay their bills so they need access to payroll and accounts payable systems or services. But few companies need to know how to build these systems. The same is true for many types of capabilities in many types of companies—they need to be able to use the knowledge in these systems, they do not need to own it.
Vital knowledge is the operationalized knowledge of what the company does for a living, why it exists. This knowledge, how it is obtained, how it is built upon and, most importantly, how it is operationalized (in the software form) is the most critical asset for many companies. Organizations need to own this knowledge in all its forms, especially the executable ones. But many companies do not realize this.
A New Life on Lease
Years ago I worked with a transportation equipment leasing company. Their primary function was predicting the equipment leasing needs of their customers, forecasting and managing the 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.
Abdication?
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 recommended 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 vital systems.
Software development is both a learning and a creative activity.
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 their futures.
Bespoken For
At the other end of the spectrum, there are companies that, intentionally or accidentally, slip into the practice of building systems they have no business building. While they are boldly stepping up to the challenge of specifying, designing, and building the systems that operationalize what they do for a living, they are also being sidetracked into building things that are not vital knowledge, that are way off their mainstream business functions. Developers may argue they need custom "bespoke" infrastructure,2 test management systems, development environments, data access methods, even programming languages. They convince the business resourcing decision 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.
Own Knowledge
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.
References
1. Drucker, P.F. Post Capitalist Society. Harper Business. 1993.
2. Spinellis, D. Bespoke infrastructures. IEEE Software 31, 1 (Jan./Feb. 2014), 23.
Footnotes
a. Starting with my first Communications "The Business of Software" column: P.G. Armour, The case for a new business model. Commun. ACM 43, 8 (Aug. 2000), 19–22; DOI:10.1145/345124.345131.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2014 ACM, Inc.
No entries found