Engineering and IT Insight: Keep your systems from becoming MULES
Manufacturing IT systems can easily become mature, undocumented legacy execution systems (MULES) as requirements change, knowledge is lost, and supporting systems go obsolete. Keep your software relevant by following these tips.
No one wants their manufacturing IT systems to become MULES: Mature undocumented legacy execution systems. Engineers design systems to meet the known requirements and provide the end users with a system they can easily understand and use. However, over time, requirements will change, knowledge will be lost, and supporting systems such as operating systems and development tools will become obsolete. When this happens, your system will join the herd of MULES. While eventually every system requires migration or decommissioning, there are steps you can take during your development project to slow down the process and provide a better long-term solution to your users.
One of the definitions of mature is inflexible and unyielding. Over time, as small changes are made to software systems, they become more inflexible and unable to be extended. Small changes and patches over time can often limit future changes as the original architecture no longer meets new needs. The first step to slow the MULE system conversion is through a flexible and expandable architecture.
System design tips: While it is impossible to foresee all possible extensions that will be required for your project over the next 10 to 20 years, you can anticipate some extensions and design for them. For example, if your project reads a set of tags to collect information, you may want to read the tag definitions from a file at start-up instead of being hard coded. You may want to make all user displayed text and error messages accessible from a database instead of hard-coded strings, allowing for use with other languages or improved messages in the future. If your system accesses an Ethernet network, make sure that it uses well-established ports and well-defined messages to allow future redirection or use of the messages. Designing a flexible architecture is difficult. It requires the architect to look beyond the current known requirements and anticipate how users would want to extend or use the system. The time spent defining a suitable flexible architecture is often gained later in the project during debugging and commissioning, so a flexible architecture will help your current project in addition to slowing the transformation from a project to a MULE system.
MULES are undocumented. This may be because either there was no documentation or the documentation was lost over time. You can fix both of these problems.
The first fix is to document your system using the assumption that the person reading the documentation knows nothing about the original requirements, nothing about the initial execution environment, and nothing about the underlying architecture and the constraints placed by the programming language or execution system. In designing to not become an obsolete system, you must remember that people reading the documentation may not be currently working for the company, and, in some cases, may not yet be out of grade school. Your future readers will not understand elements of the design, requirements, or environment that are second nature to you, so you must document information that you think is obvious.
Finding the information: Once you have documented the obvious and unobvious, it is important to place the information where it can always be retrieved. When you lose the documentation of a MULE system, it becomes a liability and not an asset. If the system fails, nobody wants to touch it or fix it, and most teams will work around the problem until the MULE system can be replaced. Keep the documentation with the code, in the same directories, to increase the chance that it will survive over 5 to 20 years. Keep the documentation in a format that can be read in the future, providing it in the native, RTF (rich text format) and PDF formats.
Support: Keeping the documentation is important, but slowing the legacy part of being a MULE system also involves keeping support information available. Systems are usually called “legacy” when the underlying operating system environments, supporting libraries, or program compilation environments are no longer supported. Because of the speed of change in IT, legacy systems may be less than 5 years old. It’s important to provide future engineers with the proper tools to support your system, and fortunately virtual systems now give you that capability. When you create a project, create the development and support environment in a virtual system.
Snapshot with editors and tools: When you archive the project, include a snapshot of the development and support environment. This environment should include the IDE (integrated development environment) or the compilers and editors you used to create the final project code. Also include the tools used to generate the documentation. If you have ever supported a system where the documentation was in Corel WordPerfect or Apple MacWrite, then you will appreciate having the original tools available when you have to make changes.
A virtual environment also has the advantage of providing the operating system. Microsoft Windows NT and Microsoft Windows XP are no longer commercially available, but many systems that require them are still running. Providing a development environment in a virtual system, including all environment help files, will be an invaluable resource for future support engineers.
Every system eventually will become a MULE system because, eventually, it can’t be changed, can’t be supported, and can’t be understood. You can delay this process and increase the value of your software with a flexible architecture, well-documented systems for novice users and support engineers, and a development environment that will be available 5, 10, or 20 years in the future. This extra work now will pay great dividends to your future replacement.
- Dennis Brandl is president of BR+L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at dbrandl(at)brlconsulting.com. Edited by Mark T. Hoske, Control Engineering, www.controleng.com.
Engineering and IT Insight: What’s the best manufacturing operations management systems design?—Should your manufacturing operations management (MOM) systems be centralized or distributed? These key considerations can help you decide. MOM includes MES (manufacturing execution systems), LIMS (laboratory information management systems), WMS (warehouse management systems), tank farm management systems, and AMS (asset management systems).
More on MOM: Cut costs with manufacturing IT standards, best practices—If you had the opportunity to reduce automation project costs or times by over 30%, reduce costs for plant-to-enterprise integration by over 70%, or reduce maintenance support costs by over 10%, you would think that most manufacturing engineers or executives would stop ignoring this opportunity.
Engineering and IT Insight: How to convert a project into a product—Extra effort is required to convert a manufacturing IT project into a successful product. Advice follows on how to do it. (If you’re considering buying software that sounds or test drives more like a project, you may want to look at other software.)
Case Study Database
Get more exposure for your case study by uploading it to the Consulting-Specifying Engineer case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.