Software productivity has been fighting to keep pace with advancements in computer, storage and networking technology for over three decades. In part one of his two-part piece, Michael Andrescavage traced some of the underlying causes of this persistent disparity and introduced the concept of an Integrated Information Processing Architecture (IIPA). In part two, he outlines what exactly an IIPA is, its value, and how to go about implementing one.

What is an Integrated Information Processing Architecture (IIPA)?

Think of the Starship Enterprise, where all systems — hardware, software, and data — are connected. A system of systems. Where all information is real-time, continuously stored, available for processing and analysis with all other information, accessible anywhere, totally integrated and never stopping. This, then, is an Integrated Information Processing Architecture (IIPA). Now, the shuttle pod leaves the Enterprise; it has its own IIPA. Both ships' IIPAs may be available to each other and others.

We now leave the realm of science fiction.

Let's build an IIPA

At first glance, it may seem that this architecture is overkill for most existing applications. But, designing for total integration requires that we embrace the larger picture. The architecture is designed to do the following:

• Support real-time additions and deletions of hardware, software, and data — dynamic expansion and contraction of processing capabilities.
• Manage a collection of computing resources (CCR) with support for every known and future hardware/operating system/networking configuration, deemed necessary.
• Capable of dynamically connecting/disconnecting CCRs and their processing capabilities to/from each other.
• Authorize remote access to the CPUs, memory, I/O and operating system on each computing resource.

The processing model is service-oriented. Services are scalable, independent, stand-alone, generalized, reusable, and exist somewhere accessible. Except for IIPA core functionality (ICF), all other software created is a service. Two types of service are available: IIPA services to support user interface, security, monitoring, etc., and end-user services.

Services are composed of one or more commands, where a command contains a list of name/value pairs which identify all necessary details/arguments/parameters/variables to accomplish a specific, clearly defined task.

Service commands are executed by command processors, where the resulting software executes and may create new commands executed by other command processors. The execution of a command provides feedback to the originator command.

Command processors are externally assigned to operating system threads at runtime, one command processor to one thread. As many command processor–thread pairs, as necessary, may be assigned. Operating system constraints such as memory and/or number of resources will determine maximum configuration.
 
Services executing within an IIPA communicate with other services via a Services Programming Interface (SPI).
 
All work accomplished is through service commands and feedback flowing through a CCR. ICF is responsible for delivering commands from source service command processor to the destination service command processor, with feedback returning to the command originator.

What are the benefits of an IIPA?

1. The dynamic expansion and contraction of processing capabilities mirrors business cycles and periods of fluctuating processing requirements. An IIPA is a convenient vehicle to exercise scalable services — services with high interactivity and services requiring high performance resources — co-existing with all other services.

2. The ability to use heterogeneous computing resources, generic processors, and multiple operating systems at market prices, financially favors this entity over any competitor.

3. Dynamic alternate-path retry is performed when a CCR outage is encountered.

4. IIPA services are available which allow for independent enhancement and functionality.

5. All software can be written as service-oriented commands.

6. The assignment of a command processor to an operating system thread provides a simple interface for high performance computing. In fact, most thread-based applications can be replaced by using service commands.

7. The threading model is ready for any number of CPU cores projected for the future.

8. The SPI minimizes the number of programming interfaces and eliminates communications programming. Programmers focus on creating the closed logic for a specific service command.  All software is:

• created using the same simple concepts
• command driven
• high-performance (multi-threaded)
• real-time
• dynamically scalable in real-time
• fault-tolerant
• operating system and hardware independent (except in specific cases)
• capable of interfacing with all other similarly designed software
• self-monitoring
• capable of being upgraded in real-time
• simple to create

9. When integration is achieved, ideas to solutions are rapid. New ways of looking at data and software generate innovative solutions.

How to get started

Identify a candidate service. Acquire X number of computing resources. Choose two people to develop the 1st IIPA service; after successful completion, these two developers can train two more developers. Initiate the next necessary services. Each service is to be supported by zero or more developers, maintainers and integrators.

All of the software systems that exist today are legacy, some older than others. For an IIPA to be a success, all systems must be converted. In the interim, as new services are being added to the IIPA, temporary interfaces from the IIPA to legacy systems may be desirable instead of a full conversion.

—-

Michael J. Andrescavage has been developing software for 40 years. He is the Chief Software Architect for Andrescavage Software, Inc. www.andrescavage.com