Architecture-Centered Information Systems In The Manufacturing Domain - Part III - Steps in the Architecture Process

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 III - Steps in the Architecture Process

Without a framework for defining architecture and the steps in which it participates, it is difficult to grasp the impact architecture has on the outcome of the system process.

The process of discovering, defining, and maintaining an architecture for a specific set of requirements and the applications that support them is a non-trivial task [Garl95], [Abow95]. There is a distinct difference between architecture and engineering [Rech97]. Generally speaking, engineering deals with measureables using analytical tools derived from mathematics and the hard sciences - engineering is a deductive process. Architecture deals largely with unmeasurables using non-quantative tools and guidelines based on practical lessons learned - architecture is in inductive process.

The steps taken during the development of a system architecture include:

• Vision of the System - the purpose, focus, assumptions, and priorities of the system.
  
  
• Business case analysis - how will the system earn its keep?
  
  
• Requirements analysis - the external behavior and appearance of the system.
  
  
• Architecture planning - the mapping between the requirements and the software.
  
  
• System prototyping - the construction of a prototype system, complete with all the components. This prototype can be used to verify the abilities of the final system.
  
  
• Project management - the professional management of the project, including resources, risk, and deliverables [PIM96].
  
  
• Architecture prototyping - the construction of an architecture platform to verify the abilities of the system components.
  
  
• Incremental deployment - the deployment of the system in a production environment. This deployment must allow for the incremental functionality of the system, while verifying the capabilities of the application.
  
  
• System transition - move the incrementally deployed system into full production.
  
  
• Operation and maintenance - a phase of the system in which all functionality is deployed and the full bookable benefits are being accrued.
  
  
• Continuous migration - an activity that continuously makes improvements to the system, within the architectural guidelines [Foot97].

The Vision of the System

The construction of a Vision is a wickedly subtle process. When first asked to articulate a "vision" the system stake holders usually ask "why, it is obvious what we want the system to do." The reality is that the vision statement includes not only the technical aspects of the system, but also the social, political, economic and operational aspects of the system.

The purpose, focus, assumptions, and priorities of a software project are essential elements of an enterprise-wide vision statement. If any of these elements change during system acquisition and deployment, there is a significant risk that the models used to define the system will be obsolete. The first step in an architecture-centered development methodology is to establish a viable vision statement, with the assumption that it should not be changed once acquisition and deployment have begun. Any changes that occur in the vision must be reflected in the project models and subsequent analysis and design.

The vision statement becomes a binding agreement between the software suppliers and the software consumers - users of the system. This vision statement must be succinct, ranging from a single slide to less than 10 pages of text. The vision statement establishes the context for all subsequent project activities, starting with Requirements Analysis and ending with the Continuous Migration of the system.

Business Case Analysis

The creation of a Business Case Analysis is a critical success factor for any system project. Without a clear understanding of the costs and benefits of the proposed system architecture, the decision-makers cannot be presented with complete information. The style of the business case as well as the contents of the analysis is usually an organization specific issue.

Requirements Analysis

A project's requirements define the external behavior and appearance of the system without specifying its internal structure [Somm97], [Jack96]. External functional behavior, however, includes internal actions needed to ensure the desired non-functional requirements of the external behavior. The external appearance comprises the layout and navigation of the user interface screens, transaction processing activities as well as the behavior of the system in terms of its abilities. These abilities are usually defined as adjectives for the properties that system possesses. Reliability, Availability, Maintainability, Scalability, Performance, Testability, Efficiency, Reusability, Interoperability, and Changeability as well as other non-functional properties of the system architecture.

An effective approach for capturing behavioral requirements is through Use Cases, which consist of top-level diagrams and extensive textual descriptions [Schn98], [Buhr96], [Lamr97]. The Use Case notation is deceptively simple but has one invaluable quality - it enforces abstraction. It is one of the most effective notations devised for expressing complex concepts and a powerful way to ensure the top-level requirements are represented with simplicity and clarity.

Figure 1. - Use Case for Order Taking and Fulfillment.

Each circle, or individual Use Case, is accompanied by a description of relevant requirements. It usually takes the form of a list of sequential actions described in domain-specific prose. Use Case definitions are developed jointly with domain experts and provide a domain model of the system for the purpose of defining architecture. Once system integration and deployment begins, Use Cases are extended with system-specific scenario diagrams that will be elaborated in workflow, procedural changes and system tests [Buhr96], [Jaco92], [Schn98].

The appearance, functionality, and navigation of the user interface are closely related to the Use Cases. Here, low fidelity prototyping - drawing the screens with paper and pencil - often proves effective. Again, end-user domain experts must be involved in the screen-definition process.

With the Use Cases and user interfaces defined, the context for architectural planning has been established. In addition to generating documentation (including paper-and-pencil sketches or output from CASE tools), the architecture team acquires a better understanding of the desired system capabilities in the context of the end-user domain.

Use Cases provide the visible means of capturing the external behavior of the system. The next step in the requirements analysis is to partition the nouns and noun phrases, verbs and verb phrases. This activity can be done through Class-Responsibility-Collaboration (CRC) Cards. This tool identifies and specifies the data and processes of the system in an informal manner [Bell98]. The CRC Card method is based on the theory of role-playing in which the participants have specific knowledge about their own roles and make requests of other participants to gain knowledge of their roles. Through this role-playing the nouns and verbs of the system are revealed.

4+1 and UML

If the UML is to be used in the development of the system architecture described in 4+1, then the different components of the UML must be assigned specific roles [Tanu98]:

Table 1. UML to 4+1 Mapping

Architecture Planning

The process of "planning" the architecture involves more than listing the attributes of the system. It involves a deep understanding of how the elements of the architecture interact with each other as well as external elements. By their nature requirements are vague and ambiguous. Treating requirements elicitation like code development will surely lead to a disappointing result.

Requirements are inherently ambiguous, intuitive, and informal. Requirements are a right-brain activity. Software is logically unintuitive (i.e., hard to decipher) and meant to be interpreted unambiguously by a machine. Software is a left-brain activity. Architecture bridges the semantic gap between the requirements and software.

Architecture's first role is to define the mapping between the Requirements and the Software. It captures intuitive decisions in a more formal manner, making it useful to programmers and system integrators, and defines the internal structure of the system before it is turned into code so that current and future requirements can be satisfied.

However, architecture also has another significant role: it defines the organization of the software project. Architecture planning is the missing link in many software projects, processes, and methods, often because no one is quite sure what architecture really is [Rech97], [Perr92], [Kruc95], [Bass98], [Shaw96]. One framework for defining software architecture is provided by the ISO standard for Open Distributed Processing (ODP) called the International Standard ISO/IEC 10746 (ITU X.900), 1995.[8]

Footnotes

[8] There are other frameworks promulgated in the industry, ranging from commercially based paradigms to government standards: Software Engineering Institute, Manufacturing Systems Integration Division, National Institute of Standards and Technology, Department of Defense, and Quality Function Deployment. There is no universal standard for software architecture. The ODP is a generic set of guidelines appropriate for client/server environments as well as the emerging Internet and object oriented paradigms. The ODP defines five viewpoint references (enterprise, information, computational, engineering, and technology). When used in conjunction with good system engineering practices and proven software development and system engineering guidelines, the ODP provides a clear and concise framework for the deployment of manufacturing centric systems. In addition to the ODP guideline several other architectures are in use today that require examination. The Zachman Framework [Zach87] is a traditional architectural approach that is not object oriented. It is a reference model with 30 architecture viewpoints based on two paradigms: Journalism (who, what, when, where, why, and how) and Construction (planner, owner, builder, designer, and subcontractor). Domain analysis which transforms project-specific requirements into general domain requirements for familiar systems. The 4+1 view model which is closely tied to UML and the Rational Unified Process. Many other architectural styles are defined in [Shaw96].

ODP is a way to think about complex systems that simplifies decision-making. It organizes the system architecture in terms of five standard viewpoints [ISO94a], [ISO94b], [ISO94c], [ISO94d]:

• Enterprise viewpoint - the purpose, scope, and policies of the business system as defined by the workflows and business rules.
  
  
• Information viewpoint - the semantics of information and information processing.
  
  
• Computational viewpoint - the functional decomposition of the system in modules, interfaces and the messages exchanged across the interfaces.
  
  
• Engineering viewpoint - the infrastructure required to support the distributed environment.
  
  
• Technology viewpoint - choice of technology for the implementation of the system.

Figure 2. The RM-ODP Viewpoints and Software Engineering, from [ISO94a]

Each viewpoint defines the conformance to the architectural requirements. Without this conformance to requirements, the architecture is meaningless, because it will have no clear impact upon implementation. ODP facilitates this process by embodying a pervasive conformance approach. Simple conformance checklists are all that are needed to identify conformance points in the architecture.

The ODP+4 methodology - based on the 4+1 Architecture [Kruc95] - generates an Open Distributed Processing architecture as well as formal and informal artifacts, including the Vision Statement, the Use Case-based requirements, the rationale and the conformance statements.

Enterprise Viewpoint

The enterprise viewpoint defines the business purpose and policies of the system in terms of high-level enterprise objects. These business-object models identify the essential constraints on the system, including the system objective and important policies. Policies for business objects are divided into three categories:

• Obligations - what must be performed by the system.
  
  
• Permissions - what can be enforced by the system.
  
  
• Prohibitions - what must not be performed by the system.

A typical Business Enterprise Architecture comprises a set of logical object diagrams (in UML notation), and prose descriptions of the diagram semantics [Larm97]. The language of the enterprise view is concerned with the performable actions that change policy, such as creating an obligation or revoking permission.

Figure 3. UML notation for describing the enterprise-wide data objects for a sales company.

When preparing the enterprise viewpoint specification, policies are determined by the organization rather than imposed on the organization by technology implementation choices.

Information Viewpoint

The information viewpoint identifies what the system must know, expressed as a model, emphasizing attributes that define the system state. Because ODP is an object-oriented approach, the models also include essential information processes encapsulated with attributes, thus following the conventional notion of an object.[9]

Architectural objects are not programming objects. The information objects do not denote objects that must be programmed. On the other hand, the architecture does not exclude this practice. Architecture objects represent positive and negative constraints on the system. Positive constraints identify things that the system's software must do. Negative constraints are things that the system's software does not have to do. Knowledge of these constraints aids the designers because it eliminates much of the guesswork in translating requirements to system. Architects should focus their modeling on the system aspects of greatest risk, complexity, and ambiguity, leaving straightforward details for the development step. The information model does not constitute an engineered design. In particular, engineering analysis, such as database normalization, is explicitly delegated to the development activities.

Footnotes

[9] This Object Oriented approach is motivated by several forces:

• Vendors use Object Oriented (OO) methodologies to define the architecture of their products. In some cases the OO components are provided through a gateway creating a traditional system with OO wrappers. In other products the system is constructed using OO technologies. Other systems are hybrids of OO and traditional client/server and SQL database technologies.
  
  
• OO architecture pervades the Internet
  
  
• OO is a better means of analyzing systems requirements using UML, Use Cases, and CRC Cards.

Computational Viewpoint

The computational viewpoint defines the top-level application program interfaces (API). These are fully engineered interfaces for subsystem boundaries. During implementation, the system integration team will develop application modules that comply with these boundaries. Architectural control of these interfaces is essential to ensuring a stable system structure that supports change and manages complexity.

The computational viewpoint specification defines the modules (objects, API's, subsystems) within the ODP system, the activities with these modules, and the interactions that occur among them. Most modules in the computational specification describe the application functionality. These modules are linked through their interaction descriptions.

The CORBA Interface Definition Language (IDL), an ISO standard notation for ODP computational architectures, becomes a fundamental notation for software architects at these boundaries. It has no programming language and operating system dependencies, and can be translated to most popular programming languages for both CORBA and Microsoft technology bases (i.e., COM/DCOM).

Engineering Viewpoint

The engineering viewpoint defines the infrastructure requirements independent of the selected technologies. It resolves some of the complex system decisions, including physical allocation, system scalability, and communication qualities of service (QoS), and fault tolerance.

The benefit of using the ODP is it separates the various concerns (design forces) during the architecture process. The previous viewpoints resolved other complex issues of less concern to distributed systems architects, such as APIs, system policies, and information schemas. Conversely, these other viewpoints were able to resolve their respective design forces, independent of distribution concerns. Decisions must be made regarding system aspects such as object replication, multithreading, and system topology. It is during this activity that the physical architecture of the system is developed.

Technology Viewpoint

The technologies that will be used to implement the system are selected in this view. All other viewpoints are fully independent of these technology decisions. Since the majority of the architecture design process is independent of the deployed hardware, commercial technology evolution can be readily accommodated.

A systematic technology selection process includes initial identification of the conceptual mechanisms (such as persistence or communication). Specific requirements of the conceptual mechanism are gathered from the other viewpoints and concrete mechanisms such as DBMS, OODBMS, and flat files are identified. Then specific candidate mechanisms are selected from available products. Other project factors, such as product price, training needs, and maintenance risks, are considered at this point. It is important to restate the rationale behind these selections, just as it is important to record the rationales for all viewpoints as future justification of architectural constraints.

Many projects wrongly consider this technology view as system architecture. By developing the technical viewpoints before the other ODP architectural views, the project is turned upside down.

Conclusion of Part III

This is part III of a five part note. The next part covers moving from the planning to implementation.

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.

References - Part III