If you haven’t yet come across the acronym ZLE, let me introduce you to it. ZLE stands for the Zero Latency Enterprise. It’s something you’ll be hearing more about in the future, but if you want to stay ahead of the game there’s no time like the present to familiarize yourself with the concept.
The purpose of this article is to help CIOs and other senior managers understand the organizational structures, infrastructure, practices, procedures and decisions that need to be made to implement and maintain the Zero Latency Enterprise.
Before proceeding, two questions need to be answered: Why the interest in the ZLE? And what exactly is it?
Not surprisingly, the interest in the ZLE is due to its promise in delivering products and services to customers more effectively. As for what it is, latency refers to the amount of delay between capturing data and making it useful to the organization. Zero latency means that as data is captured, the enterprise can immediately obtain benefit from it. Data is immediately propagated across the enterprise’s computer systems within the same transaction and is present on all relevant systems by the end of the transaction
Rather than a system or an architectural concept (e.g., data warehouse, OLTP, client/server), the conceptual underpinnings of the ZLE revolve around organizational structure. ZLEs 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.
ZLE is also a philosophy. In order to be a ZLE, a company must change its focus from one based on static information to one based on dynamic information. Customers, suppliers, employees and associates of the company will come to expect data to be perpetually current and requirements to be dynamic. The corporation will only then be regarded as responsive.
THE PERCEPTION OF LATENCY
Information latency refers to the amount of time it takes for data to take effect across your corporation’s computing infrastructure. To understand the impact of latency on people’s perceptions, consider the following:
A customer decides to take a trip to a favourite vacation spot. Using the Internet, she quickly finds a travel site on which to book a flight, hotel, car, and insurance. After paying by means of a secure on-line credit-card transaction, she decides to connect to the airline’s Web site to examine her seat location. To her alarm, the reservation is not there – the system hasn’t yet been updated. She now spends the next half hour on the phone, trying to confirm her booking. In this case, latency has resulted in an upset customer.
It should be noted that latency can result from sources internal and external to your company.
We have had the technological capability to put the ZLE in place for almost 15 years, but not the need – customers simply didn’t interact with the data. With the advent of e-business, customers have been given access to data that previously was available only internally. This has dramatically altered their expectations and is making them increasingly intolerant of latency. The customer’s attitude has changed from “be as efficient with my orders as you can” to “I expect orders I’ve placed to show up immediately in all of your company’s systems that I deal with.”
This shift has eliminated the luxury of time. Perhaps for the first time in the history of computing, the public’s expectations of technology have exceeded our ability or willingness to easily fulfil them.
BECOMING A ZLE
A ZLE must be technologically adaptive. There is a significant investment attached to providing customers and other “data consumers” with access to current data. As with more traditional data-warehouse or OLTP implementations, changing data requirements will have a significant impact on the success of the ZLE implementation. Changes in data requirements will be continuous and ongoing. Your employees and partners will also need to be adaptive to changing systems and processes. To be a successful ZLE, people must understand the implications of data flowing immediately through the entire corporation.
The user community is just one group that drives requirement changes to the enterprise as it evolves. Changes to any systems component – built in-house or purchased – have an immediate effect on the ability of the organization to remain zero latent. In order to succeed, a ZLE must be able to adapt quickly to changing requirements during and after implementation.
A ZLE must also have flexible business processes. Zero latency brings many changes to an organization at a business-process level. The necessity of capturing data at a finer granularity as it 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 e-business, is essential if the relevant information is to be current all the time.
THE BIG DECISION
When thinking about becoming a ZLE, the first and most important question you need to ask 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 and 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? Where will you draw the line and say, “We don’t need to be zero latent in this area?”
At the outset, the largest analytical task before you will be to ascertain in detail how information flows through your company. You will need to clearly understand the nature of delays: their acceptability, why they occur, how they are measured, and how they are imposed. For example, will the nightly reconciliation of data in a particular application prevent users from accessing data when they need it?
It is critical that informed choices are made about latency in your organization. Decisions should be based on business requirements and latency metrics.
THE INITIAL IMPLEMENTATION
Initial implementations of ZLE infrastructures are prone to many dangers.
Before starting, senior management must define the scope of the ZLE and have plans covering all acceptable business scenarios that may evolve. An important reason to do scenario planning is to ensure that changes in scope can be accommodated. In large organizations, such scope changes are almost certain to occur. Keep in mind that after starting the project, incorporating even the smallest business function into the ZLE implemenation can be a significant task.
The most common approach to date has been hiring a vendor to supply an OLTP system to support some of the business functions. Often, the functions made zero latent are determined by the vendor’s technology. These solutions are often pre-packaged, pre-configured, and pre-tested. Their biggest advantage, and the reason for their popularity, is that they are typically proven business models that can be implemented quickly and with confidence. 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 undertaken in order to integrate the pre-packaged systems with your existing applications. This is almost a certainty when dealing with legacy systems (see Leaving a Long – But Unwanted – Legacy, Stewart Brown, ITWorld Canada, April/May 2000).
Another common approach revolves around integrating existing systems into a data warehouse. With strong planning and flexibility, this approach is workable, provided 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 a ZLE.
The biggest risk in this approach comes from the inevitable changes that occur while implementing a system of this magnitude. The old paradigm of a one-time sign-off and exact delivery on the specs won’t work for this type of project. Requirements will continue to change as the business changes. Suppliers will change. Interfaces to internal and external systems will change. And these can result in delays. More importantly, if an application changes how data is processed, or a department changes systems, the entire ZLE implementation plan may be compromised.
Arguably, the biggest roadblock to creating a Zero Latency Enterprise is the prevalence of batch-oriented business models. Because of this approach – a carry-over from the early days of data processing – many on-line accounting systems still require periodic reconciliation. Batch models are by definition incompatible with the notion of zero latency. New business models must be developed and technology must be harnessed to reflect the needs and goals of the ZLE.
COPING WITH CHANGING REQUIREMENTS
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 your company who you are servicing. Is your client 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. Be 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 evolve.
3. Identify the scenarios you are prepared to cover as a product or service provider. Because you can’t control all aspects of your data supply and delivery line, you must consider more than one scenario as being likely.
4. Identify the scenarios you are not prepared to support. These will denote the boundaries of the architecture your implementation must cover.
5. Identify all of your data suppliers and consumers, and determine which of them are most likely to undergo change. The release history of a supplier may be a good 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? What are the implications for various scenarios?
7. Examine the proposed architecture for sensitivity to change. If a supplier changes direction, what impact will that have on you? Look for ways to insulate your architecture from supplier 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 derived from reducing latency.
10. Most importantly, accept the fact that the result will probably not be exactly what you originally specified. Remember, everything changes.
ONGOING MAINTENANCE
Having made the transition to a true zero latency enterprise, you’re not out of the woods yet. In fact you still face a huge challenge. Whether or not you used a vendor to get where you are, you’re on the hook for maintaining these systems.
During your implementation, you had the luxury of delaying changes to supporting systems. Now you must come to grips with the challenge. These are the realities:
• Interfaces will change. Vendors will develop and enhance their products and services in order to keep them vital. This will mean changes to the way data is presented or processed, or both.
• Vendors will change. Some will disappear. Some will be surpassed by competitors. Some will not have the capability to help you expand zero latency to other parts of the enterprise. Remember your scenario plan?
• Processes will change. When in the last 20 years have they not? Process change will have a direct impact on your company’s employees and partners. Implications for the ZLE can be great.
• And finally, your business will change. If it doesn’t you’ll be out of a job.
So, how do you cope with these ongoing changes? Maybe by picking up a copy of “Chicken Soup for the CIO’s Soul” or “Don’t Sweat the Small Stuff in IT Management”. OK, so they haven’t been written – yet – but you get the picture.
No matter how hard you try, change will be out of your control. Accept it and move with it as effectively as possible. Here’s a trick that may help.
MANAGING YOUR I.T. INFRASTRUCTURE AS A PRODUCT
Instead of looking at the ZLE as a project to implement, look at it as an ongoing product with an indefinite life span. As with any living product or service, once the customer is engaged, the need to evolve will never end. Therefore, there really isn’t an “end” milestone. You can’t point to a task on your project plan and say, “OK, we’re done. Time to move on to something else.” You continually need to make choices on the scope of your ZLE. Conflicts arising from divergent requirements, resource allocation, and corporate needs must be resolved on an ongoing basis. You may even decide to replace significant parts of the infrastructure, but that still doesn’t end the ZLE – it transforms it.
In effect, the ZLE is a reflection of your evolving business wisdom. And this brings us right back to where we started: more effectively serving your customers – this will be the most important critical success factor in your implementation.
Randall Becker is CEO of Nexbridge Inc., a company specializing in product management consulting and change mentoring to the high-tech community. His previous article “Taking Back What Is Ours” (CIO Canada , December 1999), discussed back-sourcing. His e-mail address is rsbecker@nexbridge.com.