Enterprise Frameworks And Enterprise Integration: A Usability Perspective

John M. Artim
Savi Technology, Inc.
615 Tasman Drive
Sunnyvale, CA 94089-1707
+1 408 458 9263 (phone)
+1 408 543 8650 (fax)

In the call for papers for this workshop, the workshop organizers state that, “Enterprise Frameworks play an important role since they allow reuse of design knowledge and offer techniques for creating reference models and scalable architectures for enterprise integration.” This paper concerns usability issues surrounding these enterprise reference models and scalable enterprise architectures. The usability issues and approach are drawn from tool integration experiences in the CASE community. This paper concludes by examining the role of these usability issues in enterprise framework design and the representation of enduring business themes1.

Keywords: extensibility usability integration presentation CASE

Introduction

One topic implicit in any discussion of enterprise frameworks is that of extensibility. Extensibility can mean the ability of a systems integration group to take a COTS framework and extend its function beyond the general enduring business themes packaged within that framework. But extensibility equally means the ability of many small development units to build pieces of function to be integrated within a larger COTS deliverable. This issue of extensibility and guided modular development has been discussed at length in the computer assisted software engineering (CASE) work of the past decade. This paper will first spend some time reviewing CASE related approaches to integration. These approaches will then be considered in the broader context of enterprise frameworks and large system engineering, described in terms of business objects and enduring business themes[1].

CASE, Integration and Usability

At one level, CASE concerns itself with the broad domain of software engineering. The software engineering domain, irrespective of technological perspective, is broad. It is sufficiently broad that single tool CASE implementations often lack the breadth needed to support the entire software engineering lifecycle. Even large case tools must, at a minimum, integrate with configuration management and integrated development environment tools (source libraries and edit, compile, debug environments). As with good enterprise frameworks, good CASE platforms must be extensible and customizable. These extensions must be allowed at any time after release of the platform. That is to say, the extensions need not be co-designed with the platform.

One approach to solve this problem in the CASE domain is to architect a CASE platform so that it can be assembled out of independently designed, modular tools. Platforms that support this modularity are built on properties of data, control and presentation integration[2].

Data Integration

To be successful, CASE requires a rich and expressive reference model of software engineering to sustain computer-assisted activities. Software engineering reference models are used in support of what is often termed, somewhat misleadingly, data integration. Originally conceived of as mechanisms of shared data persistence for a set of tools, a reference model really provides a language of interchange between the tools. If engineered to do so, it may also serve as a basis of the end-users’ domain expression.

In the CASE domain, a reference model of software engineering constructs can be used to facilitate this data interchange. The unified modeling language[3] (UML) is one such reference model. UML is, at its heart, a reference model for object technology based software engineering.

UML has proven to be a flexible language for the expression of many aspects and phases of software engineering. In enterprise framework terminology, UML provides support for a number of enduring business themes but relatively sparse connections for the flow between these themes. Mechanisms for linking themes are provided, but these form ad hoc linkages between themes. That these themes are ad hoc also implies that any linkage between tools will also be ad hoc.[4]

Earlier efforts at data integration included IBM’s systems application architecture[5] (SAA) with its enterprise and technology models. SAA’s models were intended to support enterprise-wide software development as well as what is arguably the precursor of enterprise resource planning (ERP). These reference models provided a set of generic business objects clustered around enduring themes referred to as subject areas.

Control Integration

To support the interaction of independently designed modular tools CASE platforms must provide a service to support invocation from one tool of a second tools functionality (its published services). This service is often referred to as control integration.

Currently, control integration is primarily delivered via object request broker (ORB) messaging interfaces such as OMG’s CORBA. ORB interfaces rely upon a set of a priori interfaces (interfaces defined at design time) and generic messaging protocols. Earlier efforts, such as HP’s Softbench and IBM’s AD/Cycle platform, relied on simplified enduring business themes. These themes took the form of messages to launch particular kinds of tool functionality such as a default editor or compiler or messages to perform generic actions such as requests to refresh from a flat-file.

Presentation Integration

If end users are to successfully (and happily!) make use of a broad toolset, the tools’ user interface should also provide a usable degree of consistency. Such consistency is often described in terms of the widget set to be used, the look-and-feel of those widgets as well as their standard usage, as well as presentation conventions to be followed by individual tools. Guidelines such as this are often referred to as providing presentation integration.

CASE Tool Integration

CASE platforms that provide for extensibility via a modular toolset, especially where the tools are of mixed provenance, must provide an architecture for delivery of data, control and presentation integration. SAA, through its product family AD/Cycle5, attempted to provide a combination of an infrastructure platform, a data integration model and implementation, control integration between tools, and presentation integration. Let’s examine AD/Cycle’s tool integration architecture in more detail.

AD/Cycle’s data integration mechanism was described using an Entity Relationship model IBM called an information model. This model was comprised of two components: a technology model and an enterprise model. The technology model provided for the direct tool interchange of development and design related information such database schema and code structure[6]. The enterprise model provided for analysis tool data interchange, primarily but not exclusively business process and requirements modeling.

The presentation integration was achieved using the SAA presentation standard, the Common User Access (CUA) Workplace, with the addition of product family enhancements. CUA Workplace was based on a description of user interface as an extensible set of user objects (really types of user objects) and views of those objects. Each view is itself comprised of other user objects and primitive data such as text and numeric values. This object-view paradigm[7] is one of the major forms of object oriented user interfaces in use today[8].

Primary views in an object-view based design form a transaction boundary for the end-user. All work within a primary view is independent of the work done in other primary views. Each primary view displays the objects, attributes, and relationships among objects needed by the user to solve a related set of user tasks.

AD/Cycle product family enhancements[9],[10],[11] to CUA Workplace included restrictions to look-and-feel guidelines to facilitate consistency, additional look-and-feel guidelines in areas such as node-and-arc diagramming, and a working definition of a core, extensible set of user object types.

Control integration in AD/Cycle came in two forms. One form was a set of APIs that addressed inter-tool requests for specific purposes such as source code control. This form of control integration is, in effect, an implementation of process support for a specific enduring business theme. However, the experience in AD/Cycle was that user task boundaries, implied by individual tool designs, were rarely respected by end-users. Novel task situations would often entail use of more than one tool often in novel configurations. To support these novel tasks the second form of control integration is entirely ad hoc and based on the CUA Workplace object-view paradigm.

AD/Cycle tools were expected to integrate with one another via a shared core set of user object types. Each tool would then construct its views out of these and other user objects as well as primitive data. This provided a high degree of semantic consistency in user interface. The GUI in such a system is expressive enough to form a simple graphical language representing the users’ domain.

This use of a common user domain model in the user interface also provides a means of launching one tool’s function from within another tool without exposing either tool’s internals to the other. This form of control integration is supported via a platform service that provides a look-up table listing the views each tool has registered with the platform as well as the user object type that view supports (provides a view of). This same system service delivers a list of compatible views given an instance of user object. It can launch, from within one tool’s view, another view provided by a second tool. The first tool passes the second tool the user object instance needed to populate the new view. The operating system, OS/2, in its version 2.0 and later provides this support service for objects stored using its native file system. This approach to user interface is in use today[12],[13].

One question that this approach raises is why have a user object type model at all? Isn’t this the role of the data integration model? The answer is, of course, a resounding maybe. It really depends on the purposes to which the data integration model is put. If design re-use is an important goal, then design forces will push the data integration model in the direction of finer grained entities or the more recent equivalent, finer-grained classes. These finer grained classes are more adaptable and can be recombined into new configurations to form variations of a course-grained business object. However, to provide the user a consistent language of interaction requires identification of the object types with which the user will interact.

However, if the data integration model is at the level of business objects, the user object type model is redundant with respect to the business object model. Of course this also implies that an enterprise framework must decide whether it is supplying business objects, finer-grained classes used to construct business objects, or both[14]. It also implies that a relatively complete set of business objects can help to provide greater degrees of usability in an enterprise framework but only if the business objects correspond to constructs the user recognizes as belonging to their domain.

The final and key question raised by this discussion is the relationship between an enduring business theme, workflow, and a collection of user interface views. Tools whose user interface makes use of the object-view user interface paradigm can provide two forms of workflow support each via its own presentation mechanisms: one supporting a priori workflow and the other supporting ad hoc workflow. A priori workflow can be described as a part of an enduring business theme. All GUI design approaches support some form of a priori workflow. Any time the user is provided with a mechanism, such as a button, that allows them to navigate from one fixed location in the GUI to another, they are using an a priori workflow mechanism. For a more extensive discussion of workflow and user interface navigation design, see Artim 2000.

In ad hoc workflow, the end user is attempting to solve a novel task by applying their domain expertise. The ad hoc tool integration mechanism discussed above is one such ad hoc workflow mechanism. Ad hoc workflow by its nature is not sufficiently durable to be described in an enduring business theme. Yet ad hoc workflow is the hallmark of the knowledge intensive roles so critical to today’s economy.

If an enterprise framework is implemented in such a way that it only supports a priori workflow, it will fail to gracefully extend. Fayad, et al. rightfully point out that many aspects of workflow in the commercial world are highly conserved. The difficulty arises when an enduring business theme is described in terms of a wholly contained chunk of workflow. The nature of most enduring business themes is that they are skeletal. That is, they form a framework for the myriad variation seen at both the level of organization (for example, a business and its processes) and individual (a user and her tasks). Object oriented user interface and, in particular, the object-view paradigm, provides a mechanism for adapting enterprise frameworks to this myriad variability in the application of enduring business themes.

More than this, the conceptual framework behind the object-view paradigm provides a means of organizing enterprise frameworks with this extensibility in mind. By combining data integration and control integration and by using units of encapsulation relevant to the end-user, the object-view paradigm provides components describing not only business objects, but also the workflow that forms a part of an enduring business theme.

Enterprise Frameworks And Enterprise Integration: A Usability Perspective
Artim -- OOPSLA 2000 2nd Workshop on Enterprise FrameworksPage 1

[1] Fayad, M., D. Hamu, and D. Brugali, Enterprise Frameworks: Characteristics, Criteria, and Challenges, in Communications of the ACM, October 2000.

[2] Wallnau, K. C., and P. H. Feiler, Tool Integration and Environment Architectures, Software Engineering Institute Technical Report, CMU/SEI-91-TR-11, May 1991.

[3] OMG’s UML home page,

[4] UML’s customization relationships can be used to extend UML. However existing tools can only be aware of the generalized semantics of these relationship types and not the new semantics implied by the special use of these relationships by any one (new) tool.

[5] AD/Cycle theme issue, IBM Systems Journal, Vol. 29, No. 2, IBM, New York, 1990.

[6] Until approximately 1991, AD/Cycle was largely a structured analysis and design tool suite. Up to this point, platform support for object-oriented analysis, design and implementation was limited.

[7] IBM, Object-Oriented Interface Design: IBM Common User Access Guidelines. IBM, 1992.

[8] van Harmelen, M. editor, Object Modeling and User Interface Design, Addison-Wesley Pub Company, Boston, Massachusetts, October 2000.

[9] Artim, J. M., J. M. Hary, and F. J. Spickhoff, User Interface Services in AD/Cycle. IBM Systems Journal, Vol. 29, No. 2, IBM, New York, 1990.

[10] AD/Cycle Level 3 User Interface Supplement, IBM, 1992.

[11] Artim, J. and J. Fenwick, AD/Cycle User Object Model. AD/Cycle User Interface Board architecture working paper, IBM, 1992.

[12] Roberts, D., D. Berry, S. Isensee, and J. Mullaly, Desiging for the User with OVID, Macmillian Technical Publishing USA, 1998.

[13] Artim, J. Entity, Task and Presentor Classification in User Interface Architecture: an Approach to Organizing HCI Practice, chapter in Object Modeling and User Interface Design , van Harmelen, editor, Addison-Wesley Pub Company, Boston, Massachusetts, October 2000 .

[14] Black box enterprise frameworks must supply Business Objects. White box frameworks must supply fine-grain component classes providing design-level support. Frameworks that intend to support some level of off-the-shelf use and extensibility should probably support both.