Lean MIS can't miss: Manufacturing information systems

By Nancy Glenn and David Braun

The information systems integration process can be broken down into four steps that help focus and ensure a successful technology choice.

You've established your goals, decided what the needs are, and picked out the team to make it all happen. This month, we'll look at and appraise your solutions.

1. Goal setting (www.isa.org/link/CT0906)
2. Assess needs (www.isa.org/link/CT1006)
3. Team creation (www.isa.org/link/CT1006)
4. Evaluate solutions

As we move into the fourth phase of this integration, you'll see the decisions facing you as these:

1. Will you buy the software or create it in-house?
2. Will your solution be open or proprietary?
3. Do you replace legacy systems or integrate with them?
4. To which architectural designs will you commit?

Build versus buy

Building software in house requires a long-term commitment in staffing to write and maintain the software. If there is no solution on the market for your problem, this may be your only solution. 

However, do not be deluded into thinking this is always the cheaper solution. This requires staff be trained and remain up to date in an object oriented programming language.

If your staff is fluent in FORTRAN, COBOL, or C, for example, they will require training. An object-oriented approach will be critical to any large integration project in order to keep the project flexible and manageable. 

One way to lessen the impact of in-house development is to consider a technology transfer. Partnering with an outside software vendor to develop the needed software, then releasing the software to them to productize, gives you free lifetime maintenance in return. 

This lessens the development burden for them, but lowers your ongoing maintenance costs for the system. If this is not a feasible solution, try thinking broader in your software design, and look for other departments who may need software of a similar function and design the software to be re-usable, lowering the overall burden. 

For example, Delphi Delco Electronics Systems has a custom developed common lot flow-card system being implemented in the IC Semiconductor fabs that can manage, revise, and create the paper travelers for lots. 

The Quality department is looking at the possibility of using the same system to manage, revise, and create their quality documents. 

Another effective means for reducing the burden of software cost is to purchase non-domain specific components; examples include application servers, software libraries, and databases. These technologies are reusable and not tied to a particular domain vendor. 

If you must purchase domain products, look for solutions that use generic components like these so you can get some reuse for future projects.

Open versus proprietary

Solutions for purchase come in two general flavors, proprietary and open. 

Proprietary solutions do not have an open, published Application Programming Interface (API) and require vendor-provided custom solutions for modifications or integration with other solutions. 

The biggest problem with proprietary solutions is vendor lock in. Changing a vendor for any part of your architecture requires changing all of the other parts as well. 

If you have a long-term commitment to a solution and do not foresee much change in your manufacturing processes over the next 10 years, this may be an acceptable risk for you. 

An open solution is one where the vendor provides a standard, published API and can interchange data with or execute functionality in other software packages. This approach gives you the ability to replace a portion of your manufacturing IT infrastructure without replacing many other parts. 

For example, if a new and much improved Advanced Process Control (APC) system becomes available on the market, you could replace you current APC solution without also replacing your CIM or MES solution. 

This is the most flexible approach to software integration but requires some programming "glue" to allow all of the pieces to interoperate. This will require some custom code, either outsourced or developed in-house.

Coping with legacy systems

Legacy systems can be an integrator's worst headache. They are often proprietary, use outdated programming languages, and cannot share data between systems. 

The point will inevitably come to decide if that system should undergo integration or if replacement with an open system the best idea. Both are valid options, but a general rule of thumb is if you expect the legacy system or the hardware it runs on to become unsupported in five years or less, it is a better investment to replace it. 

If the system has a lifetime of more than five years, integration with software glue is a valid choice as well. The key to legacy systems is to develop non-proprietary hooks. 

Such a hook allows you to publish an open API into the system while the hook makes the proprietary calls into the legacy system. These are hooks where you might pay half to integrator to develop and they get the right to sell it to others.

The key to legacy system integration is to develop a complete hook the first time, and not piece by piece. The piece-by-piece method works on a short-term basis but will cost a lot more in the end. 

A best practice when dealing with a legacy system is to keep in mind that it is a legacy system and will go away eventually, so within the architecture, one should try to hide it from the majority of the direct connections.

Architectural design

The architecture of an integration project is an important part of the long-term success of the project. As with technology, many solutions are possible. In general, the architecture will determine several things in the system.

1. Boundary/Interface layers between systems
2. Connections between systems
3. Scalability
4. Flexibility/Coverage

Most modern day architectures are Web based and make few assumptions about the client's environment. Logic is back on the server side and the presentation on the client's side. 

The architecture of a system lays out as layers of the system. The idea is when one connects to another system, one doesn't know if that system will change in the future. Therefore, you create an interpretation layer. This allows a system to change while minimizing the effect on another system. The use of industry standards such as XML has made this process much simpler in the past few years.

Information flow requirements determine the connections in architecture. There are connections to the various systems. The rule of thumb is to be as general as possible. Best practice here is not to hook systems directly together but rather through an integration layer to allow others to connect to the system.

The scalability of the system relates to how you expect the system to grow in the future. If you implement a solution that only has 100 clients, what points of the system must change in order to handle 200 additional clients? In general, you would just like the solution to be adding hardware to handle the additional load with no software changes required.

Architecture has a higher degree of flexibility and coverage if it can deal with other problems. For example, if your application is Web based, where Web pages are used on the shop floor, the maintenance system could also use the Web to publish documents to the shop floor.

When building an information system architecture, another best practice is to start in the middle and work out to the other layers. The middle layer is the point where the most integration will come into play. One must look at the systems and see if there are any special requirements placed on the middle layer, such as performance or fault tolerance.   

ABOUT THE AUTHORS

Nancy Glenn (nancy.d.glenn@delphi.com) is a system architect at the Delco Electronics division of Delphi Automotive Systems. David Braun (dbraun@purdue.edu) works in the supercomputing center at Purdue University.