Note: You are experiencing only the raw content of this site, without the intended layout and design. Either your browser has ignored the Cascading Style Sheet (CSS) files for this site, or you are using an outdated browser which does not support Web Standards. Learn more.

EDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology

Read and respond to what the EDS Fellows have to say about the future of technology on EDS' Next Big Thing Blog on eds.com.

Will future business applications be built on shallow knowledge or deep knowledge?

by Tom Hill

The pundits estimate that most future business applications will be constructed using a combination of 10% custom code and 90% vendor-provided reusable software components.

The reusable components will take the form of new web services and conventional APIs. Should we be concerned that the percentage of custom business application code will diminish from 100% to 10% in less than 50 years? A more positive historian would say that code reuse will be moved from zero to ninety percent over this cycle.

The more alarming business question might be – How will we (or anyone) understand the new business applications that are constructed using vendor-provided software components. The future application will be developed and maintained using an incomplete and shallow knowledge of how (or how efficiently) a component performs a given task. Wait a minute, this sounds a lot like a major goal of object-oriented design and programming. So it can not be all bad.

Creating a business-critical application with shallow or incomplete component knowledge is unacceptable to professional Systems Engineers.

How do professional SEs gain deep knowledge of vendor-provided components? Before 1983, SEs obtained a deep understanding of packaged mainframe components by examining internal program logic documentation and source code. Yes, source code was delivered with most purchased IBM software components, making IBM and its customers the first open-source community.

Since February 8, 1983, when IBM announced an “object code only” policy, most commercial off the shelf product vendors do not distribute source code.

A restricted copy of source code is provided with open source community components. The phrase “clone and own” is used to describe the internal reuse policy of the open source community.

The “object code only” deployment of system components reduces our ability to fully understand the component. Vendor-supplied documentation provides the applications SE with a shallow knowledge of the component. Shallow knowledge can tell us “what [component event] just happened,” however, deep knowledge is required to understand “why the event happened and what event is going to happen in the future.”

Engineering research to gain deep knowledge of a component without source code need not stop at vendor-supplied documentation and product training. The professional SE eventually builds a model of significant components by a scientific method of;

Retaining a deep understanding of the complete operational environment (hardware, operating system, network, the architecture of similar components) and observing the component’s behavior.
Documenting a hypothetical model
Using the model to record algorithms and external structures to predict additional performance characteristics
Testing the component and recording limit behaviors to update the model

Published Wednesday, August 24, 2005 2:51 PM

Subscribe to this post's comments using RSS

Comments

Posted by Stephen Lissenden Wednesday, August 24, 2005 8:15 PM

Are applications created using 90% reusable components a cause for concern? I believe not.

From an innovation perspective any concern would seem to be founded on an implicit belief that that the innovation space, which it is useful to note is not bound by physical resource restrictions, would be diminish by this development and therefore any associated value generating opportunities would be adversely impacted.

My view, and possibly that of the positive historian, is that the development of <a href="http://en.wikipedia.org/wiki/Web_2.0">web 2.0 technologies</a> is a natural evolution in the toolset that is available to develop computer mediated experiences. As the move from assembler to the first high level languages enabled more engagement and innovation so to, these new developments will enrich the innovation space and provide more possibilities and opportunities rather than less.

Moving on to the concern regarding understanding these new applications, following your augument it would seem to me that if there is a demand, as your stated requirements for professional system engineers suggests there is, for deep knowledge, then continued use of 'black box' proprietery software may drive the following outcomes;

1) Shallow knowledge will lead to increased development and support costs (both from a financial and time perspective), which through impact on the client/user base, which ultimately will damage the vendor.
2) Deep knowledge analysis will develop as a service offering (commercial or otherwise) to the client/user base to mitigate perceived risks.
3) Clear and open communication, of which deep knowledge is an expression, will be identified, and more widely accepted, as a competitive advantage.
4) Open Source will increase in competitiveness by default.

Will all businesses want deep knowledge of their applications, probably not.

What will be highly valued? Deep trust maybe?

Posted by Mohamed El-Refaey Sunday, January 08, 2006 9:31 AM

I am new to this paradigm of software, in which less time and effort is spent in the custom or configuration code. as all of us (as developers like the code we are writing and came after alot of thinking effort in software algorithms), so changing to this way of thinking to only apply the integration model of specific vendor product will affect alot the way we think in software development totally.

Also, I'd like to know if I want to go into this direction of thinking or learning path of this paradigm, Do I need to learn something like ABAP language for SAP to use it in this integration model? or should I start with any other vendeor-specific product to know how far the code or custom specification will be done?