The second item, Maximize Re-Use of Data and Processes, is accomplished through the generation of business information systems. To achieve that, these generators must have at least two main layers. The first is the business information system specification layer in the form of metadata. The second layer contains the resultant generation of the actual business information system language statements, that, when compiled result in an executing business information system.
Supporting the first layer must be an Integrated Development Environment (IDE) that manages all the created business information system specifications. This IDE environment must provide facilities for defining, managing, and employing all the specification objects that are able to be included in any generated business information system. Supported too must also be text editors, compilers, linkers, and debugging tools. Beyond this IDE infrastructure there must be:
- Control Templates
- Template Language
- Procedure Language Programming
- Object Oriented Programming
- Data Access Language
- Near Real Time Programming & Execution
Control Templates. Because most aspects of a business information system are similar from one business information system to the next, a very key component of the specification layer are “specification writing” templates that when invoked for every business information system control such as for menus, windows, browses, buttons, and the like, produce the specifications of these controls that, in turn enable the generation of the program language statements that accomplish the business information system control.
It is essential that these specification templates be such that the end-user created special purpose procedure language code can be specially embedded “before, during, and after” any control. The embedded procedure language code must be segregated such that the template control is unaffected, and vice versa. Such end-user embedded procedure language code isolation ensures business information system regeneration.
Template Language. The Template Specification Language is a special language that generates Control Templates, Procedure Language, and the Object Oriented Class and Method Language. The template language can be used not only to generate Control Templates, but also IT Technique Templates and Application Templates.
IT technique templates include the production of control to display and manipulate calendars as well as perform calendar-base calculations, the generation of single file recursion hierarchies, networks, and many other IT techniques such as email processing, encryption, FTP, and the like. These facilities are then able to be integrated within business information systems without exiting, accomplishing the task, and then restarting the business information system.
Application Templates are pre-written templates that accomplish whole or in part applications that can be included within a normal business information system. Examples would include Application Templates that integrate HR or Accounting.
Procedure Language Programming. Procedure language program first and foremost indicates the focus of its purpose: the procedure. Here the action word is programming, and the vehicle for accomplishing the program is through a language. Procedure language programming has been here since the dawn of the stored program computer. Such computers were without purpose until directed into action by a stored computer program. Computers then accomplished the creation of specific outcomes such as generating a payroll, accounting for finances, scheduling product deliveries, and the like.
Over the years, stored program computers shrank in size from room-sized ones to hand-helds, while at the same time, grew in performance from the slow execution of a very small stored programs, to the near simultaneous execution of many complex programs.
A procedure language contains the traditional set of commands such as assignment, looping, case, insert, change, and delete. Procedure languages also contain a methods for processing strings, calendars, and the like, and also the ability to create data structures and to add, delete, and modify records within these data structures. Included as well is the ability to define and automatically process relationships (both data and pointer-based) relationships across records from different data structures. All these fundamental capabilities in programming languages have not significantly changed over the past 50 years.
What has changed, however, is the ability to reuse common collections of procedure language statements by initially creating generalized variables within the procedures that can, at run time, be bound to local variables and/or database table names, columns, or keys. Once the binding has been invoked, the generalize procedure routines can be invoked and execute just as if they had been originally created with the local variables and/or database table names, columns, or keys.
Object Oriented Programming. Object oriented programming takes its name from its focus, the object, which represents something concrete (in IT terms), such as a file, person, account, transactions, and the like. The word, oriented, means that the action word, programming has to be oriented towards the object. Here, action words are things like Create, Destroy, Insert, Modify, and the like.
The various other language processes that can occur to instances of the object are the traditional set for example, assignment, looping, If-Then-Else, case, string processing, calendar-based processing, and the ability to create data structures and to add, delete, and modify records within these data structures
Taken together object oriented programming represents a conceptual inverse to procedure language programming. In procedure language programming, the procedure is the essential property, and what and how the procedure acts are the accidental properties. In object oriented programming, the object is the essential property and the actions performed on the object are the accidental properties.
The paramount objective of object oriented programming is to build multiple higher-levels of generalization and abstraction with the goal of removing the lower level bindings that make code brittle, unable to be re-used, unable to be re-purposed, and expensive to maintain. These levels of generalization and abstraction enable encapsulation and inheritance.
Process objects should always be in “Process Third Normal Form,” that is, the name of the object reflects its complete and singular purpose, internally employed data is defined within the object, and there is one entrance, one exit.
Object Oriented Programming capabilities and their definition, execution and evolution infrastructures and environments have grown over the years. It is now easily possible to create many layers of generalization and abstraction along with encapsulation and inheritance. These enhancements enable the development of many layers that, when compared to traditional ti procedure language program collections that accomplish the same result, are many times smaller, equivalent in execution performance, and far more efficient in development, reuse and evolution.
Near Real Time Programming & Execution. It matters not one wit about the sophistication of the control templates, the template language, and as well the differences in procedure language programming and object oriented programming if the Integrated Development Environment (IDE) is primitive. Here, primitive means that the various steps to create programs had to be created, compiled, executed, and evolved in a serial fashion. Or that only whole programs could be created, executed, and evolved versus small well-bounded subsets of functionality within the overall program.
Sophisticated IT environments accomplish the creation, execution and evolution of requirements, architectures, designs, implementations, and continuous improvements, in near real time. Such environments support repeatable cycles of "Conceive-Posit-Prove-Reflect-Optimize."