July 30, 1998 - Jack Harich - Document Map
Note the process is user centric, since our objective is satisfying the user. The user initiates or causes all process input.
Considering the current state-of-the-art of software, developers create the system for the user. As tools get better, such as those produced by the process or market, the user can do more and more of customizing or developing their own system. Eventually most users will create and refine most of their own systems using extremely innovative and friendly software. This is probably the best trend in all of software.
But what can we do today? The move is away from heroically hacking out systems nearly from scratch and towards assembly from reusable components. We mean entire systems in any problem domain, not just the GUI, database edits and reports. There are several necessary ingredients for this to work:
- Our software production processes must become assembly oriented.
- We must have, build or buy high quality components.
- A reusable assembly infrastructure is required.
- Many developers need to change their mindset from coding to reuse.
Let's address these 4 requirements.
- The above flowchart is a reasonable starting point. For many organizations the largest change is two main types of developers: those who assemble systems and those who create reusable components. Most will be assemblers. This is very, very different from the coding cowboys who what to do it all. Some of these cowboys will be unhappy being a specialist. The rest will smile with glee at their new heights of productivity. Users will be thrilled at how fast and easy new apps become available or, more importantly, are changed.
- Components are coming fast, starting with GUI widgets. One key to the component market is component standards. We have CORBA, COM, EJB and Java Beans. This author feels that _all_ these have missed the boat on what is really needed to swiftly assemble components, namely an interface standard that separates "what" from "how". This allows far greater component reuse because mere properties (as popularized by Visual Basic and used in Java Beans) fizzle out as task behavior becomes complex.
- More important is component assembly infrastructure. Currently we have nearly no tools that assemble components without requiring lots of code, which itself soon becomes the bottleneck. We address the question "What is good component assembly infrastructure?" with the document on Structured Assembly.
- The author has seen developers who renounce an assembly centric (read ultra-high reuse) process as unacceptable, for a variety of wierd reasons. The stickler is many coding cowboys want to code, code, code and see assembly as a lesser exercise of their incredible talents, which should not be constrained by so much discipline and infrastructure. Just as about 25% of developers are unable to go from procedural to object oriented, about 25% will be unable to move to assembly centric. This is actually a good thing, as these were probably marginal performers anyhow or found it more and more difficult to adopt new practices. Buyin is part of the problem and can be increased by selling this as The Next Cool Good Thing, but Way Too Subtle for All Developers To Master. ;-)
For the magic in the Continuous Change System box, see Continuous Change Architecture.