Architecture-Centered Information Systems In The Manufacturing Domain - Part I - Introduction to Software Architecture

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 I - Introduction to Software Architecture

The use of an architecture-centered design process for delivering information technology began with the introduction of client / server based systems. Early client/server and legacy mainframe applications did not provide the architectural flexibility needed to meet the changing business requirements of the modern manufacturing organization. With the introduction of Object Oriented systems, the need for an architecture-centered process becomes a critical success factor. Object reuse, layered system components, data abstraction, web based user interfaces, CORBA, and rapid development and deployment processes all provide economic incentives for object technologies. However, adopting the latest object oriented technology, without an adequate understanding of how this technology fits a specific architecture, risks the creation of an instant legacy system.

Application software systems must be architected in order to deal with the current and future needs of the business organization. Managing software projects using architecture-centered methodologies must be an intentional step in the process of deploying information systems - not an accidental by-product of the software acquisition and integration process.

Systems requirements are inherently ambiguous, intuitive, and informal. Defining requirements is a right-brain activity. Software is logically unintuitive and meant to be interpreted unambiguously by a machine. Software is a left-brain activity. Architecture bridges the semantic gaps between requirements and software.

Overview

The subject of integration of heterogeneous manufacturing systems is not only complex, it is convoluted and confusing. By focusing on the architecture of the system, the design and development processes have a place to return to when architectural inconsistencies occur.

Much of the discussion in today's literature is centered on applying the building architectural analogies to the design and deployment of information systems.[1] This analogy glosses over many of the difficulties involved in formulating, defining, and maintaining the architectural consistency associated with acquiring Commercial Off The Shelf (COTS) applications. The detailed activities occurring in each of these stages assures that the current business requirements are met by the system, while providing an adaptive architecture to meet the future needs of the organization.

In many COTS products, the vendor has defined an architecture that may or may not match the architecture of the user domain. It is unlikely the vendor's architecture will be a match for an organization that has mature business processes and legacy systems in place. The result is an over-constrained problem.[2].

By acquiring a COTS application and installing it, the end user may have unknowingly acquired the architecture of the application's vendor. The consequences of this decision may not be known for some time. If the differences between the target architecture of the business and the architecture supplied by the vendor are not determined before the acquisition of the COTS product these gaps will be revealed during the systems operation - much to the disappointment of the purchaser.

Footnotes

[1] Many of these architectural analogies are based on mapping the building architecture paradigm to the software architecture paradigm. If this were the actual case software systems would be built on rigid immovable foundations, with fixed frameworks and inflexible habitats and user requirements. In fact, software architecture is more analogous to urban planning.

The macro level design of urban spaces is provided by the planner, with infrastructure (utilities, transportation corridors, and habitat topology) defined before any buildings are constructed. The actual dwelling spaces are built to broad standards and codes. The individual buildings are constructed to meet specific needs of their inhabitants. The urban planner visualizes the city-scape on which the individual dwellings will be constructed. The dwellings are reusable (remodeling) structures that are loosely coupled to the urban infrastructure. Using this analog, dwellings are the reusable components of the cityscape, similar to application components in the system architecture. In both analogies, the infrastructure forms the basis of the architectural guidelines. This includes, utilities, building codes, structural limitations, materials limitations, and local style [Alex79], [Alex77].

[2] In many real life applications, there does not exist a solution to a problem that satisfies all the constraints. Such systems are called over constrained systems. An example might be the selection of matching clothes (shirt, shoes, and pants). There are red and white shirts, cordovan and sneaker shoes, and blue, denim, and gray pants. If the following matching constraints are used - Shirts and Pants: {(red, gray), (white, blue, (white, denim)}; Shoes and Pants: {(sneakers, denims), (cordovans, gray)}; Shirts and Shoes: {(white, cordovans)}, there is no solution.

What is Software Architecture?

The term architecture is so overused in the software business, that it has become a clich. There are "official" descriptions of software architecture and architects. Much of the architecture work has taken place inside development organizations and academia. In this paper, the description of architecture is taken from a variety of reliable sources.

Software architecture is defined as the generation of the plans for information systems, analogous to the plans for an urban dwelling space. Christopher Alexander [Alex77], [Alex79] (the inventor of design patterns) observed that macro-level architecture is made up of many repeated design patterns. Software architecture is different from software design. The architecture is a view of the system as a whole rather than a collection of components assembled into a system. This holistic view forms the basis of the architecture-centered approach to information systems. Architecture becomes the planning process that defines the foundation for the information system.

Distributed object computing and the Internet have fundamentally changed the traditional assumptions for architecting information systems. The consequences of these changes are not yet fully understood by the developers as well as consumers of these systems.

The current distributed computing (client/server) and Internet-based systems are complex, vulnerable, and failure-prone. This complexity is the unavoidable consequence of the demand for ever-increasing flexibility and adaptability. These rapidly changing technologies require a different planning mechanism, one based on fundamentally new principles. Because technology is changing at a rapid pace and user business requirements are becoming more demanding, the architecting these new systems is now essential. No longer can systems be simply assembled from components without consideration of the whole [Foot97].

Architecture is not the creation of boxes, circles, and lines, laid out in presentation slides [Shaw96], [Shaw96a]. Architecture imposes decisions and constraints on the process of designing, developing, and deploying information systems. [Adow95], [Alle94], [Kazm96], [Perr92]. Architecture must define the parts, the essential external characteristics of each part, and the relationships between these parts in order to assure a viable outcome.

Architecture is the set of decisions about any system that keeps its implementers and maintainers from exercising needless creativity.

The architecture of a system consists of the structure(s) of its parts, the nature and relevant externally visible properties of those parts, and the relationships and constraints between them [D'Sou99].

Architecture Based IT Strategies

Much has been written about software and system architecture. What is architecture and why is it important to the design and deployment of software applications in the manufacturing domain?

Manufacturing information systems possess a unique set of requirements, which are continuously increasing in complexity. In the past, it was acceptable to provide manufacturing information on a periodic basis. This information is gathered through a data entry process that was labor intensive and error prone. In the current manufacturing environment, the timeliness and accuracy of information has become a critical success factor [3] in the overall business process.

In the past, manufacturing information was usually provided through a monolithic set of applications (mainframe based MRP systems). [4] This critical data was trapped inside the applications, which were originally designed to liberate the workforce from mundane data processing tasks [Bryn98], [Bryn93].

However, without flexibility and adaptability, the users were forced to adapt their behaviors to the behaviors of the system. The result was a recurring unrecoverable cost burden on the organization. What was originally the responsibility of the software - as defined in the Systems Requirements Analysis - becomes the burden of the user [Bryn98], [Schr97], [Bryn93]. In the manufacturing environment, this includes multiple and inconsistent data entry tasks, report printing and reentry, inconsistent database information, islands of information and automation, and the inability to adapt to the changing needs of the organization.

The approach of scheduling multi-product batch production activities using an MRP system has given way to customer driven massive customization production with just-in-time everything [Maho97]. It also has become more difficult to predict customer demand for configured products. This adds to the complex problem of manufacturing, planning, and production scheduling.

Any replacement of the legacy manufacturing system that supports batch production must provide:

• Support for manufacturing processes that can be quickly modified and expanded as production demand changes.
  
  
• A mechanism to address the previously well-defined boundary between product production, product design and business and financial management.
  
  
• A migration path away from the traditional product bills-of-material approach to production scheduling. This previous approach has given way to configured bills-of-material, generated at the time the order is taken, supported by just-in-time component suppliers.

An effective manufacturing system architecture must somehow combine production control systems and information systems. [5] Most approaches in the past elected to keep these two systems separate but linked, adapting them to make intersystem communication transparent.

However, this strategy fails to address the important problem of how to restructure the manufacturing operations to meet the demand of future operations. An alternative approach is to integrate the Manufacturing Control System (MCS) with the Manufacturing Information System (MIS) as a federated heterogeneous system. Production personnel can then make use of the MIS maintained information (design and product information) directly on the shop floor. In turn, design and support personnel can then gain direct access to production information.

The complexity of this massive customization and just-in-time manufacturing environment means that the software components, and the work processes they support, are in constant flux. For an integrated manufacturing system to function in this way, software systems must be continuously expanded, modified, revised, tested, and repaired. The software components must be integrated quickly and reliably in response to rapidly changing requirements. Finally, such a system must cooperate in addressing these changing objectives. All these requirements define a highly flexible, adaptive architecture capable of operating in rapidly changing conditions [Mori98].

In order to address these needs, the system architecture must proceed along the following path:

• Define the goals of the business in a clear and concise manner, using a notation that is readable by both humans and machines.
  
  
• Identify the Information Technology already in place that meets these goals.
  
  
• Identify gaps in the levels of Information Technology that fail to meet these goals.
  
  
• Identify the organizational structure needed to support the implementation of the strategy.
  
  
• Define a layered framework for connecting the system components.

Footnotes

[3] Dr. John Rockhart from MIT's Sloan School of Management is the source of the concept of Critical Success Factors (CSF). The CSF's for a business are associated with its industry, competitive strategy, internal and external environmental changes, managerial principles, and a CEO perspective.

[4] The mainframe environment has been tagged with the monolithic label for some time. Now that mature client/server applications have been targeted for replacement, they too have been labeled monolithic. It is not the mainframe environment that creates the monolithic architecture, it is the application's architecture itself that results in a monolithic system being deployed. This behavior occurs when the data used by the application is trapped inside the code. Separating the data from the application is one of the primary goals of good software architecture. This separation however, must take into account the semantics of the data, that is the meaning of the data. This meaning is described through a metadata dictionary which is maintained by the architect.

[5] At this point, the separation between information systems and manufacturing systems is somewhat artificial. A Manufacturing Control System (MCS) can be defined as the software components that control the scheduling, material planning and production activities [Voll97]. The information processed by the MCS typically includes Bills-of-Material, Shop Floor Scheduling, Production Planning, Customer Configuration Instructions, Work Instructions, etc. A Manufacturing Information System (MIS) can be defined as the software components that author, distribute, inform, and interact with manufacturing personnel. The information conveyed by these systems is not directly involved in the scheduling and production of products, but rather forms the basis of these activities.

The information processed by the MIS typically includes: Model and Drawing information, Planning Bills-of-Material, Product Support Information, Quality Assurance Information, etc.

Information Systems in Manufacturing

In the traditional information systems domain the operational improvements of the shop floor are the primary focus of IT.

By expanding the scope of the IT Strategy to include all aspects of manufacturing, from order entry to product shipment, an overall architecture of the information systems can be constructed.

Although this note is targeted at generic systems architecture, it is useful to outline the manufacturing systems that are subject to these architectural constraints.

Operations Improvement - the operational information systems provide the tools needed to run the business on a day-by-day basis. They provide real time information about costs, productivity, and operational efficiency. They include information, work planning and operational control for:

• Materials management
  
  
• Flexible manufacturing
  
  
• Machine tool control
  
  
• Automated process control

Advanced Manufacturing Technologies - the control of machinery through automated work instructions, machine tool instructions, and other non-human intervention processes that contribute directly to the bottom line of the business.

Information Systems - the application software that forms the basis of the operational efficiency and advanced machine control, is dependent on the order entry, production scheduling and shop floor control facilities provided by:

• MRP - manufacturing resource planning. Is a set of techniques that uses bill of material data, inventory data, and the master production schedule to calculate the requirements for materials.
  
  
• ERP - enterprise resource planning. Is an accounting oriented information system for identifying and planning enterprise wide resources needed to take, make, ship, and account for customer orders.
  
  
• PDM - product data management.
  
  
• EDM - enterprise document management. Is an infrastructure system, which document-enables business process and application through workflow and a document repository. The primary function of EDM is to manage the change to business critical documents and delivery these document to the proper user at the proper time.

Characteristics of Manufacturing Technologies

There are several characteristics of manufacturing systems that are shared by systems with good architectural foundations. These properties may appear abstract and not very useful at first. However, they are measurable attributes of a system that can be used to evaluate how well the architecture meets the needs of the user community.

Openness - enables portability and internetworking between components of the system.

Integration - incorporates various systems and resources into a whole without ad-hoc development.

Flexibility - supports a system evolution, including the existence and continued operation of legacy systems.

Modularity - the parts of a system are autonomous but interrelated. This property forms the foundation of flexibility.

Federation - combining systems from different administrative or technical domains to achieve a single objective.

Manageability - monitoring, controlling, and managing a system's resources in order to support configuration, Quality of Service (QoS), and accounting policies.

Security - ensures that the system's facilities and data are protected against authorized access.

Transparency - masks from the applications the details of how the system works.

Motivations for Architecture-Centered Design

The manufacturing domain creates a unique set of requirements, not found in other business information system environments. By focusing on the non-functional requirements for manufacturing systems, the operational aspects of the software can be isolated from the underlying infrastructure. This isolation provides the means to move the system forward through its evolutionary lifecycle, while minimizing the impacts on the operational aspects of the business processes.

The application of architecture-centered design to manufacturing systems makes several assumptions about the underlying software and its environment:

• Large systems need sound architecture. As the system grows in complexity and size, the need for a strong architectural foundation grows as well.
  
  
• Software architecture deals with abstraction, decomposition and composition, and style and aesthetics. With complex heterogeneous systems, the management of the system's architecture provides the means of controlling this complexity.
  
  
• Software architecture deals with the design and implementation of systems at the highest level. Postponing the detailed programming and hardware decisions until the architectural foundations are laid.

Architectural Principles

Software architecture is more of an art than a science. This note makes no attempt to present the subject of software architecture in any depth, since the literature is rich with software architecture material. There are several fundamental principles however to hold in mind:

Abstraction / Simplicity - simplicity is the most important architectural quality. Simplicity is the visible characteristic of a software architecture that has successfully managed system complexity

Interoperability - is the ability to change functionality and interpretable data between two software entities. Interoperability is defined by four enabling requirements:

• Communication - the mechanisms used to communicate between the system components.
  
  
• Request Generation - the verbs used in the communication process.
  
  
• Data Format - the syntax used for the nouns.
  
  
• Semantics - the intended meaning of the verbs and nouns.

Extensibility - is the characteristic of architecture that supports unforeseen uses and adapts to new requirements. Extensibility is a very important property for long life cycle architectures where changing requirements will be applied to the system.

Interoperability and extensibility are sometimes conflicting requirements. Interoperability requires constrained relationships between the software entities, which provides guarantees of mutual compatibility. A flexible relationship is necessary for extensibility, which can be easily extended into areas of incompatibility.

Symmetry - is essential for achieving component interchange and reconfigurability. Symmetry is the practice of using a common interface for a wide range of software components. It can be realized as a common interface implemented by all subsystems or as a common base class with specializations for each subsystem.

Component Isolation - is the architectural principle that limits the scope of changes as the system evolves. Component isolation means that a change in one subsystem will not require a change in another.

Metadata - is self-descriptive information, which can describe services, and information. Metadata is essential for reconfigurability. With Metadata, new services can be added to a system and discovered at runtime.

Separation of Hierarchies - good software architecture provides a stable basis for components and system integration. By separating the architecture into pieces, the stability of the whole may sometimes be enhanced.

Architectural Styles

Architectural style in software is analogous to an architectural style in buildings. An architectural style defines a family of systems or system components in terms of their structural organization. An architectural style expresses components and relationships between these components, with constraints on their application and the associated composition and design rules for their construction [Perr92], [Shaw96], [Garl95].

Architectural style is determined by:

• The component types that perform some function at runtime (e.g., a data repository, a process, or a procedure).
  
  
• The topological description of these components indicating their runtime interrelationships (e.g., a repository hosted by a SQL database, processes running on middleware, and procedures created through user interaction with a graphic interface).
  
  
• The semantic constraints that will restrict the system behavior (e.g., a data repository is not allowed to change the values stored in it).
  
  
• The connectors that mediate communication, coordination, or cooperation among the components (e.g., protocols, interface standards, and common libraries).

There are several broad architectural styles in use in modern distributed systems and several detailed substyles within each broad grouping [Shaw96], [Abow95].

Because practical systems are not constructed from one style, but from a mixture of styles, it is important to understand the interrelationship between styles and their affect on system behavior.

This analysis:

• Brings out significant differences that affect the suitability of a style for various tasks, the architect is empowered to make selections that are more informed.
  
  
• Shows which styles are variations of others, the architect can be more confident in choosing appropriate combinations of styles.
  
  
• Allows the features used to classify styles to help the designer focus on important design and integration issues by providing a checklist of topics.

4 + 1 Architecture

There are many architectural paradigms in the market place. The 4+1 paradigm is used here to focus the system architecture of the decomposition of the architectural components into a COTS based view of the system

In many projects, a single diagram is presented to capture the essence of the system architecture. Looking carefully at the boxes and lines in these diagrams, the reader is not sure of the meaning of the components. Do the boxes represent computers? Blocks of executing code? Application interfaces? Business processes? Or just logical groupings of functionality?

One approach to managing architectural style is to partition the architecture into multiple views. This multiple view paradigm is based on the work of [Kruc95], [Adow93], [Perr92], [Witt94]. The 4+1 Architecture describes the relationship between the four views of the architecture and the Use Cases that connect them.[6] A view is nothing other than a projection of the system description, producing a specific perspective on the system's components.

Figure 1. The 4+1 Architecture

This paradigm will be further developed during the Architectural Planning phase using the ISO/IEC 10746 guidelines.

The system architecture is the structure of a software system. It is described as a set of software components and the relationships between them. For a complete description of an architecture several views are needed, each describing a different set of structured aspects [Hofm97].

For the moment, the 4+1 Architecture provides the following views:

• Logical - the functional requirements of the system as seen by the user.
  
  
• Process - the non-functional requirements of the system described as abilities.
  
  
• Development - the organization of the software components and the teams that assemble them.
  
  
• Physical - the system's infrastructure and components that make use of this infrastructure.
  
  
• between the system and its environment or between the internal objects involved in a particular execution of the system.

There are numerous techniques used to describe the architectural views of a system: algebraic specifications [Wirs90], entity relationship diagrams [Chen76], automata [Hopc79], class diagrams [Rumb91], message sequence diagrams [ITU94], data flow diagrams [DeMarc79], as well as many other. In this note the Unified Modeling Language (UML) combines many of these notations and concepts into a coherent notation and semantics [Booc99], [Fowl97], [D'Sou99].

Footnotes

[6] The Use Case notation has become popular in object oriented design and development. The Use Case specifies the sequence of actions, including any variants, that a system can perform, interacting with actors of the system. [D'Sou99], [Jaco92], [Schn98].

Moving From 4+1 Architecture to Methodologies

Now that the various components of system architecture are established, the development of these four architectural components must be placed within a specific context. This is the role of an architectural methodology.

In the 4+1 architecture the arrangements of the system components are described in constructive terms - what are the components made of. The next step in the process is to introduce a business requirements architecture process. The business requirements will drive the architecture. Without consideration for these business requirements, the architecture of the system would be context free. By introducing the business requirements, the architecture can be made practical in the context of the business and therefore become generative.

These business requirements are not the business functions, but rather the functional and non-functional requirements of a system to support the business functions.

Structure Matters

From the beginnings of software engineering, structure has been the foundation of good architecture [Parn72], [Dijk68]. There are some basic tenets that can be used to guide the architecture-centered deployment [Clem96]:

• Systems can be built in a rapid, cost-effective manner by importing (or generating) large externally developed components.
  
  
• It is possible to predict certain qualities about a system by studying its architecture, even in the absence of detailed design documents.
  
  
• Enterprise-wide systems can be deployed by sharing a common architecture. Large-scale reuse is possible through architectural level planning.
  
  
• The functionality of a system component can be separated from the component's interconnection mechanisms. Separating data and process is a critical success factor for any well architected system

Conclusion of Part I

This is part I of a five part note. The next part describes 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 I