Architecture-Centered Information Systems In The Manufacturing Domain - Part IV - Moving From Planning to Implementation

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 IV - Moving from Planning to Implementation

This section covers the steps involved to move from Planning to Implementation.

Prototyping the System

Screen definitions from the System Requirements Analysis can be used to create an on-line mockup of the system to show to end users and managers. Dummy data and simple file I/O can provide a realistic simulation for the essential parts of the user interface. End users and architects then jointly review the mockups and run through the Use Cases to validate requirements. Often, new or modified requirements will emerge during this interchange. Print outs of these modified screens can be created and marked up for subsequent development activities. Any modifications to requirements are then incorporated into the other architectural activities.

Through the mockup, management can see visible progress, a politically useful achievement for most projects, that reduces both political and requirements-oriented risk. With rapid prototyping technologies such as screen generation wizards, mockups of most systems can be rapidly constructed.

Building Block Based Development

There are two distinct approaches to acquiring and deploying software systems:

Product based - which solves specific problems using components of individual systems. These components can be integrated to form a complete system, but the resulting integration may or may not possess the attributes of good architecture.

Asset based - which solves problems in different contexts using components that are architected to provide services greater than the sum of their parts.

Figure 1. The process of reusing asset base software systems.

In Figure 1, the architects' role is to of avoid the inclusion of the product based must have requirements that corrupt the architecture.

Building Blocks of the Prototype

Building blocks are an architectural paradigm that provides the means to construct system along three dimensions [TOGAF00]:

Structure - determine the system decomposition parts and the relationship between the parts.

Aspects - model the functional decomposition of the system.

Behavior - deals with processing that takes place within the system.

Structure should be considered the most important of the three, since it is through structure that the system complexity can be reduced.

This is the primary motivation for the architecture-centric view management of structure. Without control of structure, the resulting system is simply a collection of parts. Gaining any synergy from the collection is now longer possible without a structural framework in which to place the components and their interacting interfaces.

The building blocks of a manufacturing system are usually centered on the ERP system, since the Bill of Material is owned by this application. In order to avoid a detailed discussion of ERP and its relationship with other business applications, a set of generic building blocks can be developed which can be used for all manufacturing applications.[10]

Figure 2 - Generic Building Blocks of the system architecture

Footnotes

[10] Many ERP vendors provide toolkits for customizing the applications. In the past this approach was seen as a competitive advantage for both the vendor and the user. It is now understood that this approach is very expensive in terms of maintenance, upgrades, and continued operations and support. The tailoring aspects should be viewed from the user interface and federation interface paradigm, rather than tailoring the core functionality of the system. [Aust98], [Upto97]

Managing the Project

As the final step in the pre-development process, the project management team plans and validates the deployment schedule to resolve resource issues including staffing, facilities, equipment, and commercial technology procurement [PMI96].

At this stage the schedule is defined for the parallel incremental, external and internal activities performed during Incremental Development. External increments support risk reduction with respect to requirements and management support. Internal increments support the efficient use of development resources - for example, back-end services used by multiple subsystems. Current best practices suggest performing several smaller internal increments that support larger scale external increments, the so - called V-W staging approach [Redm97], [Cock95], [Cock99], [Boeh88].

The architecture-centric process provides for the use of parallel increments. Since the system is partitioned into well-defined computational boundaries, integration teams can work independently and in parallel with other teams, each within their assigned boundaries. Integration planning includes increments spanning architectural boundaries.

The plan should be detailed for early increments and include re-planning activities for later in the project, recognizing the reality that project planners do not know everything up front. At this stage, the team should prepare a risk mitigation plan that identifies technical backups. The integration team involved in mockup and architecture prototyping should continue to build experimental prototypes using the relatively higher-risk technologies well in advance of most developers. This run-ahead team is an essential element of risk mitigation [Sist94], [Redm97], [McCo96], [Karo98], [Hump89], [Doro96], [Boeh91].

The final activity in project management planning is the architectural review and startup decision. Up to this point, the enterprise sponsors have made relatively few commitments compared to the full-scale deployment costs (about 25% of system cost). Executive sponsors of the project must make a business decision about whether to proceed with the system. This executive commitment will quickly lead to many other commitments that are nearly impossible to reverse (such as technology lock-in, expenses, and vendor-generated publicity). At this point, the system architects are offering the best possible approach given the current business and technology context.

Prototyping the Architecture

The architecture prototype is a simulation of the system architecture. System API definitions are compiled and stub programs are written to simulate the executing system. This architecture prototype will be used to validate the computational and engineering architectures, including the flow of control and timing across distribution boundaries.

Using technologies such as CORBA, a computational architecture specification can be automatically compiled into a set of programming header files with distributed stubs (on the calling side) and skeletons (on the service side). Processing can be simulated in the skeletons with dummy code. Simple client programs can be written to send invocations across computational boundaries using dummy data. A small number of essential, high-risk Use Cases can be simulated with alternative client programs. At this point, the prototype execution is used to validate conformance with engineering constraints. This is also the time to propose and evaluate changes to the Computational View, Engineering View, or Technology View architectures.

Incremental Deployment of the System

Deployment starts with several essential activities. The integrators must learn and internalize the architecture and requirements. An effective way to achieve this is with a multi-day kickoff meeting, which includes detailed tutorials from domain experts and architects. The results of all previous steps can be leveraged to bring the integrators up to speed. Lectures should be videotaped so that replacement staff can be similarly trained.

Each increment involves a complete development process, including design, coding, and testing. Initially, the majority of the increments will be focused on individual subsystems. As the project progresses, an increasing number of increments will involve integrating multiple subsystems [Cock95], [Cock99].

For most of the software integration activity, the architecture is frozen, except at planned points where architectural upgrades can be inserted without disruption. Architectural stability enables parallel development. For example, at the conclusion of a major external increment, an upgrade might be inserted into the computational architecture before the next increment initiates. The next increment starts with a software upgrade that conforms to the changes. In practice the need for and frequency of such upgrades decreases as the project progresses. The architect's goal is to increase the stability and quality of the solution based on feedback from development experience. A typical project requires two architectural refactorings (upgrades) to get to a stable configuration that is suitable for deployment.

Transitioning the System to Production

Deploying the system to a pilot group of end users is an integral part of the development process. Lessons learned during this initial deployment will be translated to new development iterations. Schedule slips are inevitable, but serious quality defects are intolerable.

Improving quality by refactoring the integration (improving software structure) is an important investment in the system that should not be neglected. At this stage, architectural certification - where the architect confirms that the system implementation conforms to the specifications and properly implements the end users' requirement - becomes extremely important. In effect, the architect should be an impartial arbitrator between the interests of the end users and the developers of the system. If the end users identify new requirements that affect architectural assumptions, the architect can assess the request and work with both sides to plan feasible solutions.

Operating and Maintaining the System

Operations and Maintenance (O&M) is the proving ground to verify if the integration was done right. The majority of system cost will be expended here, and as much as, 70% of the O&M cost will be due to system extensions. The associated requirements and technology changes are the main drivers of continuing development. Typically, half of each integrator's time will be spent trying to figure out how the system works. Architecture-centered development resolves much of this confusion with a clear, concise set of documentation, i.e., the system architecture itself.

Continuous Migration of the System Components

System migration to a follow-on target architecture occurs near the end of the system life cycle. Two major processes for system migration are called Big Bang (or Cold Turkey) and Chicken Little [Ston92], [Brod95]. [11] A Big Bang is a complete, overnight replacement of the legacy system. In practice, Big Bang seldom succeeds; it is a common antipattern for system migration [Brow98]. The Chicken Little approach is more effective and ultimately more successful. It involves simultaneous, deployed operation of both target and legacy systems.

The Cold Turkey approach in which the legacy systems are replaced in-kind with the new systems has many impediments:

• A better system must be promised - the current user base expects that the replacement system will perform significantly better, since the effort necessary to deploy the new system needs to be paid back many times over.
  
  
• Business conditions never stand still - the new system must be capable of evolving with the changing business conditions. As time moves on, the requirements themselves change. Changes in the deployed system must be capable of keeping up.
  
  
• Specifications rarely exist for the current system - by definition, the legacy system is poorly documented.
  
  
• Undocumented dependencies frequently exist in the current system - over time, the legacy system has become customized to meet the previous tactical requirements.
  
  
• Legacy systems are usually too big to be simply cut over from old to new - millions of database entities and hundreds of mainframe applications are tightly coupled to form the legacy system. This complexity becomes a serious burden simply to understand.
  
  
• Management of large projects is difficult and risky - all the problems associated with managing large projects are present.
  
  
• Lateness is rarely tolerated - since the legacy system is mission critical, any delays become exaggerated.
  
  
• Large projects tend to become bloated with new and unjustified features - once the system is opened to migration, all sorts of new features will be required.
  
  
• Homeostasis is prevalent. [12]
  
  
• Analysis paralysis sets in - with all the issues stated above, the analysis activities become bogged down in details

The Chicken Little approach is one in which the system components are incrementally migrated in place until the desired long-term objectives have been reached.

• Controllable - since the scope of each incremental effort can be managed within the overall architecture of the system vision. The failure of one step in the process does not affect the proceeding deployments. In principle, the failure of one step would also not affect future steps. Once the failed step has been corrected, the project would proceed as planned.
  
  
• Only one step fails - there is no Big Bang approach, with an all or nothing result
  
  
• Incremental, over time - effort, budgets, human resources can be incrementally deployed.
  
  
• Conservatively optimistic - success is always in hand with incremental benefits paving the way.

In the Chicken Little approach gateways are integrated between the legacy and target systems. Forward gateways give legacy users access to data that is migrated to the target system. Reverse gateways let target-system users have transparent access to legacy data. Data and functionality migrate incrementally from the legacy to the target system.

In effect, system migration is a continuous evolution. As time moves on, new users are added to the target system and taken off the legacy environment. In the end, it will become feasible to switch off the legacy system. By that time, it is likely that the target system will become the legacy in a new system migration. The target system transition overlaps the legacy system migration. In the Chicken Little approach, Transition, Operations and Maintenance, and Continuous Migration are part of a continuous process of redeploying the system to meet the ever changing needs of the business.

Footnotes

[11] The concept of Chicken Little and Big Bang or Cold Turkey originates from the two references. Stonebraker's paper describes how GTE migrated 10,000 workstations using the business applications from a mainframe environment to a client/server environment [Ston92]. This work was done before the advent of CORBA ORB's and the current trend of wrapping the applications into a federated system through the OO interface. The lessons learned in this work as well as the work at Boeing Aircraft Company in [Ganti95] supports the notion that a good architectural foundation is a mandatory requirement if there is going to be any hope that the outcome will be successful.

[12] hoomeostaosis n.1. the tendency of a system to maintain internal stability owing to the coordinated response of its parts to any situation or stimulus tending to disturb its normal condition or function. 2. A state of psychological equilibrium obtained when tension or a drive has been reduced or eliminated.

Conclusion of Part IV

This is part IV of a five part note. The next part covers applying the methodology.

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