IT Issues for Asset Management

Upgradability, integratability, scalability, and mobility

It is 1999. The maintenance function has come of age. Its performance can be planned, measured, tracked, and im-proved. The data it generates can be captured, analyzed, disseminated, and integrated. What's next? Will it be driven by corporate need or by information technology (IT) capabilities?

Where we are now and where we are headed are both defined by desired abilities: upgradability, integratability, scalability, and (stretching the metaphor a bit) mobility. Interestingly, it is easier and less confusing to describe the future than it is the present, which only points out the necessity of clarifying the technological state of the industry before leaping to what is on the horizon.

Let's start with the more easily solved problems. Forward-looking users of computerized maintenance management systems (CMMS) and enterprise asset management (EAM) systems want scalability, a system that can grow with them and accommodate hundreds of power users and thousands more non-maintenance, casual, or self-service users interfacing with the system. But this is only one side of the coin. The world of mergers and acquisitions is also a world of divestitures and spin-offs. While there has been an understandable focus on being able to move from a departmental to an enterprise system in order to get full value from it, users should keep in mind that it is also quite possible that a division of a well-integrated company could just as suddenly find itself an independent operation or the adopted child of a very different parent organization.

For these reasons, I believe scalability needs to imply movement toward both larger and smaller organizations. Clearly, there are products available now for any size organization, but the ideal, from both a cost and a flexibility perspective, is a system that can scale in both directions without changing code. More EAM/CMMS suppliers will need to develop this capability in response to what I predict will become a growing market need.

Besides providing the flexibility to operate as a stand-alone or highly integrated operation, single-platform systems offer another benefit that is just being recognized, particularly by smaller companies. That is the availability, at no extra cost, of special, sophisticated functionality originally developed for other companies, often at great expense. Using departmental asset maintenance software that springs from a single code base as an enterprise product opens up possibilities for expansion otherwise unavailable to departmental users. And having the latest functionality, like having the newest technology, is often an important competitive advantage.

The quest for mobility
Another frequently mentioned item on many maintenance wish lists is mobility, but the lack of clarity about just what mobility means contributes to the confusion that surrounds the capabilities available in today's market. Often mobile computing implies wireless technology, although this is not always the appropriate solution. The technology itself is less important than the benefits it bestows, namely untethered real-time data transmission.

Fully wireless, fully mobile (FWFM) solutions for field-dispatched workers, e.g., cellular digital packet data (CDPD), have become quite attractive recently with the introduction of fixed-price, virtually unlimited-usage communications contracts from network vendors and handheld device batteries that last an entire 8-hour shift. With only one exception, FWFM solutions are still on the drawing board in asset management because of the rigorous demands of lightweight application development.

Semi-wireless, real-time solutions such as radio-frequency and infrared LAN connections may be affordable in limited-duty applications such as storeroom management and central-plant equipment logging, though wiring a large, spread-out LAN with wireless nodes every 500 to 1000 ft can be too costly for a single application like maintenance. Operating at higher communication speeds though, such applications are correspondingly less demanding to develop and a number of asset maintenance software users are implementing such systems.

What is more widely and affordably available are store-and-forward solutions that capture data and transmit it in batch format at a later time. These are the heaviest of the mobile solutions because entire tables of reference data, e.g., spare-part availability and equipment failure history, must be carried by the mobile unit for reference and validation purposes, something of no concern to a system with real-time access. Such solutions are quite common today, but rarely use wireless connections because of the amount of data synchronization involved in their operation.

Mobility is understandably associated with the Internet. Most solutions utilize the Internet in some way, although the plain old telephone system is still heavily used. Even though Web-enabled sounds like a leading-edge buzzword, fast and cheap Internet access by EAM systems is today's reality. The major competitors are already Web-enabled. Solutions will be refined, products will become more widely available, and costs will come down, but mobility and remote access are here now.

Integration, upgrading, open systems
Integration and upgrading have been the rocks on which all enterprise business applications, including EAM, have foundered for years. Fortunately, the solution to both lies in standards-based, distributed component architecture. Note that I did not say simply component architecture. The difference is comparable to Mark Twain's comment: The difference between the right word and the almost right word is the difference between lightning and the lightning bug. It is important to be clear on this point, as all vendors may say they have components, each meaning something different by it. (In fact, the word component has been used in programming circles for years.) But it is in an architecture reliant on standards-based, distributed-component technology where the real promise, and real dollar benefits to customers, lie.

The first response to the problem of integration came with the development in the 1980s of applications from different vendors that could be made to work together. The process was difficult, time-consuming, and often hideously expensive, but it could be done. And it was such a significant development that it was given the moniker open systems architecture. However, open is a relative word; one can walk through an open door but not an open window.

Open systems were like windows; they allowed systems to shake hands, but they did not really allow easy entrance, and so integration has continued to hinder a corporation's ability to choose the specific applications it really needs. The decision often has come down to opting for the best functionality in the most critical systems, compromising in other areas. For many organizations, this has meant choosing a tier-one financial or back office system bundled with other functional modules that are second tier at best. For others it has meant enduring the time, expense, and irritation of integrating different applications.

Although the concept of open systems made integration possible, it did nothing for the problem of upgrading. Generally, there has been no easy way to add functional enhancements without waiting for an entire new release of the product, a time frame that can span several years. And new releases have always been a big bang proposition; there has been no way to add only selected functional enhancements. The problem has been further compounded by the fact that many prior customizations (especially database reconfiguration) must be reprogrammed for the new release. Again, it is industry leaders who have made the greatest effort to minimize both the difficulty and the expense of customization.

DCA and barrier-free systems
Standards-based, distributed-component architecture (DCA) can finally eliminate the windowsills and even most of the doorsills of integration. And it can facilitate the easy adoption of enhancements as they become available. In short, DCA ushers in a new era of barrier-free systems. But the components must be standards-based. They must share a common language that enables them to talk to each other.

As the confusion between components, distributed components, and standards-based components suggests, the development of DCA has been an evolutionary process. There are other terms that further confound the issue. For instance, do loosely coupled enterprise application suites differ from DCA? If the business logic uses standards-based (i.e., nonproprietary) messaging to communicate among modules, then no. But DCA does differ dramatically from tightly coupled business application suites which use proprietary (i.e., single-vendor) messaging. While such applications are designed to work easily with modules by the same vendor or through a vendor-supplied, proprietary interface, they are monolithic and somewhat inflexible when it comes to interfacing with the applications of other vendors. And when it comes to upgrading, the effort is a carefully orchestrated IT operation and is often accomplished only at enormous cost.

Bringing down TCO
One of the key measurements spoken of today in IT departments is total cost of ownership (TCO). Although the phrase is relatively new as a software term, the issues it raises are familiar ones: integrating and upgrading, and the cost of doing both. The use of standards-based, distributed-component technology will enable customers to upgrade on the fly, immediately as new functionality becomes available. Cost savings or efficiency improvements associated with that functionality need not be delayed months or years until a new release is issued by the vendor and scheduled by IT. There are also cost savings associated with being able to add only desired enhancements and in the ease of upgrading. The term associated with this capability is slipstreamed upgrades.

How important are slipstreamed upgrades? In today's era of heightened competition, can you afford to have your systems compromised or down for a massive upgrade? Can you afford to delay an upgrade and let your competitors bypass you in the critical area of information technology? Certainly Wal-Mart's erstwhile competitors paid the ultimate price for not having the real-time inventory and stocking systems in which Wal-Mart wisely, if at high initial cost, invested.

Standards-based DCA also means that the time, expense, problems, and frustration associated with integration eventually will become things of the past. All back-end integration today is either database dependent or proprietary; the integration software that works with Microsoft SQL Server must be completely rewritten for an Oracle database, and integration using messaging middleware relies on proprietary formats. With standards-based distributed components, integration will no longer be constrained in this regard, eliminating not only the financial cost but the competitive cost of non-optimal systems and the risk associated with having critical operations interrupted. Ask anyone who's been through it what the disruption caused by an enterprise systems integration project is like, especially one that fails to achieve its target return on investment.

What's taking so long?
In sum, standards-based DCA virtually eliminates the most costly and troublesome issues associated with enterprise business application software, including EAM systems. This provides users competitive advantage and better protection against business interruption. It is a heady promise, but it has just begun to be realized. No vendor offers a complete, distributed-component-based product & yet. But several tier-one enterprise software vendors are committed to DCA technology; these are the vendors that already offer one or more standards-based distributed components and have publicly announced their intention to convert completely to standards-based DCA in the future. If DCA is the answer to so many prayers, why hasn't everyone jumped on the bandwagon? The answer is not hard to find. As with any revolutionary technology that threatens to supplant a well-established one in which thousands have made huge investments, and with so-called network technologies in particular, it will take time for DCA and its benefits to acquire critical mass. Owning one of the first fax machines brought few benefits because there were few people to whom you could send your fax messages.

In the case of DCA, two things have stood in the way of quick acceptance: the lack of agreement on standards and the lack of available commercial development tools. Only in the past year have standards such as DCOM, CORBA, JDBC, EJB, and XML become mainstream business application development platforms and tools such as Visual J++, BEA Web Logic, and Visual Age become generally available. The windows of open systems are giving way to the doorways of barrier-free systems, but the true barrier-free era will begin when everyone, not just one vendor, gets rid of the windowsills.

Defining the leaders
Having conquered client/server and open systems architecture, enterprise integration, and functionality issues, vendors who would be leaders in asset maintenance now should be committing to standards-based DCA. Change may be the order of the day in many regards, but some things will remain constant. From the time only two decades ago when maintenance was just beginning to define its value to the corporation, customers have continued to seek vendors with certain gold-standard qualities. They want a vendor that will meet their needs today and one that has the financial strength and the vision to invest in the future. Look for companies that have those very qualities.

Certain companies take the lead in exploring lightweight application technologies such as DCA, in developing consistently robust functionality, and in making their product as flexible and as widely applicable as possible. While niche players focus well on meeting the current functional needs of their particular customer base, leaders are committed to the customer's long-term benefit, whether measured in dollars or performance. Think of an everyday example. All cars run well on their first day out. The best ones still run well 100,000 miles later & but require far less to operate and maintain along the way. MT


Milton Bevington is manager of product marketing for PSDI, 100 Crosby Dr., Bedford, MA 01730; (781) 280-2000; Internet www.maximo.com