Architecture-Centered Information Systems In The Manufacturing Domain - Part V - Applying the Methodology

Glen B. Alleman is associated with Niwot Ridge Consulting, www.niwotridge.com

About This Note:

This note is presented in five parts as follows:

1. Introduction to Software Architecture
   
   
2. The Architecture Process
   
   
3. Steps in the Architecture Process
   
   
4. Moving from Planning to Implementation
   
   
5. Applying the Methodology

Part V - Applying the Methodology

A Critical Success Factor in the architecture business is the clear and concise application of a methodology (any methodology) to the problem. The attributes clear and concise cannot be over emphasized. The UML notation is one means of conveying clear and concise architecture, but other "languages" can be used.

The methodology described in the previous sections must be deployed against a live system in order to be of any value to the organization. This section applies the methodology in a checklist manner. The architect, the developers, and the deployment team can use these checklists to ask questions about the proposed (or existing) system.

Every great movement must experience three stages: ridicule, discussion, and adoption
- John Stuart Mill.

The Role of the Architect

The architect's role in all of these processes is to maintain the integrity of the vision statement using the guidelines provided in this White Paper. This can be done by:

Continually asking architecture questions in response to system requirements, requests for new features, alternative solutions, vendor's offerings and the suggestions on how to improve the system - does this suggestion, product or feature request fit the architecture that has been defined? If not, does the requested item produce a change in the architecture? If so, does this item actually belong in the system?

Continually asking the developers, integrators, and product vendors to describe how their system meets the architectural principles stated in the vision of the system. These questions are intended to maintain the integrity of the system for future and unforeseen needs, not the immediate needs of the users. Without this integrity, the system will not be able to adapt to these needs.

Continually adapting to the needs of the users and the changing technology. The discipline of software architecture is continually changing. The knowledge of software architecture is expanding through research and practice. The architect must participant in this process as well.

Architecture Management

The management of the system architecture is a continuous improvement process much in same way any quality program continually evaluates the design and production process in the search for improvement opportunities.

Architectural evaluation - the architecture of the proposed system is continually compared with other architectural models to confirm its consistency.

Architectural management - the architecture is actively managed in the same way software development is managed.

System design processes - there are formal design processes for software architecture, just as there are formal processes for software development. These processes must be used if the architecture is to have an impact on the system integrity.

Non-Functional design process - the non-functional requirements must be provided in the detailed system design. The design process will include the metrics needed to verify the non-functional requirements are being met in the architecture.

Architecture Evaluation

The ODP framework provides a number of functions to manage the architecture of the system [Booc99]:

Management - how are the various components of the system being defined, created, and managed? Are these components defined using some framework in which their architectural structure can be validated?

Coordination - are the various components and their authors participating in a rigorous process? Can the architectural structure of the system be evaluated across the various components with any consistency? Is there a clear and concise model of each coordinating function in the system?

Transaction - are the various transactions in the system clearly defined? Are they visible? Are they recoverable? Do the transactions have permanence?

Repository - is the data in the system isolated from the processing components?

Type management - is there a mechanism for defining and maintaining the metadata for each data and process type?

Security - have the security attributes of the system been defined before the data and processing aspects?

Architecture Management

The computational specifications of the system are intended to be distribution-independent. Failure to deal with this transparency is the primary cause of difficulty in the implementation of a physically distributed, heterogeneous system in a multi-organizational environment. Lack of transparency shifts the complexities from the applications domain to the supporting infrastructure domain. In the infrastructure domain, there are many more options available to deal with transparency issues. In the application domain,

Access - hides the differences in data representation and procedure calling mechanisms to enable internetworking between heterogeneous systems.

Location - makes the use of physical addresses, including the distinction between local and remote resource usage.

Relocation - hides the relocation of a service and its interface from other services and the interfaces bounded by it.

Migration - masks the relocation of a service from that service and the services that interact with it.

Persistence - masks the deactivation and reactivation of a service.

Failure - masks the failure and possible recovery of services, to enhance the fault tolerance of the system.

Transaction - hides the coordination required to satisfy the transactional properties of operations. Transactions have four critical properties: Atomicity, Consistency, Isolation, and Durability. These properties are referred to as ACID [Bern97]. Atomicity means that the transaction execute to completion or not at all. Consistency means that the transaction preserves the internal consistency of the database. Isolation means the transaction executes as if it were running alone, with no other transactions. Durability means the transaction's results will not be lost in a failure.

System Design Process

The construction of software is based on several fundamental principals. These are called enabling techniques [Busc96]. All the enabling techniques are independent of a specific software development method, programming language, hardware environment, and to a large extent the application domain. These enabling techniques have been known for years. Many were developed in the 1970's in connection with publications on structured programming [Parn72], [Parn85].

Although the importance of these techniques has been recognized in the software development community for some time, it is now becoming clear of the strong link between system architecture and these enabling principles. Patterns for software architecture are explicitly built on these principles.

Abstraction - is a fundamental principle used to cope with complexity. Abstraction can be defined as the essential characteristic of an object that distinguishes it from all other kinds of objects and thus provides crisply defined conceptual boundaries relative to the perspective of the viewer. [Booc94]. The word object can be replaced by component or module to achieve a broader definition.

Encapsulation - deals with grouping the elements of an abstraction that constitute its stricture and behavior, and with separating different abstractions from each other. Encapsulation provides explicit barriers between abstractions.

Information hiding - involves concealing the details of a component's implementation from its clients, to better handle system complexities and to minimize coupling between components.

Modularization - is concerned with the meaningful decomposition of a system design and with its grouping into subsystems and components.

Separation - different or unrelated responsibilities should be separated from each other within the system. Collaborating components that contribute to the solution of a specific task should be separated from components that are involved in the computation of other tasks.

Coupling and Cohesion - are principles originally introduced as part of structured design. Coupling focuses on inter-module aspects. Cohesion emphasizes intra-module characteristics. Coupling is the measure of strength of association established by the connection from one module to another. Strong coupling complicates a system architecture, since a module is harder to understand, change, or to correct if it is highly interrelated with other modules. Complexity can be reduced by architecting systems with weak coupling.

Cohesion measures the degree of connectivity between the functions and elements of a single function. There are several forms of cohesion, the most desirable being functional cohesion. The worst is coincidental cohesion in which unrelated abstractions are thrown into the same module. Other forms of cohesion - logical, temporal, procedural, and informal cohesion are described in the computer science literature.

Sufficiency, completeness, and primitiveness - sufficiency means that a component should capture those characteristics of an abstraction that are necessary to permit a meaningful and efficient interaction with the component. Completeness means that a component should capture all relevant characteristics of its abstraction. Primitiveness means that all the operations a component can perform can be implemented easily. It should be the major goal of every architectural process to be sufficient and complete with respect to the solution to a given problem.

Separation of policy and implementation - a component of a system should deal with policy or implementation, but not both. A policy component deals with context-sensitive decisions, knowledge about the semantics and interpretation of information, the assembly of many disjoint computations into a result or the selection of parameter values. An implementation component deals with the execution of a fully-specified algorithm in which no context-sensitive decisions have to be made.

Separation of interface and implementation - any component in a properly architected system should consist of an interface and an implementation. The interface defines the functionality provided by the component and specifies how to use it. The implementation includes the actual processing for the functionality.

Single point references - any function within the system should be declared and defined only once. This avoids problems with inconsistency.

Divide and conquer strategies - is familiar to both system architects and political architects. By dividing the problem domain into smaller pieces, the effort necessary to provide a solution can be lessened.

Non-Functional Architecture

The non-functional properties of a system have the greatest impact on its development, deployment, and maintenance. The overall abilities of the system are a direct result of the non-functional aspects of the architecture.

Changeability - since systems usually have a long life span, they will age [Parn94]. This aging process creates new requirements for change. To reduce maintenance costs and the workload involved in changing a system's behavior, it is important to prepare its architecture for modification and evolution.

Interoperability - the software systems that result from a specific architecture do not exist independently from other systems in the same environment. To support interoperability, system architecture must be designed to offer well-defined access to externally-visible functionality and data structures.

Efficiency - deals with the use of the resources available for the execution of the software, and how this impacts the behavior of the system.

Reliability - deals with the general ability of the software to maintain its functionality in the face of application or system errors and in situations of unexpected or incorrect usage.

Testability - a system needs support from its architecture to ease the evaluation of its correctness.

Applying These Principles

The following checklist can be used as a guideline for applying these principles.

Develop a vision statement for the system. This vision statement must be acceptable not only to the management and executive team members, but to the end users as well. It is not uncommon to have a wonderfully crafted statement of the systems vision, that can be placed on the boardroom wall, only to have the shop floor user consider the vision out of touch with what actually happens in the real world. Developing the vision statement is not a simple task and should be given sufficient time and effort. This statement will form the foundation of the project and will be used to resolve conflicts in the direction of the development effort - why are we doing this is answered by the vision statement.

The business case process is common is most organizations. The constraints of the financial calculations will be defined ahead of time. The business case must consist of hard - bookable - savings. After these savings have been identified, soft savings can be considered.

The requirements analysis can take place in a variety of forms. The real goal here is to bring out the needs of the user, within the context of good system architecture. The users needs can be captured through interviews, Use Cases, CRC Cards, or a nearly any requirements generation process. The primary goal of the architect is to prevent the requirements from corrupting the underlying system architecture. This tradeoff process requires skill and persistence. In many cases the user will articulate a requirement as a must have behavior of the system. The consequence of this requirement may damage the architectural structure of the system. The architect's role is to incorporate the requirement without upsetting the architecture. This is done by iterating on both the requirements and the architecture until there is the proper fit.

Using the IEC 10746 ODP structure, the architect defines the system from the five (5) viewpoints. The capturing of these viewpoints can be done through any appropriate tool. In the current OO paradigm, the UML notation is a powerful means of describing all five viewpoints. The complete UML language, in conjunction with CRC Cards, can describe the system logical and physical behavior.

The prototyping process provides a powerful means of trying out parts of the system design without the commitment to production. During the prototyping activity, the system architecture is being evaluated against the planned architecture. During this process, the architect must be vigilante to avoid compromising the structural, aspect, and behavioral integrity system without good cause. It is the natural inclination of the developers and end user to accept a work around at this point. This work around will become a permanent undesirable feature of the system if it is accepted without the full understanding of the consequences.

The incremental deployment process should follow the Business Case analysis rollout strategy. The business case describes how the benefits will be booked over time and by which component of the organization. The system deployment must follow this benefit stream in order to accrue the savings.

The transition to production process is a continuation of the incremental deployment. The full training and operational support activities are now deployed.

The operation and maintenance of the system is then turned over to the production staff.

The continuous migration of the system is a process not usually considered part of system architecture. Without the architectural influences on this activity, the system will quickly decay into a legacy set of components.

An Example Architecture

There are numerous examples of layered architecture in the current literature. Presenting one here may appear redundant. However, we need to start some place and the EDM/PDM domain provides unique requirements not always found in general business systems. This example, shown in Figure 5-1, is derived from [Hofm97] and adapted to the manufacturing domain.

In this example architecture the components are partitioned into functional layers:

Workflow - is an application system that implements workflow metaphors for business processes. This component is usually a COTS product or at least a set of components that adheres to the Workflow Management Coalition specifications. The workflow component acts as a glue piece above all the application systems of the enterprise, integrating all the applications. If there is an atomic process to be performed, the work can be performed externally to the workflow system or as part of an application component embedded in the workflow process.

Interface Objects - are made up of two types:

• Dialog Interfaces - provide for the manipulation of kernel objects through graphical user interfaces. The interface objects are typically partitioned into presentation objects and dialog controls that manage the flow of control in the dialog.
  
  
• Batch Interfaces - provide for manipulation of application kernel objects using batch processes. This batch processing is often neglected

Exception Handling - is a common service provided by the standard architecture. Exceptions ride up along the application domain until they reach the upper layer and can be handled by software or made visible to the users. In practice exception handling consists of several exception classes and protocols plus components to map exceptions to meaningful messages for the users.

Application Kernel - is a set of components grouped by structural similarity, not by functional requirements.

• Business transaction objects - a meaningful business process may require several steps or dialogs, which in turn interact with lower level business processes. Business transaction objects are used to control the sequencing of these actions.
  
  
• Application kernel objects - provide the core set of functions needed for EDM or PDM. These functions are usually derived from the analysis of the business.
  
  
• Pure functions - provide a core set of functions used by the application. These functions typically have a narrow interface, perform complex calculations or behavior (management change, format conversion, database processing).

Application System - consists of an interface and a set of application kernel objects that are manipulated through the interface.

Figure 1. A Standard Architecture

Conclusion

This is the conclusion of a five part article. The previous four parts were published on this web site, with the same title.

The Author

Glen B. Alleman, has provided consulting services to a variety of industries and business domains in the industrial and commercial market places. These include, e-commerce systems, publishing systems, information technology strategies, manufacturing systems, engineering design systems, and software process improvement.

He has direct experience in a variety of large scale integration environments and business domains. He also has extensive program and project management experience with multiple concurrent projects involving hardware, software, multiple sites and legacy business systems integration.

Mr. Alleman has deep technical and architectural knowledge of a variety of system paradigms including: client/server, CORBA, and web-based systems.

He is the Principal Consultant for Niwot Ridge Consulting, Niwot, Colorado, www.niwotridge.com.

The Reference section which follows applies to this section only.

References