July 31, 1998 - Jack Harich - Try the Document Map
(This document was a presentation to CDC in Atlanta on 8/11/1998.)
Synopsis
The Future of Application Development is impossible to predict with any significant length or accuracy. Thus the only way one can prepare for it is to:
- Adopt Best Practices and Best Technologies possible now.
- Accommodate anticipated changes.
- Insulate yourself from unanticipated changes.
It's difficult to write about concepts as complex, nebulous, novel and just plain hard as this. It's much easier to describe them in person, wave your hands for 60 minutes and then elaborate via question and answer. Please bear with me here....
Introduction
In a nutshell, here's how you can achieve 1, 2, and 3:
1. Adopt Best Practices and Best Technologies possible now.
Based on early results of my R & D for the last year, we have specific actual working examples of highly productive, cutting edge approaches. These are not pie-in-the-sky recommendations, but full blown working systems that serve as proof positive examples.
2. Accommodate anticipated changes.
Most short term change is predictable, given a study of your organization, the market and literature. Examples are 200 function point requests a month or 5 new users a week. Traditional Best Practices work fine here.
3. Insulate yourself from unanticipated changes.
This gets harder. Let's take a cue from the ancient Japanes game of "Go". Prime early game strategy includes what is called "Flexible Shape", to handle anything your worthy opponent does. Flexible Shape is better than an inflexible one, such as hard coding business facts. Examples of Flexible Shape are platform independence and separation of business rules from business logic. Our goal is a flexible process and architecture that can react favorably to anything our opponent Mr. Future can throw at us. A perfect plan is not possible, but a flexible one is.
Number 3 is the toughie. The remainder of this document is a series of logical inferences concentrating on how we can best insulate systems and system development from unanticipated changes and accomodate anticipated changes. Our goal is to identify the "golden nuggets", those few practices that lead to the biggest gains. We now address these core questions:
|
Forces
Hyper Change (Prime Force)
Hyper Change is rapid change. Since it causes more problems and creates more opportunities than any other force, it is the prime force to consider. A huge roadblock to preparing for Hyper Change is it is ceaseless, exponential and huge, while most software developers are optimistic under-estimaters. This combination is deadly. Hyper Change also overloads most organizations, causing a gaggle of problems.
Management of Complexity (2nd Force)
As we exit the Industrial Revolution and enter the Information Revolution, we are greeted with a deluge of information and related technology. The quantity is enormous. The types vary greatly. Uses and inter-relationships are intricate. Enterprise systems are so large and complex no one understands them completely. All of this is growing exponentially. The net challenge is how to manage complexity, such as in systems one is building and the information these systems are managing. Note we have at least one partition here, Systems and Information.
The Inhuman Interface Dilemma (3rd Force)
As more and more people begin to use computers daily, more and more find it to be one of the most frustrating and unproductive activities they have ever engaged in. They may be casual users, power users or developers. Regardless of their level, they all eventually (or quickly) reach the point where they can easily see many glaring shortcomings in the human/machine interface. Examples are the inhuman computer can't hear or speak, Unix is completely different from Windows, or most software is hard to learn and use, and is full of bugs. Many users ultimately begin to dislike software, knowing there must be a better way.
A whole new User Interface is needed, but will take time. It will drift towards the way humans interact with other humans. Meanwhile, how can we design our systems to accommodate the huge technological leaps sure to take place here? How can we provide a more human/friendly interface with today's technology?
Enshrouded in these issues is "What is the top goal of software development improvement?" We feel this can only be turning all users into developers via tools that are so good any sharp user can (from their perspective) develop their own application or system. This will take not just clever software algorithms but an incredibly easy to learn and use human interface. It will also take software that can develop itself, learning from its own use. Long term this type of software will drive the entire industry, making it the prime force someday.
Flexible Shape to Support Continuous Change
The very, very common theme of the above is change. Thus we must build systems that can handle change continuously, not the static ones we keep hacking out now. Systems must be dynamic, living entities that breath in new changes every hour. A good Flexible Shape architect would first define a process, then an architecture to support that process, and then techniques (aka best practices) to support that architecture and process.
Continuous Change Process (Top Objective)
The place to start is the organization's process. An increasingly efficient and effective process is our top goal, because that will lead to greatest user satisfaction. The second goal is supporting continuous change. This is akin to the difference between pre-industrial revolution hand crafted goods and post-industrial revolution assembly lines using interchangable parts. We need to have more manufacturing engineers who moonlight as fewer coding cowboys to get the conceptual leaps that innovative projects require.
Continuous Change Architecture (Supports the Process)
Form follows function. Architecture follows process.
Architecture is a system's top level partitions and their interactions. Architectural Goals assure that subsequent decisions will result in a "good" system. Our most important goal is supporting the Continuous Change Process. Key subgoals are technology independence, separation of state from logic, conceptual simplicity and a more human interface.
Configurability (Prime Technique to achieve process & architecture)
Taking a cue from nature, we see that a few strands of DNA can define a creature as complex as man himself. DNA is a complex encoding of pure data and almost no behavior. Organisms are constructed, repaired and modified from DNA and "bootstrap" workers who use the parameters in DNA to build more workers, who build more workers, etc.
The DNA is pure data (or state or parameters) and the workers are logic. Thus by cleaving systems into state and logic as much as possible we can achieve great leverage, which gets better with experience. Calling the DNA parameters and the workers Business Objects, a productive approach is to design systems to be an organized collection of parameter driven Business Objects, and to assemble such systems by Business Object composition and setting parameters. Assembly should involve absolutely no code, because that combines state and logic.
Techniques to Implement Process and Architecture
Appropriate Enterprise System Architecture
What is the appropriate logical architecture to use in building enterprise systems that support continuous change?
Structured Assembly (Theoretical Foundation for Bean Assembler)
Here we address the difficult question "What is good component assembly infrastructure?"
As we move toward component centric systems, what are the problems to avoid?
The Bean Assembler (A Tool of the Future Today)
This is a Layered Architecture "neutral framwork" for the first layer. It's an Integrated Assembly Environment (IAE), not an IDE. Here's the original spec. Currently we are in our first iteration. This is where most of my time has gone in the last year.
The key concept of the BA is parameter driven components assembled into an existing infrastructure. Systems are configured, not coded. Business rules are separated from reusable behavior. This is hugely efficient, as we can see by the success of SAP and PeopleSoft. The difference is the BA is domain neutral and is designed as the foundational element for building systems of any type or size.
Previously this technology has been so scarce and valuable it has been embedded in proprietary products. The BA opens the door to let any developer use this new technology without reinventing the wheel.