We are thinking at a high level of abstraction here, because that's what it takes to see the true essence of anything. An eagle eye's view let's us see that UHR is a structural change rather than an incremental one, because UHR completely changes the way we design, implement and maintain systems by systematically using several dozen concepts, without negatives such as vendor lockin, lack of extensibility, domain limited, or code centric. It's well known that structural change offers much larger benefits than incremental change, typically an order of magnitude greater.
None of the "20 to 30" concepts are new inventions, except some near the final phases. It's their organization that's new, and that organization of concepts is what UHR is.
This will be hard for some to understand, because they are used to defining differences with discrete elements, and don't think architecturally. A good example is feature lists, which is really a procedural viewpoint. Dear reader, please don't you fall into this trap too. Instead, shift into overdrive right now! UHR is an Architecture, not a long feature list. UHR is a Framework for Frameworks. UHR is a whole new mindset. UHR gives software gravity, because user intentions always have somewhere to fall without coding. (Trying hard to click on that light bulb, for that moment of sublime insight. :-)
Component Based Development (CBD) is also structural change, and is very similar to UHR. However, it has the negatives mentioned above.
How to Finally Understand UHR
In general, procedural or code centric types will be unable to deeply fathom UHR, but true OO and Plugpoint Framework types will have an easy meal. Software shops and developers at Level One (Unpredictable) will mostly just use UHR tools and parts, while those at Level Two (Repeatable) or above will also build their own tools, frameworks and parts.
If you feel you haven't grasped UHR to the core, try this exercise. Draw a blank Technology Grid for the first 4 phases. Use the computer electronics industry instead of software. After all, Moore's Law has been working like magic, and the computer industry is software bound, not hardware. UHR has borrowed many ideas from electronics, such as Messages, Datatrons, Parts Assembly and sophisticated visual tools.
On the Part Centric phase, the Mechanisms are circuit boards and connectors, plus diodes, resistors, capicators, transistors, etc. On the Microkernel phase, use the BIOS, CPU, bus, OS, etc. On the Ease of Use phase the Mechanisms will include drawing tools that generate circuit masks, simulators, fabrication lines, etc. On the Parts Management phase look at the EDA industry (Electronic Design Automation) tools that handle over 250,000 internet based parts today.
Your grid (the 4 phases of the electronics industry) has grown by incremental improvement over the last 20 to 30 years. UHR is just an accelerated master plan to shorten decades to years.
Pseudo Versus True Structural Change
The three Meta Concepts Structured Programming, Object Oriented and 4GL IDEs are strong attempts at structural change. But history now shows they have failed to improved productivity at the level of an order of magnitude.
Structured Programming, while a huge contribution, only improves implementation in a single method. It's just better coding at the method level, and doesn't even encourage reuse.
Statistics are software productivity has improved an average of only 4.5% per year in the last 50 years, and is actually falling in the last few years. Thus these three Meta Concepts are "pseudo structural change". Pseudo means "appearing to be true, but actually being false." What has really happened here? Why have these prominent Silver Bullets failed?
My best guess is they have each provided an insufficient foundation for large change. Without a certain "Critical Mass", a productivity explosion will not occur.
The software industry is obviously still immature, and has yet to reach critical mass and take off. For example, for the Wright brothers to fly 120 feet in 12 seconds in 1903, they had to first:
- Create reliable aeronautical data with their own wind tunnel, amassing more data on wing design than anyone before them, and compiling tables of computations that are still valid today.
- Discover that a long, narrow wing shape was the ideal architecture of flight.
- Figure out how to move the plane up and down on a cushion of air.
- Figure out how to control yaw with rudders.
- Develop a forward elevator to control pitch.
- Devise a pully system to warp wing shape in midflight to stop lateral roll.
- Design the first effective airplane propellers, twin 8 footers of laminated spruce, that turned in opposite directions to offset the twisting effect of each other.
- Pick a launch site with a steady favorable breeze, at Kitty Hawk, N. C.
- When they found a lightweight gas-powered engine didn't exist, they designed and built their own 12 hoursepower engine weighing only 152 pounds.
What is needed is a total approach that considers all the legs of the table, not just one leg at a time like these three Meta Concepts do. The software industry needs a total architecture, not incremental competing piecemeal improvements that result in an unplanned hodgepodge, which is the mess we have today except for a few standards. UHR provides a complete and new approach to the design, implementation and maintenance phases of software development, without negatives such as vendor lockin, lack of extensibility, domain limited, or code centric. That's why UHR is true massive structural change.
With time, we will integrate in the analysis phase to offer total life cycle support, and then surpass that with the concept of "Living Systems". At that point, today's software cycle of analysis, design, implementation, testing and maintenance will be replaced by a model more like biological life forms. That this is fairly easily designed shows the extensibility of UHR.
In summary, Silver Bullets are Pseudo Structural Change or Incremental Change, but people don't realize it. Golden Bullets are True Structural Change, and are less common. We leave it for you to judge whether UHR is a Silver or Golden Bullet.
UHR Versus CORBA, COM and EJB
Many ask, "How does UHR compare to CORBA, COM and EJB?" UHR is not trying to do what CORBA, COM and EJB do, which is to provide a serverside framework for distributed "object" collaboration with various built in infrastructure and services. Each "object" can be a single object or the entry point to a system, and can even be a proxy fascade to a remote object or system. CORBA, COM and EJB are considered the main Component Based Development (CBD) choices. We refer to them below as CBD.
In contrast, a BA system is a single system running in a single process on a single machine, such as a toaster, laptop, client or server. The BA has a much less ambitions goal than CBD. BA parts can use other systems, such as CBD to accomplish tasks. BA parts can also collaborate directly without CBD or other mega-middleware, such as with sockets. The BA is just a domain neutral Microkernel and visual tools. Since the kernel is domain neutral, it knows nothing about location, GUIs, persistence, transactions, sockets, etc, and so can be very small and flexible. The kernel is not a runnning system until parts are added, just as CBD systems do nothing until parts are added.
CBD solves location, language compatibility, collaboration and common mega services problems. The BA is not addressing the location or lauguage compatibility problems at all. The BA does help parts collaborate. The BA does allow Services Architecture to be implemented within a BA system, but doesn't provide any advanced services. If common services are desired between BA systems, the proper parts can be added to do this. BA parts can do anything a class can do.
The BA is the UHR reference implementation. The BA is not middleware, it's not a distributed system solution, it's not a serverside object pool, it's not an application server. However, the BA can be used to build systems of any type, such as all of the above, by adding the right parts. The BA kernel is about 1/100 the size and complexity of a CBD system with no parts, because it's domain neutral.
Let's compare the important features:
- All try to enhance productivity.
- They offer part life cycle management.
- They offer ways for parts to collaborate.
- Parts have exposed interfaces.
- They are all a "framework" for plugging parts into.
- They do nothing until parts are added.
- Built in simple Naming and Notification services. These are domain neutral.
- Hierarchial system composition.
- Hierarchial system object and message services, with shadowing.
- Declarative Knowledge driven reusable parts.
- Domain neutrality.
- A small microkernel.
- Sophisticated standard visual tools that work for all systems and parts.
- User assembly. (Once the second generation visual tools are ready)
- A total approach to Software Development, not just the distributed parts issue.
- Many other concepts in the UHR Technology Grid.
- Built in advanced services such as transactions, security and distribution.
- Location transparency, a big issue.
- Language transparency, also a big issue. (except EJB supports only Java)
I consider the last group of features to be domain dependent, while the Naming and Notification services that the BA offers are the minimum necessary for decent part collaboration and so are required by all domains. This is a close call with large ramifications....
It is the features that UHR doesn't offer that CBD vendors seem to be differentiating themselves on. They are mushrooming these areas into the main attraction, unfortunately some with little regard for compatibility, and high hopes for lockin. By contrast, the BA's humble agenda is to stay small and simple, letting users implement or purchase these areas themselves. This lightweight approach is far more flexible. It let's users retain fuller control of their system architecture and parts, so their strategy is not so controlled by vendors. Only a Microkernel approach allows users to manage their own destiny. Less is more.
Think of the BA as a lightweight, flexible, open, standard, platform independent, domain neutral Microkernel with sophisticated visual tools for assembling parts into powerful systems of any kind quickly. It's really about the same thing you'd design, given enough interations.
To summarize, CBD leans toward advanced serverside middleware and part pools, while UHR is a total approach to software development for systems of any kind. (Please note I haven't used CORBA, COM or EJB, and so this is a cursory comparison.)
See discussion on this document. This is an alternative opinion.