Related Corporate Summary: Managing ZLE implementations assuming change will happen is absolutely critical. Nexbridge has proven methodologies for ensuring that your implementation is effective. Leave us a comment below and let us show you how to make zero latency possible and effective rather than being potential disastrous for your reputation and a waste of resources.

The raw form of this article is Copyright © 2000 Nexbridge Inc. All rights reserved.
This article has been published in different form in the September 2000 issue of CIO Magazine (Canada). The final published article, Are You Ready For The Zero-Hour, can be obtained found at www.itworldcanada.com
The article is copyright Laurentian Technomedia Inc. (LTI), © 2000. All rights are reserved.
No material from this article may be reproduced electronically or in print without written permission from LTI.
For permission for commercial or educational use of the content of this or any LTI publication, write to:

Editor-in-chief,
LTI,
55 Town Centre Court, Suite #302, Scarborough, Ontario, M1P 4X4.

The purpose of this article is to help senior management understand the organizational structures, infrastructure, practices and procedures, and initial and ongoing decisions that need to be made to implement and maintain the Zero Latency Enterprise (ZLE). Obviously, the first question to ask is why the interest in ZLE? The answer, not surprisingly, is to more effectively deliver products and services to customers.

What Is a Zero Latency Enterprise (ZLE)?

Latency refers to the amount of delay between data capture and usefulness to an organization. Zero latency means that as data is captured, the enterprise can immediately obtain benefit from that data.

ZLE is an organizational structure, rather than a system or an architectural concept (e.g., Data warehouse, OLTP, client/server). ZLE companies use their system resources and business processes to keep their enterprise data current and continuously available to all user and consumer applications. Users expect that all data presented to them reflect what is current in all systems across the corporation.

It is also a philosophy. In order to be a ZLE, a company must change their focus from static to dynamic information. Consumers, suppliers, users, employees, and associates of the company will come to expect data to be perpetually current, in addition to requirements being dynamic, and corporations being responsive.

A ZLE Primer

Information Latency refers to the amount of time it takes for data to take effect across your corporation’s computing infrastructure. There are three broad measures of latency to consider:

• Zero latency means that as data appears, it is immediately propagated across your computer systems within the same transaction. In a zero latent enterprise, the data is present on all relevant systems by the end of the transaction.
• Positive latency means that it takes time for data to show up in different systems. This is the result of data collected by an application, being extracted and used to update other systems in periodic batches. The time between the initial data capture and the availability on those other systems is a measure of latency.
• Negative latency means that data is in your system before it actually has effect to the corporation. In a limited scope ZLE organization, data is captured but requires a subsequent process to be executed to take effect. The measure of negative latency is the time until the data participates in the ZLE. This type of data is crucial to consider if your front-end systems do not participate in your ZLE.

The Perception of Global Latency

To understand the impact of latency on people’s perceptions, consider these two examples:

Online banking has given us almost up to the minute information on the status of our accounts. Many financial institutions permit you to transfer money between accounts instantaneously. There is no latency in most of these types of transactions. However, if you wish to pay a bill, or transfer money between Canadian and US currency accounts, latency is imposed on the customer by business process and regulatory requirements.

A customer decides to take a trip to a favorite vacation spot. Launching an Internet browser, they quickly find a travel site on which to book a flight, hotel, car, and insurance. After paying with a secure online credit card transaction, they decide to examine the seat selection, possibly to make changes. Delighted at the marvels of technology, they connect to the airline’s web site and look for their reservation. It’s not there. Frantically, they get on the phone and try to reach customer service. As you might expect, that the reservation system hasn’t yet been updated on the details of the reservation. This example illustrates that your latency issues can result from both internal and external sources.

Why Companies Have to Adopt a Zero Latency Model

Users expectations evolve based on perception, not necessarily on available technology. We have had the technological capability to put ZLE in place for almost 15 years, but not the need. Users simply didn’t interact with the data. Consequently, no one has put business processes in place to support what was a low priority requirement. With the advent of eBusiness, users (in the form of customers) have been given access to data that was previously available to internal systems only. This shift in access to information has motivated a dramatic change in users’ minds from “be as efficient with my orders as you can” to “I expect orders I’ve given you myself to immediately show up in your company”. This shift has eliminated the luxury of time because, if a customer-user places an order, they expect to see the order, in real time, everywhere that they have access, including the customer support system. Users are becoming increasingly intolerant of businesses where they see transactions being delayed. Now, for arguably the first time in the history of computing, the general public’s expectation of technology has exceeded our ability or willingness to easily deliver.

What Does a Zero Latency Enterprise Need to Do?

A ZLE company must be technologically adaptive. ZLE requires an investment in converting many independent data sources and data consumers to make effective use of data – effective now being defined as on time and current. As with more traditional data-warehouse or OLTP implementations, changing data requirements directly influences the critical success factors (CSF) of a ZLE implementation. These changes are continuous and ongoing. Participants in the ZLE, your employees and partners, also need to be adaptive to the changing systems and processes. Part of being a successful ZLE is having people understand the implications of data flowing immediately through the entire corporation.

The user community is just one source that drives requirement changes to the overall enterprise throughout the ongoing evolution of the company. In the ZLE world, changes to any component – in-house built or purchased – have an immediate effect on the ability of the organization to remain zero latent. In order to succeed, a ZLE company must be able to adapt quickly to changing requirements during and after implementation.

A ZLE company must also have flexible business processes. ZLE brings many changes to an organization at a business process level. The necessity of capturing data at a finer granularity, as the data is generated, can easily result in major corporate shifts. No longer, for example, can data be updated in batches. Closer control of inventory, delivery schedules, and order information, especially in eBusiness, is essential if the ZLE information is to be current, all the time.

The Big Decision

The first and most important question you need to ask, when thinking about ZLE is:

“Which parts of my company must be zero latent?”

Do you need to have an up-to-the-second picture of your cash position? How about inventory? Orders? Where are delays in data processing acceptable and where are they not? What about payroll and time accounting? Do you need to know who is working where and when and how it relates to your balance sheet? Where will you draw the line and say, “We don’t need to be zero latent in this area?”

The largest analysis task required going into ZLE is an in-depth look at how information flows through your company. You need to clearly understand where delays are acceptable and where they are not, why they occur, how they are measured, and how they are imposed. If you have to wait for a nightly reconciliation in some data in some application, will that mean that your users are not going to have access to data they expect to see?

To be successful in implementing ZLE, it is critical that informed and measured choices are made about latency in your organization. Decisions should be made based on business requirements and latency metrics.

The Initial Implementation

Initial implementations of ZLE infrastructures are fraught with dangers.

The importance of deciding which portions of your company will be part of the zero latency effort is crucial. You and other senior managers must define the ZLE scope before starting the implementation and be absolutely certain you have plans covering all acceptable business scenarios. Some of these scenarios may be based purely on different latency requirements. This doesn’t mean you have to actually do the implementation for all scenarios; rather, you have to be able to do the implementation as scenarios unfold. An important reason to do scenario planning is that once the ZLE scope is determined, and implementation started, the scope itself is subject to change. In large organizations, this will be almost guaranteed and should be included in your ongoing scenario planning process. It is likely a non-trivial task to incorporate even the smallest business function into your ZLE after starting.

The most common approach, to date, has been to contract a vendor or solution provider to supply an Online Transaction Processing (OLTP) system to support some aspects of the business functions. Often, the portion of your company that is made zero latent is driven by the technology that is made available to you as part of the solution. These solutions are often pre-packaged, pre-configured, and pre-tested. The advantages of using this approach, and why it is so common are: it is a proven business model for implementation; and you can quickly implement with confidence that the system you are getting will work, functionally. The biggest disadvantage is that these solutions are often not sufficient to support all of your MIS requirements. Other projects – customization and redevelopment – often have to be performed in order to integrate the pre-packaged systems in with your existing MIS applications. This is almost a certainty when dealing with legacy systems (Leaving a Long – But Unwanted – Legacy, Stewart Brown, ITWorld Canada, April/May 2000).

Another common approach is to try to integrate existing systems into a data warehouse. With strong planning and flexibility, this approach is workable, provided that the existing systems can perform at a sufficient level to handle on-line updates of the data warehouse. To date, very few businesses have the computing capability to handle the thousands of transaction updates per second to a data warehouse needed to support ZLE.

The biggest risk comes from the inevitable changes that occur in the time it takes to implement a system of this magnitude. The old paradigm of a one-time sign-off on, and delivery exactly to, the specifications for a development project is inappropriate for ZLE. Requirements, including those for ZLE itself, will continue to change as the business changes. Your suppliers change. Interfaces to internal and external systems change. These can result in delays. More importantly, if an application changes how data is processed, or another department changes systems, you may find your entire ZLE implementation plan compromised.

Arguably, the biggest roadblock to ZLE is the prevalence of and dependence on batch oriented business models. In many enterprises, the batch business model has been adopted as a result of the technology available in the early days of data processing. A carry over of this is that many on-line accounting systems still require periodic reconciliation. This is incompatible with the needs of a ZLE. New business models must be developed that reflect the desires of the zero latent enterprise. Technology must be harnessed to reflect these corporate goals.

How Do You Cope with Ongoing Requirements Change?

The first step in “getting there” is to accept the inevitability that your system will change, before, during, and after implementation. Attempting to control change, by preventing it, is not effective, and often not possible. What follows is a list of issues and questions to be examined during your initial implementation and revisited regularly:

1. Clearly identify to yourself and to your company who it is that you are servicing. Is your client actually an internal marketing group? Is it an operations group that supports a service provided by your company? Is it an outside consumer of goods and services?
2. Identify the value your product or service has to your client. Make sure to include the implicit value as well as the visible, up front value. Then, identify the value it has to you. Most of the time, if you get the same answer, you’re fooling yourself. The differences in the perception of value can be a key gap in the ability to continually evolve.
3. Identify the scenarios you are prepared to cover, as a product or service provider. Because you can’t really control all aspects of your data supply and delivery line, you have to consider more than one scenario as being likely.
4. Clearly identify the scenarios you are not prepared to support. The scenarios you are not prepared to support guide the boundaries of the architecture your ZLE implementation must cover.
5. Identify all of your data suppliers and consumers. In doing so, identify which of them are most likely to undergo change. While this is a difficult task, you can look, for example, at the past release history of a supplier as a starting point. Can you arrange service level agreements with your suppliers to ensure interface compatibility support?
6. Determine whether your choice in hardware and software architecture will be flexible enough to assure long-term compatibility. Will you find yourself locked into one specific architecture? Is this acceptable? Consider how long and in what scenarios you are and are not prepared to accept this.
7. Examine the proposed architecture for sensitivity to change. If a supplier changes direction, what impact will that have on you? Look for good abstractions in your architecture to insulate you from changes. Avoid dependence on specific data formats and connectivity.
8. Push the architecture people on change. What happens if you add new data feeds? What happens if you have to change the normalization of your support data warehouses? Run through different business scenarios with your architects and see how those differences will be reflected in the system design.
9. Develop metrics and algorithms to assess business benefits to reducing latency.
10. Most importantly, accept the fact that the final result probably will not be exactly what you originally specified. Remember that everything changes.

Ongoing Maintenance

Assuming you’ve had a successful implementation and are now a true zero latency enterprise, you’re now going to face a huge challenge. If you used a solution provider or vendor to implement your ZLE, they’re likely to have gone onto other implementations. That leaves the ball in your court to maintain these systems. If you did it yourself, you’re in the same boat: Coping with Change.

During your ZLE implementation, you had the luxury of delaying any changes to supporting systems untilafter implementation. Now that it’s after implementation, you have to come to grips with it. These are the realities:

Interfaces will change. Vendors develop and enhance their products and services to meet not only your needs, but also the needs of their other customers. The vitality of their products depends on their ability to change as business needs change. You receive benefit from their vitality – either that, or you’ll soon be picking a new vendor. Even your own internal systems will be enhanced as your business evolves. These changes will mean changes to either the way data is presented or processed or both.

Vendors will change. At some point, you might decide that you will be better served by a different vendor. You may also decide to integrate a new part of your business into the ZLE. Remember your scenario plan?

Processes will change. This has a direct impact on all of your employees and partners. To make your business processes sustainable, senior management must commit to defining, communicating, and maintaining a corporate culture that includes understanding the processes. Successful process training efforts are integral to a ZLE and must be as adaptive and ongoing as the technological changes to be effective.

Your business will change. Won’t it? So, how do you cope with these on-going changes?

Managing Your IT Infrastructure as a Product

In reality, you can take heart in knowing that there is very little policy, process, or procedural difference in managing your organization as a ZLE compared with any other structure. The biggest shift you will have to make is that, no matter how hard you try, change will be out of your control. You have to accept it and move with it as effectively as possible. Instead of looking at ZLE as a project to implement, look at it as an ongoing product with an indefinite life span.

The set of decisions you made in your implementation, are the same decisions you must make on an ongoing basis. You continually need to make measured choices on the scope of your ZLE. Conflicts arising from divergent requirements, resource allocations, and corporate needs must be resolved on a continuous and ongoing basis. Because these conflicts impact on the very core of your organization, to be successful, they must be resolved at the highest levels of management.

All these activities are continuous and ongoing. There really isn’t an “end” milestone for ZLE. You can’t actually point to a task on your project plan and say, “Ok, we’re done. Time to move on to something else.” With ZLE, as with any living product or service, once the customer is engaged, the need to evolve will never end. You may even decide to replace significant parts of the infrastructure, but that still doesn’t end the ZLE. It transforms it. In effect, ZLE is a reflection of your evolving business wisdom. This brings us right back to where we started: more effectively serving our customers.

The Customers’ Role in a ZLE

Accepting that the customer is part of the processes supporting ZLE is the most important critical success factor in your implementation. Your customers can include other divisions, end-users, business-to-business partners, suppliers, and clients. Including and engaging these users in the Zero Latency Enterprise is crucial to your bottom line because their expectations are driving changes to business processes in your company. The old adage “The customer is always right” has perhaps less apparent meaning now, since users are interacting with your information systems directly, and can see for themselves that they are right. They also have the means to tell whether or not you are servicing their requests in a timely, accurate, and effective manner. Perhaps we need a new adage: “The customer is always in the loop.” To be customer focused, we need to view our business systems as products where our customers have an integral role in our business processes.