Technology Trends In AIDC (automatic identification and data collection) Development
The need for open, flexible, multiplatform, AIDC (automatic identification and data collection) development environments is important to satisfy the data collection needs of today's businesses. Choosing a development environment that provides a common platform to support evolving standards and architectures is a critical decision that needs to be considered carefully. The following article outlines how and why these needs have developed and what should be considered when establishing a set of evaluation criteria.
Variable IT Environments
IT environments in business today are as varied as they have ever been. In the 1990s an attempt was made to create monolithic software applications that managed all data processing and business process aspects of an organization. However, that outcome only became a reality for a very small percentage of companies. These unified applications are typically developed through a process of needs analysis, functional specification, choice of development platform, development and deployment, and then into a series of upgrades and enhancements. At some later point (which could be months or years depending on many variables) in this process a new or enhanced development technology evolves, business needs change, new standards are embraced, and suddenly there is justification to start the cycle all over again. The promise of a single business application managing all the requirements of an organization in a cost-effective manner has never been delivered.
So what does this mean? It means that many organizations have been required by the competitive and dynamic nature of their industry and the effect of consolidation and corporate acquisitions to implement multiple business applications that use disparate technologies on multiple platforms with different databases at different locations that need to communicate with each other. And let's not forget about the impact the Internet has had on everybody both in speculation and reality. This environment has challenged, and will continue to challenge the IT departments and executive management of every business. It has created a cottage industry of integrators, consultants, custom programmers, help desks, trainers, and varied application specialists. The IT industry is, however, moving in the right direction with application interface standards, communication standards, and Web services. But it will be many years until most organizations move in that direction and between now and then things will continue to change.
Intensified Data Entry Requirements
An often overlooked challenge of the proliferation of increasingly complex business applications throughout an organization is the impact on data entry requirements. Without the timely and accurate input of data, the value and integrity of any business application decreases dramatically. Business application software can potentially be found anywhere in an organization. These applications include supply chain management, inventory management, quality systems, process control, inventory management, manufacturing, distribution, logistics, warehouse management, accounting, and human resources. But they all share the common need to be fed timely and accurate data to portray to the user, be it management, planners, or workers, an accurate snapshot of that aspect of the organization, as close to real time as possible, so the most appropriate business decision can be made at any given time. The ability to do this is the competitive advantage that supports the justification of buying and implementing these applications in the first place. The depth, breadth, and complexity of these applications vary by industry and customer requirements and relate directly to the intensity of the data entry requirements.
For example, a food processor needs to meet FDA requirements and in the event of a recall must have on record traceable data that allows the recall to be limited to only those lots affected. To do this requires a significant amount of data to be collected during procurement, receipt of ingredients, process manufacturing, and distribution of the end product. And, obviously, the data must be accurate. Many organizations have found (and many of them only realizing during implementation) that they need more workers, rather than less, to meet their data entry needs to support the full capabilities of a new business application. Sometimes this data needs to be collected at one point in the process, but is required in multiple business applications that manage different aspects of an organization such as quality, MES (manufacturing execution system), or ERP (enterprise resource planning).
Existing AIDC Environments
Under these circumstances it is easy to see why companies have invested in AIDC technology or have developed project plans to do so. The technology is not new; in fact, it is more than 30 years old. And as with any other technology, data collection hardware has evolved over time as well. Wireless standards have evolved, and hardware manufacturers have recently delivered viable products using open environments such as Pocket PC and Windows CE. Many users of data collection technology are now finding themselves with a mixed bag of equipment and networks at various locations throughout their organization. This is caused by many factors including: autonomous buying decisions, frequent smaller buys of different or newer technology, and acquisitions or mergers of companies with dissimilar technology. Finding AIDC solutions that accommodate mixed devices, platforms, networks, and applications may be an important consideration.
Many organizations want to migrate their hardware to these new open environments but are unable to cost justify a mass migration. Many of the data collection solutions deployed today are terminal emulation (TE) architectures or, if they are client/server, were developed for proprietary character-based terminals. This architecture allows an organization to quickly extend the business application to a mobile environment to automate the data input requirements into the application. One of the issues with the TE architecture is that it requires modification to the core business application to accommodate unique business processes, customer requirements, and exception processing. This can be costly to program and implement, and for many companies, even costlier to maintain through the life cycle of the business application as the companies upgrade to new versions and releases of the product. And since it really wouldn't make sense to run a character session on a graphical display unit, architectural decisions must be strongly considered as part of the migration to newer technology.
Once it has been determined within the organization that an AIDC project will be initiated or that older technology will be displaced with open platforms, a set of evaluation criteria must be established. While it is important for these criteria to get specific in some cases, there are general concepts and requirements that will need to be a part of any forward thinking evaluation.
Ideally, an AIDC development environment will allow an organization the flexibility to support existing technologies such as TE and batch while providing a migration path to client/server or Web server architectures. The new environment should allow a mix of these architectures within a local area network (LAN), wide area network (WAN), or virtual private network (VPN) structure. This flexibility provides an organization the option of migrating a portion of a location, an entire location, or several locations without requiring all locations to migrate to new hardware, yet giving them the capability to take advantage of the new AIDC development environment. That same flexibility provides consistency across locations for supporting a single AIDC development platform, yet allows the financial impact of hardware upgrades to be spread over a desired time frame while wringing out additional returns on the existing hardware investments. The ability to support hardware from multiple vendors may be important as well. While the newer open environments today provide common device operating system platforms across vendors, prior technologies typically utilized proprietary operating systems or, even in the case of DOS, different TCP/IP (an open computer communications language) stacks, causing significant differences.
The evaluation criteria should be based upon long-term business application strategies as well. For example, if the goal of an organization is to reengineer existing applications or purchase new applications that take advantage of evolving application integration techniques and standards (i.e. Web Services, EAI, RosettaNet), then the AIDC environment should be built upon technologies and standards such as XML (extensible markup language), COM/DCOM, .NET, and object technology. By using these industry-accepted technologies not only will the development environment be flexible enough to integrate to today's applications, but it will inherently embrace the evolving standards.
The development environment should not be limited to a set of tools, but should provide a framework to build a turnkey solution. It should include the TCP/IP communications necessary to route transactional messages between devices and the server. The communications should support client/server processing, Web server environments with support browsers on the end devices, terminal emulation sessions, and batch processing for off-site data collection. By supporting these different methods and architectures, the product can support a mix of older and newer business applications typically found in mid- to large-size organizations. Ideally the environment will also include an integration framework that provides scalability to support as many end devices across the network as necessary, without requiring a server at each location while still providing user acceptable response times at the device level. The integration architecture should be capable of targeting business application hardware platforms like UNIX/Linux, AS/400, and Windows, as well as the various databases the applications may run on.
A data collection system of any significance will require administration. The ability to record and review system-wide transaction history, edit transactions, provide device level security, and offer device administration should be inherent to the development environment, not custom-programmed for a solution. The key to any data collection system is the accuracy and use of bar code labels throughout the enterprise. A robust development environment will provide hooks to label design software as well as the ability to administer label design, label processing, and label integration to the business application.
Another key component of a well-rounded development environment is the client design capabilities. This should be a graphical Integrated Development Environment (IDE). Ideally it will be based upon existing industry-accepted development tools such as Visual Basic or Visual Studio. This provides users with a familiar environment that has been tailored for development of AIDC clients and their typically limited screen sizes. The client designer should support devices across hardware manufacturers and multiple operating systems such Windows CE/2000, Pocket PC, DOS, and various proprietary hardware. Ideally a single client program can be compiled to run on multiple device types and within multiple architectures such as client/server and Web server without the need to rewrite the program.
While there are many software developers out there that provide data collection development tools and environments, look for those whose products have been built to embrace newer, open technologies and standards, not just accommodate them. If your organization has taken time to develop an IT strategy that tries to take advantage of new standards, yet also realizes that supporting and migrating legacy applications and systems is inevitable, try to find a vendor who shares your desire to move forward, yet accepts the reality of your business.