- They persistent parametrized data mimicking the characteristics of some "real-world" object
- They have methods that create the object's behavior and
- They have interfaces adhering to the XML standard.
In summary, initially programming was about creating code in as little space as possible. As hardware increased in power (according to Moore's Law), programming and its supporting tools focused on creating more cost effiecent code, that is, code that is easily to develop and maintain. This led to the paradigm shift of Object Oriented Development, which began to create code that enabled and supported particular process functions and activities. In total, this code was much more complex, requiring more CPU cycles, more memory, and more storage. Since, by the 1990s, the computing power had doubled and redoubled many times, this was not a problem, but linking the objects through non-standard interfaces was. The standards of Web Services provided the answer to this interfacing issue and created the requirements for another paradigm shift.
Now that Service Components (Web Services and Objects meeting other interface standards) can enable and support functions or activities of a process, organizations had a requirements for these functions to be optimally ordered and structured to support the most effective process possible, and the most cost efficient manner (as technology changed) and to be agile enough to enable the organization to successfully respond to unexpected challenges and opportunties.
Rapid, Agile, Assembly
- That the implementation team has established or is establishing an Asset and Enterprise Architecture Repository (AEAR). This should include a Requirements Identification and Management system and repository (where all of the verification and validation (tests) are stored).
- That the implementation team is using a CMMI Level 3 conformant process (with all associated documentation
- That there are business process analysis (including requirements identification and modeling), and a RAD-like Systems Engineering and System Architecture process preceding the implementation process.
- That the implementation team has access to a reasonable set of Composite Applications modeling tools that link to data in the AEAR.
- That the organization's policies and standards are mapped into automated business rules that the process flow can use through a rules engine linked to both the Orchestration engine and the Choreography engine.
- Separating the candidate application from the developers, since the developers have a tendency to "play" with the code, wanting to tweak it for many different reasons. These "tweaks" can introduce defects into code that has already been through the validation process. Migrating the code from the development environment to the staging environment and not allowing developers access to the staging environment, can effectively lock out any tweaking.
- The migrating the application to the staging environment, itself, can help to ensure the migration documentation is accurate and complete. For example, the order in which code patches are applied to their COTS product can change, significantly, the behavior of the product.
- The staging environment is normally configured in a manner identical with the production environment. It uses the same hardware and software configurations, though from large installation, the size of the systems is generally smaller than production. Since the code or product implementers have a tendency to "diddle with" the development environment. Very often I've been part of efforts where the code runs in the development/assembly environment, but not production because the configuration of the two environments is very different with different releases of operating system and data base COTS software. Having the staging environment configuration control to match the production environment obviates this problem.
There are several advantages to using SOA in a Rapid Application Development/Implementation process including:
- The implementer can use Service Component or assemble a small group of Service Components to perform the function of a single Use Case. This simplifies the implementation process and lends itself to short-cycle roll-outs.
- Since the Service Components are relatively small chunks of code (and generally perform a single function or a group of closely coupled functions) it allows the implementers at least the following actions:
- Replace one Service Component with another technologically updated component without touching the rest of the Composite Application as long as the updated component has the same interfaces as the original. For example, if a new developmental authentication policy is set
- Refactoring and combining the Service Components is simplified, since only small portions of the code are touched.
- Integration of COTS components with components that are create for/by the organization (for competitive advantage) is simplified. While my expectation is that 90 percent or more of the time, assembling COTS components and configuring their parameters will create process enabling and supports Composite Applications, there are times when the organization's competitive advantage rests on a unique process, procedure, function, or method. In these cases unique Service Components must be developed--these are high-value knowledge-value creating components. It's nice to be able to assemble these with COTS components in a simple manner.
- The Structure of an SOA-based Composite Application has three categories of components: Service Components, Process or Workflow Components, and the Business Rules. Change any of these and the Composite Application changes. Two examples:
- Reordering the functions is simplified because it requires a change in the process/workflow component rather than a re-coding of the entire application.
- If properly created in the AEAR, when an organization's policy or standard changes, the business rules will reflect those changes quickly. Since in well architected SOA-based systems will have a rules engine tied to the rules repository in the AEAR and to the orchestration and choreography engines executing the process or work flows, any change in the rules will be immediately reflected in any Composite Application using the rule.
However, as indicated by the Superiority Principle, it will take time, effort, and resources to create the training and tooling, but the pay back should be enormuous. I base this prediction on my experience with the RAD process that I developed in 2000, which by 2005 had been used on well over 200 software development efforts and which was significantly increasing the process effectiveness of the IT tools supporting the process, and the cost efficiency of the implementations.
(PS--the Superiority Principle is "The first instance of a superior system is always inferior to a mature example of an inferior system").