If an application architecture existed that allowed complex systems to be defined entirely at the business or design level and then generated into a myriad of physical environments, the natural next step would be to use that architecture to define standard business objects that would provide a foundation for delivering integration across a variety of application areas and environments. That step would be driven by two objectives.

1. The reduced costs and increased flexibility and functionality that would accrue from a large group of users and vendors building solutions on the same open architecture – If basic, standardized objects were agreed upon by a community, the productivity, reusability and flexibility of options that would result would dramatically alter the quality and costs in their delivery of large, complex application systems.

2. The opportunity to define and build standardized, information objects for the cloud – The cloud and other connectivity opportunities provided by the internet are creating a revolution in the delivery of application solutions. The lack of standardization around the definition of information and its high-level processing remains one of the last obstacles to the effective support of complex, integrated systems within these areas. AOA provides the foundation for that standardization.

There are architectural components common to almost all applications, such as people, addresses, organizations and calendars, and other components common to special applications within an industry, such as students, classes, courses and instructors in an academic organization. These components can be grouped into standard AOA objects (such as the Degree Audit object described further into this presentation), along with processing rules, to be floated in the cloud as shared objects.

However, there are some common concerns that immediately arise around any discussion of standardized objects: 1) It has been tried before and has always resulted in failure; 2) If it succeeded, it would restrict further innovation and impede progress in the industry.

Those are both valid concerns and require a clear response, to which AOA offers the following:

1. The AOA object standards will not be set through bureaucratic edict, but through normal competitive marketing practices. The first players in the game will deliver an initial standard, which will be accepted only as long as it delivers effective results. That current standard will always be open to challenge. For example, OpenCUAS will propose the initial object standards in the academic ERP market, standards that can be challenged as new competitors enter that open market.

2. The object standards will always be fluid. The AOA logical structure allows objects to be easily extended and modified, and compare/merge functions support a world where those standards are held loosely and there exist multiple versions of the same object. It’s a little bit like “having your standard and modifying it too.”

AOA objects have five special capabilities that make them ideal for functioning as object standards for the cloud:

1. AOA objects have a flexible, but clear, structure and graphic representation for documenting objects. They also have an effective rules language which takes full advantage of that structure.
2. An AOA object can be generated into a large number of physical environments, without requiring any additional programming.
3. An AOA object can have any number of extensions, without requiring any alteration to its rules or database access statements.
4. Utilites exist to compare versions of an AOA object and to selectively merge functionality.
5. Most importantly, an AOA object can be floated through multiple nodes on the cloud, with modifications to the object being made at different nodes, after which the object is returned to its source. Once returned, data security and integrity validations are performed and changes are written back to the database via a single statement. The meta information that accompanies the AOA object throughout its journey provides the automation necessary for such functionality.

 It is the realization of this kind or reusability that is the objective of the Application Open Architecture introduced in this presentation. More detailed explanations of the above functionality are contained in the AOA Description sections.