The basic building block of tomorrow's software is parameter driven parts. What is a parameter driven
part? Here's an example. Suppose you have a part named StandardWindow. Suppose you have these parameters:
- Title is: Edit Customer
- Width is: 300
- Height is: 400
If we have this part and parameters, we can pass the parameters to the part, and the part will decide what to
do. In this case the result will be a 300 by 400 window titled "Edit Customer".
The beauty of UHR is we pass the paramters to the part as a single bundle of data, not as individual
lines of code as other approaches do, such as Visual Basic, Delphi, Visual Age, Visual Cafe, JBuilder and Smalltalk
IDEs. This abstraction, the bundle of parameters passed to a part, is the new key to making the widespread use
of parts happen. Reuse relies on parameters, not code.
Now that we have seen what parameters and parts are, consider what they each do. They are specialists. Parameters
contain "what to do". Parts contain "how to do it". This magnifies the abstraction immensely,
because the parameters are what varies from system to system, while the same parts can be used in different systems.
We are reusing the concept of Interchangable Parts, one of the fundamental discoveries that made the Industrial
Revolution possible. We have taken this concept to the next level, Redeployable Parts.
Ahhhhh, but there's more. Parameters declare what to do, and the parts do it. We thus prefer to call parameters
"Declarative Knowledge" or DK. This is one of the cornerstones of the field of Artificial
Intelligence (AI). We are deliberately not using any other AI concepts in UHR in the early stage, and so we avoid
the problems AI has encountered. But later DK is a very sweet bridge mechanism when we need to tap into AI for
dynamic logic.
There's even more. DK can be stored as ASCII text. That text can be converted to the type of data bundle a part
is expecting, regardless of what language the part is written in. Thus UHR is language independent. The
Bean Assembler (BA) is the first example of UHR. The fact that it uses Java is merely because Java is the best
choice now.
Good gosh, there's even more. Different parts can use the same DK. For example you might need a RoundWindow
for one customer and a RectangleWindow for another. No problem. Use two different parts when assembling their systems.
DK is part independent.
As UHR systems grow in size and age, and the UHR industry of frameworks and parts matures, most of your investment
will be in DK. It is comforting to know that investment is language and part independent.
2nd Concept - Plugpoint Frameworks
Parts don't just work together magically. They need a surrounding framework they can be plugged into.
Consider your electric applicances, you phones, your PCs connected to the internet. They have to be plugged
into the proper socket to work at all and to work together. What's behind those connectors in the wall is an invisible
framework that supports the parts plugged into it. The framework and parts together make up the system. Our
definition of a plugpoint framework is a "part context" with specific points to plug in different types
of parts.
Each software domain, such as GUI, Persistence, Communication, Mathematics, Inventory, etc, needs a framework
and parts to be built before we can start assembling systems. Frameworks themselves are collections of parts. Some
frameworks are reusable across many domains, while some are not. Large systems are composed of collections of frameworks.
So we say, UHR replaces hand written code with parameter driven parts and frameworks.
3rd Concept - Domain Neutral Microkernel
What are all these parts and frameworks going to do? Lots of things, including collaborating, starting and stopping,
getting their DK, etc. To make this much, much easier we provide a foundational framework for all other frameworks
and parts to sit on top of. This is identical to the Unix or Linux kernel.
The microkerel is domain neutral to maximize reuse. It's small so that it's simple to understand and use, and
as we all know the smaller a piece of software the fewer bugs it has. The microkernel provides the standards upon
which systems are built, resulting in much more standardized, understandable, maintainable, extensible, compatible
systems.
4th Concept - Standard Archtecture
To create systems, you first create plugpoint frameworks that run on top of the microkernel. Then you create
parts that plug into frameworks. Then you create an actual system by creating DK to drive the parts. The DK
drives Parts plugged into Frameworks sitting on the Microkernel. That is our layered standard
architecture.
The designer does not start with a blank slate anymore when creating a new system. All systems have the same
architecture. Once you've seen one you've seen them all. This does wonders for productivity.
5th Concept - InnovativeVisual Tools
To assemble parts into systems, you can use text editors and manual file management. But this is kinda crude,
and is little better than hand written code. The real productivity of UHR occurs when the system assembler uses
various visual tools to do it. These can be designed in an entirely different way from old ones, because we are
DK and not code centric.
In the post code centric age, you design your User Interface and all else follows. This is the largest
area for improvement all across the software industry. We will soon see dramatic innovations such as speech input
and output, retina control, 3D conceptulization of data and workflow structures, UIs that morph to match the user's
needs, smart personalized virtual assistants and agents, wearable UIs, and the obsolescence of the keyboard and
mouse. Usability will graduate to Likeability. All this will tremendously empower the individual, with results
no one can anticipate.
Some parts and frameworks will need custom visual tools for maximum productivity. Some domains will need many
custom visual tools, such as those combining hardware and software. Many organizations will differentiate themselves
by the power of their visual tools, leveraging well designed frameworks and parts. However we hope this rush to
both use UHR and differentiate themselves will not splinter the UHR vision.
The visual tools may sound like an Integrated Development Environment (IDE), but they're not. We are not developing,
we are assembling. We are not debugging, because there's no code. We are not integrating anything awkward, because
there's so little to do and it's seamless. All we have to do is drop parts into a System Tree, edit their DK, and
we're done. Since we are not using code, this can be done while the system is running. The norm becomes evolving
systems as fast as you can decide what to change while the system is running. This is a mind blower....
The BA visual tools are currently first iteration, and are barely enough to prove the concept. Fortunately a
new round of tools is on the way due to the beginning of the BA Open Source work groups in February 99. Managment
must realize the visual tools are still immature and plan accordingly. Visual tools are currently where the
greatest investment in UHR needs to be made.
Up to now it has been impossible for users to create any of their own systems, except in limited domains such
as simple websites or simple relational database apps. Once we have mature visual tools and plenty of parts, UHR
will allow developers or users to create and improve systems of most types from scratch themselves. This opens
up entirely new directions for the entire high tech industry and those eager to merge with it.
"User Assembly", aka Personal Programming, is the arrival of the marvelous ability for users to build
their own systems from parts, just like our ancestors built their own homes and made their own clothes. The user
is now back in the driver's seat, and system creation is no longer only in the hands of the high priests of programming.
Most software vendors will fight this trend at first, but the foresighted ones will support it. Eventually users
will totaly drive the software industry, just as democracy finally became the norm. Their use of parts will be
monitored by Part Shops (vendors, user groups) who will respond rapidly to their Part Shop orders and patterns
of use.
Personal Programming will be seen by history as the return of power to the people, a type of social progress.
Putting the Concepts Together
Note how each concept has successively built on the previous ones. The latter concepts are not possible without
the former concepts. This is solid architectural design, where the key abstractions are correctly identified and
leverage each other. Lack of this is the reason similar attempts have failed, plus most were vendor centric.
Combining the above concepts yields the model below. Note the simplicity. Several people commented at BA Workshop
#2, "What I like about the BA is it's so simple!" This is indeed good news.
The blue boxes are a system we are building. The upside down pyramid of blue boxes is purposeful. A system has
lots of DK, some Parts, a few Frameworks and one Microkernel. The churn is where it should be, on the user's intentions
of what they want the system to do.
We now return to:
Industrial Revolution - The totality of the changes in economic and social organization that began about
1760 in England and later in other countries, characterized chiefly by the replacement of hand tools with power
driven machines, such as the power loom and the steam engine, and by the concentration of industry in large
establishments.
And the summary of UHR:
UHR replaces hand written code with parameter driven parts and frameworks.
Let's examine the potential impact one area at a time:
"changes in economic and social organization"
- To use UHR well requires reorganizing developer's roles (or new companies) into creating frameworks, creating
parts, creating visual tools and assembling systems. There will be clear economic and social differences in these
different roles. Managers must realize some serious structural changes are necessary.
"the power loom" - New tools
resembling complex machinery will appear. Their real power will be how good their User Interface is. To most users
these visual tools will _be_ UHR. The new types of machinery possible with UHR will hit like a tidal wave once
we see several large successes. Companies will compete with better and better power looms, but their real advantage
will be in masterly understanding of the underlying technology, especially the depth to which DK can be taken.
"the steam engine" - Later
replaced by electrical motors, this was the source of power for all other machinery. This role is played by the
Domain Neutral Microkernel. We will see vast tinkering with the kernel. New and better ones will appear, since
any top developer who understands the present kernel can create a new one in a month. Management must expect evolution
in the kernel, but help to avoid introducing incompatable UHR variants.
"concentration of industry in large establishments" - Currently software is a cottage to cathedral industry. The potential for individuals or
small sharp groups to invent whole new products still exists, and is somewhat the norm. This will eventually disappear
due to the appearance of massive high cost automated assembly lines using incredible mechanical/visual tools, sophisticated
parts, powerful frameworks and highly trained technicians we can only dream about today. This is similar to the
rise of billion dollar chip manufacturing plants. But this will take time. An interesting difference is the chips
are all the same, but the software/hardware systems will mostly take the mass customization route. Note the conflict
between this and Personal Programming.
"UHR replaces" - This is
radical change. It is also difficult change for those who are barely coping with software today, ie the 75% of
shops still at Level One, aka Unpredictability or Chaos Canyon. Most shops should not even try UHR until it is
more mature. Many coding cowboys will not survive when most coding disappears, because as UHR matures most "creating"
will be with UHR itself.
"parameter driven parts"
- Though promised a decade ago, UHR will make software parts a large industry. The average developer will use a
minumum of 2,000 parts. "Part Shop" tools will appear and be crucial to assembly. "Designer Parts"
that look different but do the same thing will appear. Internet based Part Shops will offer over 250,000 software
parts that are searched, downloaded, studied, tested and deployed in minutes. Parts will be as common as nails
and hubcaps.
"frameworks" - These are
100 times as hard to create as parts, and 1,000 times as valuable. There has never been a plugpoint frameworks
industry, but there will be. Framework specialists will appear, just as we have DBAs and Sys Admins today. Every
organization pursuing a market will need one or more. Companies will appear to create frameworks for you, or to
train you how to do it yourself, starting with their templates. There will also be Part specialists. The hot course
at colleges will no longer be Compilers but Parts and Frameworks. Part and Framework creation skills will be the
first that organizations will need to adopt UHR.
Adopting UHR - An Introduction
Now we get to the hard part. (pun intended. :-) Just how do I start using UHR in my organization? Well, this
is no different from major opportunities of any type.
First you must understand the opportunity. The Concepts above are a good introduction.
Next you must be aware of the ramifications. That was in Industry Impact and a bit in the Concepts.
Then you formulate a plan in the usual manner, with a risk free attitude as usual. Here's some ideas:
1. Get some UHR expertise.
2. Identify the individuals who have the potential to become Framework and Part Creators. It's nearly
mandatory that Framework Creators have built their own frameworks before. Framework design is downright difficult.
Many think they can do it well but can't. Be sure to get good people.
3. Do some small incremental improvements using UHR. For example do an in house tool, then convert some
table driven portion of a product to UHR. These are one shot types of work. You might even try a new small product
or a layer.
4. You now have some onboard experience. Identify a portion of your repeated developement that could
better be done with UHR. Pick a low risk one to start with.
5. Consider a Value Chain approach driven by a customer from end to end. Redesign things so you have
a highly defined process using UHR. Try it, and fine tune as needed.
6. Then spread UHR far and wide.
Possible Value Chains in approximate order of creation or modification are:
- Assembly, feeds external customers.
- Framework Creation, feeds Assembly. Later feeds Part Shop.
- Part Creation, feeds Assembly. Later feeds Part Shop.
- Part Shop, feeds Assembly.
- Solution Cycle (aka Sales), feeds Assembly.
As you can see, a traditional organization will not suffice. UHR is not hand coding in lots of different departments
with occasional collaboration. It is a highly engineered manufacturing flow with merge points.
Management should realize that UHR is in the Very Early Adopter stage, carrying all the potential for success
or failure that all new technologies invariably have. We define success as usefulness, not acceptance, which will
take care of itself if something is truly useful.. We hope this document contains realistic enthusiasm and not
hype. Good luck!
