Architecture-Centered Information Systems In The Manufacturing Domain - Part II - 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 II - The Architecture Process

The selection of a specific methodology for capturing, defining, and describing the system architecture is an arbitrary decision. The following methodology is used as an example. Other methodologies can be used as long a they provide a sufficiently rich set of artifacts needed to articulate the requirements and the solutions that meet those requirements

Figure 1 describes the process by which the architecture of the system is discovered, verified, and deployed.

This methodology provides a broad framework in which systems architecture can be put to work. Depending on the specific needs of the organization, each methodology phase may be adapted to the desired outcome. In some situations, the business case and IT Strategy already exist and the technical aspects of the system dominate the effort. In other situations, the framework for thinking about the problem must first be constructed before any actual system construction can take place.

The methodology provides guidelines without overly constraining the solution domain. The methodology is vendor neutral, notation neutral and adaptive to the organization's short and long-term needs. The methodology has been proven in the field, in a wide variety of manufacturing industry environments.

Figure 1. The Methodology Steps

The Methodology and 4+1

The primary components of the methodology that are focused on 4+1 Architecture description are shown in Figure 3. This methodology is deployed in the context of:

Commercial off the shelf (COTS) products integrated into a federated system. The external functionality of a COTS product is defined by the vendor. The behavior of the system is usually fixed in some way, with little or no ability to alter the internal functioning. External behaviors can sometimes be tailored to meet business needs, within the framework of the COTS product.

Line of Business databases used to separate the data from the applications. Legacy applications hold information within their boundaries that must be integrated with the new system. In many instances, it is not feasible to move this legacy data to a new system.

Workflow engines used to manage the business processes. In many environments the work processes are fluid, changing with the business climate. Adapting the work processes to the business process is usually done through some form of workflow.

Using this context, the traditional software development approach to system architecture is not appropriate. Writing software in the COTS environment is a rare occurrence. The 4+1 architecture is adapted to describe the behavioral and best practice attributes of the system. In the COTS domain, the 4+1 Architecture descriptions are now:

Logical - the functional requirements of the business process that are directly implemented by the system. These include any manual processes or custom components that must be provided to work around gaps in the COTS system.

Process - the abilities of the system that are required to meet the business requirements.

Development - the vendor, system integrator, business process, and management teams and resources needed to define, acquire, install, deploy, and operate the system.

Physical - the infrastructure needed to define, acquire, install, deploy, and operate the system.

Scenarios - the Use Cases that describe the sequence of actions between the system and its environment or between the external objects involved in a particular execution of the system.

The design of software systems involves a number of disciplines applied during the various phases of the methodology. In the past, functional decomposition and data modeling was the accepted mechanism for defining the system architecture. The descriptive and generative aspect of these notations has given way to UML based notations.[7] Although the methodology described here is technically independent of any notation or requirements methodology style, there are advantages to using the current state-of-the-art tools.

These include:

• Providing reassurance through graphical descriptions of the system. Using a layered descriptive language, pictures of the system can be constructed at all levels of detail - from high level executive diagrams to programmer's level details of data and processes.
  
  
• Providing generative descriptions, which transform functional decompositions into code templates.
  
  
• Strong textual descriptions, since pictures alone are rarely sufficient to convey the meaning of design.
  
  
• Aesthetic renditions that convey good design principles through a simple, clear, and concise notation.

Footnotes

[7] The Unified Modeling Language (UML) is a formal language used to capture the semantics (knowledge) about a subject and express this knowledge to others, including machines. The modeling aspects of UML focus on understanding a subject and capturing and communicating the knowledge about the subject. The unifying aspects of UML come about through the best practices of the industry, principles, techniques, methods, and tools. Although UML is object oriented it can be used in a variety of software and system settings using the definition of system architectures [Alhi98], [Mull97].

Methodology and the Architecture

Figure 2 presents a rearranged topology for the methodology. This arrangement focuses on applying the architectural principles to the components of the methodology. There are steps in the methodology that are not addressed in Figure 2. Although these steps may be impacted by architecture they are secondary to the Requirements Analysis, Technical System Design, System Development, and System Deployment.

Figure 2. Details of the methodology and its relationship to system architecture.

Methodology for the SRA

The System Requirements Analysis (SRA) includes the discovery of the functional and non-functional requirements that influence the architecture of the system. These requirements are in addition to the business processing requirements of the system [Somm97]:

Functional requirements - are requirements for the system that can be stated as specific behaviors. The following requirements are for the functional architecture not the business processes provided by this functional architecture.

• Abstraction - enables complexity reduction.
  
  
• Encapsulation - deals with grouping of abstractions.
  
  
• Information hiding - conceals details.
  
  
• Modularization - provides meaningful decomposition.
  
  
• Separation - provides separation of collaborating components.
  
  
• Coupling / Cohesion - are measurements of system structure.
  
  
• Sufficiency, completeness, and primitiveness - are properties of components.
  
  
• Separation of policy and implementation - data and process are isolated.
  
  
• Separation of interface and implementation - user interfaces and core processes are isolated.
  
  
• Single point references - referential integrity is maintained.
  
  
• Divide and conquer strategies - modular architecture.

Non-functional requirements - are usually termed the system's abilities and represent a set of attributes of the software and hardware that can be measured. These include:

• Reliability - the robustness of the system in the presence of faults.
  
  
• Scalability - the ability to increase the system's performance with little or no impact on the system architecture.
  
  
• Availability - the ability to deliver services when called upon to do so.
  
  
• Maintainability - the ability to repair the software or hardware with no impact on the system's availability.
  
  
• Performance - the ability to deliver services within the expectations of the users.
  
  
• Repairability - the ability to repair the system without causing consequential damage.
  
  
• Upgradability - the ability to make changes to the hardware and software components without influencing availability.

Methodology for the TSD

The Technical System Design (TSD) develops a detailed description of the system in terms of the multiple views. Each of the views is a refinement of the functionality of the COTS products laid over the business processes.

Enterprise view - describes the scope and policies of business systems across the enterprise. This view considers all the users of the system in an attempt to normalize the requirements so any one set of requirements or user does not dominate the system architecture. This view is based on providing a system that is considered infrastructure.

Information view - describes the semantics (the meaning) of the information and the information processing. This view assumes the information is isolated from the processing and that the processing activities will change over time, while the semantics of the information remains static throughout the lifecycle of the system.

Computational view - describes the functional decomposition of the system. This view decomposes the system into computational units and reconstructs the system in a manner that best supports the functional organization of the system.

Engineering view - describes the infrastructure of the system as seen from the physical components, networks, servers, peripherals, and workstations.

Technology view - describes the technology choices that must be made when selecting vendors for the infrastructure and enabling the COTS components.

Conclusion of Part II

This is part II of a five part note. The next part describes the steps in the architecture process.

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 II