CM: THE NEXT GENERATION - Building Reliable Applications

I am perpetually frustrated by the "big-IT" solutions that come out of the software industry under the guise of "it has to be big to do all it does" and "if it's not big it's not a world class solution". Think about it.  A few things will come to mind.  Like some Database Vendors, Business Process Software solutions, and, yes, CM solutions.  In the latter area the industry has seen a few "small-IT" tools emerge which meet the requirements better than the "big-IT" tools, at least in some areas for some tools, in a broader sense for at least one. And better small-IT solutions will emerge over time across the entire software spectrum.

When I buy a software solution, I don't want an internal Help Desk, a need for significant consulting, a huge training bill, a large platform resource requirement, a solution administration team.  I want easy of use, easy customization, small footprint, zero administration, reliability and loads of features that meet my requirements, out of the box if
possible.  This is certainly true of CM tools as well. 

Architecture First

First and foremost, in building reliable applications, these things have to be the minds
of the architects. The software industry aims too low in general.  Let's glue things together.  Let's copy and paste and change it.  We'll optimize it later, or we can use bigger
boxes to run it.  Let's get it running first, then we can look at the features we need.  

If you're in this type of environment, I don't envy you. What's missing is the building of the underlying architecture.  Some might say architecture doesn't just happen.  But more properly, good architecture doesn't just happen.  If you don't build it well, you'll have a poor architecture. 

The philosophy that says "just make it work" is very pervasive across the software industry - largely because it's easy to do and there are so many writing software.  And this is not to
mention the schedule pressures to get to market.  If you want reliable applications, you need to have good architects and good architecture.  You have to replace the "pick one of the many ways to do it" philosophy with the "what's the proper way to do this".  And to answer that question, you need to understand architecture from the ground up and develop the appropriate rules to guide you. There may be a few in your midst that do - maybe it takes them a couple of days to rationalize their "gut feel" about something.  But it's usually worth it.

Take a look at various large software systems - how rapidly do they evolve?  The ones that evolve slowly, or perhaps not at all may have maxed out on their architecture (though this is not always the reason they don't evolve).  From the bottom up, the software must be well architected.  If you're cutting and pasting code all over the place, it becomes much more than a challange to universally improve the functionality of that portion of code.

Re-Use

After designing the overall architecture, build fully re-usable libraries/APIs from
the bottom up.  Design the interfaces and review them with system architects for maximum re-useability and for appropriate usability.

For example, file systems have always had re-useable APIs, but not useable
ones.  "Set this flag on and that one off" and call it with this action and the routine can do about anything you want.  I want simple to use routines, and so I always start a major project by introducing a file system API.  It has meaningful routines such as:

• FindFile
• CreateFile
• OpenFile
• Seek
• ReadBytes
• WriteBytes
• OpenTextFile
• AppendToTextFile
• TextRead
• TextWrite
• CloseFile

and then a bunch of directory functions and a few other file functions in similar vane.

I don't have to set flags to say that working with binary data or ascii data.  I don't have to set