Business Object Design and Implementation Workshop
Business Object Design and Implementation Workshop
Position Paper Business
Application Components
Tom
Digre (digre@ti.com)
Organization
Date/Place: 16 October 1995/Austin, TX
Global business competition and a shift from commodity to custom products has created an environment of continuous business structure change. In order to effectively compete, businesses are constantly revisiting products, processes, suppliers, and customer care-abouts. A successful information strategy must enable business flexibility by provisioning business solutions at a rate commensurate with the increasing rate of business structural change.
Rapid solution delivery in response to continuous business process changes requires direct involvement of empowered users to dynamically change their business processes, workflows, rules, policies, presentation, and other aspects of their environment. Impediments to achieving these goals have been technological and organizational barriers between business and the enterprise's information technology. Central enterprise IT organizations have repeatedly failed to achieve productivity, performance, and cycle time gains necessarily to support business change.
Software productivity levels using third generation languages such as COBOL, C++, and Smalltalk have improved by less than a factor of 10 since 1960. A fundamental problem with software solutions implemented using 3GL is the inability to cope with increasing business complexity. As complexity increases, there is an adverse nonlinear impact on requirements interpretation, productivity, reliability, delivery cycle time, flexibility, and cost. The challenge is to provide rapid implementation of accurately specified business requirements. The implication is that the business user should directly provision his business solution, expressing his specification in a form consistent with the problem domain. The business user should only be exposed to the business problem domain, all underlying technological and implementation complexity should be hidden. Mechanisms for achieving these goals utilize concepts of componentization, model-based specifications, and end-user solution assembly.
While semiconductor (and downstream hardware) technology has consistently sustained an annual doubling of productivity and performance gains, significant software productivity gains have not materialized. The software industry needs to capitalize on the semiconductor concepts of specialized, application-independent, encapsulated, units of functionality (components).
Exploitation of these component concepts within the software domain will be aided by open standards for specification of component syntax and semantics; the existence of a marketplace (suppliers and consumers) for reusable software components; and tools for the construction of components and consequent assembly of components into solutions.
A component-based IT architecture is founded on well-defined information components that can be specialized and/or assembled into applications. The architecture recognizes that components, including tools and services, can be purchased from external vendors (e.g., desktop tools); specialized and assembled by users (e.g., user-developed financial analysis); or developed by the IT provisioner. The component-based architecture defines the platform, or board on which these reusable components can fit together.
Within the component-based architecture scenario, the business user will assume the responsibility for solution provisioning. The business user will administrate business rules, work flows, and presentation. The business user will specialize and assemble components into solutions using Enterprise modeling tools and toolkits.
The Information Technology provisioner will provision reusable components that can be combined to form solutions by the business user. The IT provisioner will provision these components through purchase, construction, or specialization and assembly of finer-grained components. The IT provisioner will encapsulate purchased and legacy systems so they can be utilized as reusable, inter-operable components.
All provisioning roles are inextricably tied to components. All roles specialize and assemble components. In most cases, the product of assembly is itself a reusable component. Overall cycle time is drastically reduced by end-user assembly of these components.
Building on this approach, components can be used in several business solutions. When a business condition changes, the resulting modification to software is envisioned to occur only in those components directly associated with the changing business specification. To support users in making their required changes, the component-based architecture should include an enterprise integration model which fully specifies the exposed services of all components, and a set of tools. The tools include business rule tools, work flow tools, presentation tools, software assembly tools, data access tools, and so forth.
The term "component" has been perceived, defined, and used in numerous ways throughout the IT industry:
Hardware, network, and fundamental software (e.g., operating system) infrastructure components currently have reasonable levels of plug-and-play interoperability. This enables rapid and transparent installation/replacement of tailorable infrastructure components within a broad range of reliability, performance, capacity, and price characteristics. These infrastructure components are no longer on the critical path to achieving objectives such as business solution cycle time reduction and end-user empowerment.
The components which are on the critical path for meeting business objectives are Business Application Components. Characteristics of Business Application Components include the following:
Examples of (standard) business application components include:
OMG's central mission is to establish an architecture and set of specifications to enable distributed integrated applications. Primary goals are the reusability, portability and interoperability of object-based software components in distributed heterogenous environments. Much of the effort to date has been to establish an enabling infrastructure based on open and standard interface definitions. While the enabling infrastructure will have positive impact on the enterprise, orders of magnitude higher impact will be achieved through rapid delivery of interoperable business application components.
Business Application Components do not exist in isolation. For each business solution, there is a set of explicitly and implicitly defined "business rules" which govern the relationships between components, valid business states of the enterprise, and composite behavior. Knowledge of these semantics of business application components within an enterprise implementation context is necessary for successful implementation of business solution assembly from components as well as the component specialization necessary to implement dynamic business rule changes. Thus, the specification of a business application component must include semantic and contextual information, not just IDL.
Business Application Component context is provided by domain frameworks (e.g., SEMATECH Framework) which provide, in addition to the interface definition, semantics on component relationships and behavior. These frameworks, just as their constituent Business Application Components, will be specializable for enterprise-specific requirements. Frameworks serve to further reduce (or clarify) exposed complexity. The assembly concept, when applied to domain-specific frameworks, enables rapid assembly of business solutions across multiple frameworks and domains.
The OMG Object Architecture is defined as a layering of services from Common Object Services and Common Facilities through Applications. It is a natural extension of the OMG Architecture to formally define (possibly via IDL extensions) the business domain facilities in terms of the concepts specified within Common Object Services (such as persistence, transaction, event management, relationship services). This will begin to address the current inability to formally express semantics and will lay a foundation for the common business infrastructure and services (which is an objective of an RFP currently being drafted by BOMSIG). Formal semantic specifications will be necessary to create a true plug-and-play business component market or to implement a viable end-user solution assembly tool.
Some of the key issues related to the concepts of business application components and solution assembly include:
Business Object Design and Implementation
| Page Hits | |
|---|---|
| This Page | |
| Since 9/27/95 | |