ODC and Flexible Systems
We're all accustomed to the plethora of system updates, tweaks, virus scans, etc. that have become part and parcel of using computing technology in business. New antivirus data, operating system updates, and other required changes all form part of the increasingly plastic nature of software. ODC requires similar flexibility at the level of software application features; software components must be able to swap in and out of operational systems on an as-needed basis. One mechanism for this capability is aspect-oriented programming (AOP).
Aspect-Oriented Programming
The move to component-based software is a step in the right direction, but the bulk of software changes today still require expensive upgrade procedures. The relatively new area of aspect-oriented programming provides for the ability to swap out existing software from an operational system and replace it with new code.
Why might you want a rapid software change in an ODC environment? Perhaps a component has failed, some vital new feature is needed, or some key algorithm has changed. Regardless of the reason, ODC allows for rapid changes; for instance, in seconds or minutes rather than weeks or months.
Closing the Administration Loop
The present generation of IT administration is largely manual in nature. A key element of keeping systems operational is one or more skilled individuals studying system consoles, log files, and trouble tickets and then tweaking operational software. A lot of this labor can and probably should be done by software. This principle applies particularly to logging. A case can be made for building the intelligence into software to manage its own logging details and take appropriate action. The growing complexity of systems may make this requirement mandatory for future systems. Beyond logging, ODC systems will also be self-configuring and self-defending.
The need for self-configuring systems can be seen during installation or deployment. The ability of software to self-configure reduces the need for large amounts of know-how at this stage. In many cases, IT users may have very limited knowledge but still want to install increasingly advanced software. I recently installed J2EE from Sun Microsystems, and it was a very straightforward process. However, when I later tried to launch the application server, I ran into a problem with my Windows XP firewall. The problem took a bit of effort to resolve, but I managed it without calling in any IT support. ODC should help make such problems a thing of the past by intelligent auto-configuration.
A more subtle requirement for self-configuration forms the very basis of autonomic computing. Nowadays, if a software system has to withstand a sudden load increase, the end user may experience a delay or a timeout (assuming that the system is not over-provisioned with excess capacity). It's a bit like when you run up some stairs; your autonomic nervous system makes your respiratory rate increase and your heart beat faster, etc. in order to meet the extra "load." Software doesn't yet operate in this way. Instead, we currently have to rely on over-provisioned systems (extra servers, excess bandwidth) above and beyond the anticipated requirements. Clearly, this is a wasteful approach! If the systems can automatically configure themselves, the cost of over-provisioning can potentially be reduced in parallel with improvements in service.
Also, it's worth remembering that the root cause for about 40% of computer system outages is operator error. The complexity of traditional systems is outstripping the ability of administrators to manage them. Closing the loop may help reverse this trend.