Migrating toward enterprise information systems
Using a maturity model provides advice to assist a business owner moving processes and software from Level 0 (paper-based systems or homegrown systems) of the model to Level 1 (focused data systems). The diagram provided presents the maturity model in its entirety.
Great place to start
The good news is that Level 0 applications make up a large number of applications, and moving to Level 1 is a common activity within the maturity model. The bad news is that the homegrown Level 0 applications are almost always disbanded in the process.
It’s important to understand that this is a natural evolution of maturity. The scope of the maturity model is not typically envisioned when Level 0 applications are built. However, the work performed on these applications isn’t wasted effort. In some cases, it is the only way to understand what is needed (either by the success of the application to fill a specific need or by recognition of a need that went unfilled). This makes Level 0 systems a great place to start when developing requirements for an enterprise-level system.
Quick recap, context
In the first article of this series, Understand the maturity model to better manage, integrate plant floor, enterprise systems, the enterprise information system maturity model was introduced. This model presents a general context for understanding enterprise systems. Most importantly, it provides a set of criteria to evaluate your enterprise system needs and help determine next steps to increase decision efficiency (and the bottom line). In effect: greater decision efficiency = lower costs = higher profits.
Reaching the primary goal of sustainability
The primary reason for making the leap to Level 1 is the overall sustainability of the system. Sustainability is primarily affected by the choice of the application platform for the system. The following offers advice on several primary aspects of Level 1 sustainability.
Licensing: Licensing can be a road block to maintaining and operating an enterprise system. When selecting a platform to build a Level 1 system, it is important to evaluate licensing models to identify any restrictions or limitations. Some software uses more complex models that may restrict access to configuration and management tools. These restrictions often provide a competitive advantage for the integrator or vendor to gain future work updating the system.
Here are some key items to look for:
- The availability of configuration and management software should not be limited to the system integrator performing the implementation. The owner and other system integrators should be able to access and configure the software.
- Be wary of any licenses that restrict connectivity to a "vendor locked" version of configuration and management software.
- System licenses should not restrict communication to other third-party devices or applications that are not of an approved brand. This is not a technical limitation, but rather a tactic used by vendors to prevent future integration of competitor’s products into the existing system.
- Some applications require a physical device (such as a USB key) be present to properly license a system for operation. Hardware keys are susceptible to being stolen and issues can arise when interfacing the licensing hardware in a virtual environment. Systems should provide software key licensing.
Openness: "Open" is a common buzzword that can have several meanings. First, it can refer to the availability of vendor support and configuration. Systems can be deployed so they are only serviceable by a single vendor through controlled proprietary knowledge. These "closed" systems force the owner to rely on a single vendor and limit the owner’s ability to obtain competitively priced services.
The second meaning of openness is the ability to communicate and integrate with third-party systems. Here are some questions to ask when examining system software:
- Does the system rely on proprietary protocols to communicate to devices and other systems?
- Does the system store historical information in a proprietary database? If so, are standard interfaces available, such as Web services or open database connectivity (ODBC), to allow data access from third-party systems?
- Does the system support exporting data into industry standard formats such as comma separated variable (CSV), Microsoft Excel, or extensible markup language (XML) files?
Open communication is crucial when augmenting the system. Systems that don’t provide standard interfaces increase the complexity of future integration and provide lower overall value.
Extensibility: The full usefulness of a system is rarely realized during the initial installation and use. Systems are generally selected and installed to fulfill specific objectives. It’s common for future goals and requirements to dictate changes to existing systems. The goal is to select applications that not only offer a set of features, but also provide a platform on which the system may be enhanced and extended.
There are several guidelines to use when evaluating the extensibility of a system:
- Does the system provide programming software, a software development kit (SDK), or an application programming interface (API) to support third-party developed modules?
- What is the extent of the features that may be accessed through an available API or SDK? Is read/write access to data possible? Are other system functions available?
- Is the system modular? Is it possible to buy what you need now and add functionality later?
- If third-party modules or extensions may be developed for the system, what are the development requirements?
- How accessible are the tools and training, if needed? Does the system vendor provide training or certification programs?
As a general rule, systems that support extensible frameworks are more flexible and provide better value over the life of the system.
Scalability: In contrast to extensibility (which refers to new system features), scalability signifies the ability to add capacity to the system using the existing features. For example, a manufacturing control system is scaled by adding a new controller. It is extended by a adding a new processing feature that was not previously available.
It’s important to understand short- and long-term goals when selecting a platform. Typically, a system supports the necessary capacity at the time of the deployment. However, the ability to support future capacity needs to be understood. Be sure to select systems that may be rapidly and cost effectively expanded to meet the growing needs of the users without adversely affecting the performance of the system. It is also important that a system provides features to easily manage and configure system components.
Support: The long-term success of a system depends greatly on the ongoing support structure for hosting, maintenance, and troubleshooting. The support responsibilities of the owner and system provider need to be clearly defined. The following questions help determine how responsibilities should be divided:
- Can routine maintenance activities be performed by the owner/third party?
- Can disaster recovery procedures be performed by the owner/third party?
- Can the IT resources at the installation site support the system hardware, operating system, and application software?
- Can local resources support the hosting, backup, and redundancy requirements or should some or all of the support responsibilities be outsourced to a third party?
Once an owner has successfully implemented Level 1 systems, the next step is to gain a competitive advantage of centralized data with Level 2 maturity. Level 2 maturity enables businesses to correlate information across their systems and make key insights into their operations. The next article in this series will provide advice when moving beyond Level 1.
– Corey Stefanczak is senior system architect, Leidos. Edited by Brittany Merchut and Mark T. Hoske, Control Engineering, email@example.com.
- Understanding the maturity model can help organizations move from Level 0, paper-based systems and homegrown systems, to Level 1, focused data systems.
- Don’t toss level 0 intelligence on the way.
- Level 1 offers sustainability that is largely influenced by the choice of the application platform.
What goals can you attain more easily by moving to higher levels in the system maturity model?
Learn more about Leidos in the Global System Integrator Database.
The following articles below have more information on maturity systems, and software development:
This article online contains links to each part of this full five-part series on meeting the challenges of enterprise information systems looking at the maturity model introduction, taking the first step, gaining a competitive advantage, optimizing resources, and a highly mature enterprise.
Part 1: Understand the maturity model to better manage, integrate plant floor, enterprise systems Control Engineering (CE), August issue, Inside Machines section, p. M1
Part 2: Migrating toward enterprise information systems from Applied Automation (supplement to CE and Plant Engineering), October issue, p. A13 [This article]
Part 3: Gain a competitive advantage, meet the challenges of enterprise information systems CE Weekly News enewsletter, Nov. 25
Part 4: Optimizing the climb up the enterprise information systems maturity model CE November issue, Technology Update, p. 34
Part 5: Highly mature enterprise: Meet the challenges of enterprise information systems CE December issue, Inside Machine section, p. IM4
See article on software development capability, with more about the value of advancing in the maturity model.
The maturity model concept also has been applied to green/sustainability/energy-efficiency concepts and to cyber security.