WAN Governance

Once upon a time... (What are the key applications? 2/3)

We saw in part 1 of this study based on a panel of 48 networks representing an aggregated amount of more than 10 000 sites, that in average:

• Enterprises differentiate 69 key applications;
• They group these applications in 15 Classes;
• The number of applications and classes do not depend on the network size.

Let's see now how these enterprises manage their applications according to their criticality to the business. We classified them in four level of criticality: TOP, HIGH, MEDIUM and LOW. We voluntarily selected a relatively small number to get sure that the classification is really meaningful to enterprises: in a 64 value scale, how would you seriously compare level 43 with level 47?

Here are some examples of applications with their usual level of criticality (note that there are significant differences among enterprises, and we do not mean here that application A is always at criticality C):

• TOP criticality: SAP, ORACLE, CITRIX, AS400, Voice…
• HIGH criticality: LDAP, Video conferencing, SIEBEL, Intranet…
• MEDIUM criticality: NOTES, SHAREPOINT, Internet, Emails, File sharing…
• LOW criticality: File transfer, Antivirus, QUAKE, BITTORENT…

When studying how applications and User Classes are related together, it appeared that:

• The number of Classes is remarkably well balanced among criticality, with 3 to 4 User Classes per level;
• Application are also very regularly spread among business criticality, with an average of 15 to 20 applications per level;
• On the other hand, the volume of traffic over networks is not balanced: the higher is the importance of applications to the business, the lower is the % of network usage. TOP critical applications represent only a very small amount (3.3%) of the total of traffic, while LOW critical applications take more than half of this traffic (54%).

3% of business critical traffic requires the same analysis accuracy than 54% of low critical traffic: this means that the need for deep understanding of applications traffic and performance over the WAN is related to the importance of these applications for the enterprise activity, not to the amount of traffic over the network.

On a personal note to my colleague Nigel, who loves to ask CIOs if they know the portion of their network that is used for business applications, I can now provide him with the (average) answer: between 3% (TOP) and 9% (TOP + HIGH) of the traffic, for 15 to 30 critical applications.

In the next part of this study, we will see how applications can be split according to their technical characteristic (real-time, transactional, etc.).

Once upon a time… (what are the key applications ? 1/3)

In a previous post, we proposed a 12-point check-list for a WAN governance project. Let's discuss here the subject that begins our whole story: What are my key applications?

We recently made a survey (*) about implementation of Autonomic Networking and Objective-based management as configured by enterprises that use Ipanema solutions. I would like to share with you some results that I believe meaningful.

The study bears on a panel of 48 large enterprises, in all industry verticals across every continent. Aggregated, it represents more than 10,000 sites, and can be reasonably considered as a fairly representative sample.

 

• The first outcome is about the number applications discovered and/or declared: on average, we found 69 differentiated applications per enterprise. The classification system being practically unlimited, we can consider this figure as the current level of granularity that is required by an enterprise. I must recognize that we expected a smaller figure; it gives a sense of usage diversity in organizations.

 

• The second outcome is about the way applications are gathered by families (we call them "User Class" in the Ipanema jargon (**)). The average number of application groups is of 15 User Classes per enterprise, with a minimum of 7 and a maximum of 33 classes per network. 15 is then the "Magic Number" for WAN governance powered by Autonomic Networking. The graph beside shows the number of enterprises according to the number of User Classes they implement, with the classical 'long tail' in such type of statistics.

 

• The third outcome is that neither the number of applications nor the number of User Classes depends on the network size. This time, the result was expected as the principle of Objective-based management is to drive application performance from the enterprise's application portfolio and not from its network topology.

 

In further posts, we will continue our story and examine how business criticality has been managed as well as the nature of the declared applications.

 

(*) I would like to particularly thank the Ipanema Support and Consulting team that makes this study possible.

(**) A "User Class" gathers all applications with same Business Criticality (4 levels, from TOP down to LOW) and same Type of traffic (3 options among Real-time, Transactional and Background).

Autonom-Air Traffic Control

Want to try a globally optimized traffic control system that is based on Objective-based management? That's easy, just take a plane: Air Traffic Flow Management (ATFM) that drives planes from one airport to another one in association with Air Traffic Control (ATC) provides global optimization.

Air Traffic Flow Management regulates the traffic in order to optimize end-to-end capacity. Its objectives are multiple, all concurring to security, availability, comfort and economic efficiency of air transport:

    - Avoid collisions;
    - Improve flight accuracy;
    - Maximize airspace 'bandwidth' between airports;
    - Accelerate flights handling at origin and destination;
    - Reduce expenses of airlines as well as airport organizations.

Let's simplify the ATFM/ATC structure in (a) Ground control at source airport (b) Air control between airports (c) Ground control at destination airport.

A few decades ago, the state of communication, computing and software technology did not permit a global approach. Each segment of the system behaves independently. A plane leaving, say Amsterdam Schiphol to London Heathrow had a good chance to hold quite a long time above river Thames, circling around till a landing slot will be found by the local Ground control. It used considerable amount of fuel, flight duration was uncertain, airport capacity had to be limited for obvious security reasons (there is no room to hold too many planes at same time, and fuel quantity in a plane is somehow limited...).

Thanks to technology improvements, ATFM/ATC behaves now as a globally optimized system: flights are taken into account as end-to-end processes where what happens at source airports (e.g. departure slots) depends on what happens at destination airports and even at airspace level (routes, weather, etc.). Our Amsterdam flight may be delayed a few minutes before departure because London has to prioritize an arrival from Chicago. We will leave Netherlands only when we get sure to have a free slot when reaching England. Benefits of this global approach are numerous:

    - Better security (reduced collision probability);
    - Improved accuracy, leading to better customers comfort and satisfaction,
    - Optimized airspace usage, allowing sharing a heavily loaded route by more planes;
    - Accelerated take-off and landing frequency (reduced from a few minutes to a few tenth of seconds at peak time)
    - Reduced cost (no extra fuel consumption, improved sharing of expensive infrastructure, etc.).

It is really easy to find similarities between global air traffic optimization by ATFM/ATC and modern Autonomic Networking/Objective-based management of application traffic in enterprise networks. Replace Schiphol and Heathrow by your own datacenter and branch office, airplanes by application flows and IP packets. You will immediately feel the difference between legacy policy-based/locally-managed communication systems and Autonomic Networking/Objective-based solutions.

Used to entrust global ATFM with our own life, don't you think it's time for reaching similar efficiency and maturity in the networking area?

Compass and chronometers

One of the key aspects of WAN governance is situation awareness: what is users' Quality of Experience (QoE)? What is the network performance? What are business and recreational applications that share the network? What is the network load? What is the peak hour in the day, peak day in the week, peak month in the year? Is it network, clients or servers that limit the application performance? All of this must be answered per application, per site, per business unit…

Like many if not all complex subjects that cannot be embraced easily and require progressive adjustments, a clear view of the situation is a major step for an optimized application delivery strategy in a well managed closed loop process that could be summarized like this:

1. Decide about objectives
2. Understand the current situation
3. Compare situation to objectives
4. Decide corrective or improvement actions
5. Apply corrective or improvement actions
6. Measure results and evaluate gaps with objectives
7. And so on…

A compass is a relatively basic tool that provides one value: north (or south) pole direction. A chronometer is a (less basic) device that provides one value: the GMT time. Both in hand, modern navigators managed to sail Mare Incognita all over the globe, while previous explorers that could not benefit from this technology had to stay in view of the coast line.

Like explorers, organizations that decide to apply WAN governance need simple and fundamental data that could be easily compared to goals. Not awfully long lists of parameters, figures, values, graphs, tables, charts... that will generate more doubts and questions than clarity.

It seems that the necessary quality of such KPIs (Key Performance Indicators) are:

• Simplicity (typically a value on a well-known scale like 0 to 10, or a RAG - Red Amber Green - code)
• Relevance to the objectives
• As few of them as possible
• Ability to be easily obtained

We will provide later some examples of application performance KPIs, like MOS (Mean Opinion Score) for voice and video, AQS (Application Quality Score) and Apdex (Application Performance Index) for data applications.

A very fundamental aspect of KPIs to take into consideration (and that will also be discussed in posts to come) is that KPIs are not neutral:

• They reflect the strategy
• They affect the behavior of the monitored process
• They modify the process they are measuring ("Observer effect")

Would you sail like Odysseus and take ages to get home (well, be kept as Calypso's lover for seven years may seduce some of us…)? If not, you'd better to get compass and chronometers before leaving the harbor…

 

(note: a technical incident forced me to republish this post - sorry for those who already read it)

Less haste, more speed

I am often required to participate in hiring interviews. At a recent one, the candidate repeatedly made the point that “I’m really energetic”. It seemed fairly true from his body language and general attitude and I saw this as a really cool quality. However I failed miserably to understand, or even get the guy to properly explain, what this significant amount of energy was and what it would be used for in his potential new job.

Having recently talked about the dual (Yin/Yang) structure of Global Economic Impact of WAN Governance, I will now discuss the first point of the Yang (productivity increase) aspect: ensuring an appropriate, predictable and stable level of performance.

As this point is often confused with the acceleration of applications over networks, I will be specific and isolate it: neither the goal nor the implementation are similar. We will talk more about acceleration in a later post; let’s concentrate a moment on guaranteed performance.

The goal here is to obtain stable business processes (like customer-facing transaction, purchase orders, financial consolidation…) through guaranteed performance of applications, in all cases, everywhere over the global network.

Application performance over the network and hence the processes they support, is impacted by many factors that relate more to the usage and traffic load than to the network itself:

·      Time matters: like in consumer networks, business network traffic changes, dependent on the moment you look at it. Each working day has its own peak times (usually up to 11 am, then up to 3 pm, with a lull for lunch). Monday and Friday traffic can differ from the other days (more or less activity, depending on enterprises). In some cases, monthend is critical (for example, financial consolidation for public companies). According to their market sector, enterprises may have very important traffic seasonal fluctuations (e.g. the end of the year for retail). On top of all this, time zones, bank holidays and so on all differ between regions…

·      Asynchronous events: the network is used for many types of activities, implying a lot of people working in different departments. Many events depend on poorly planned causes (e.g. anti-virus signature updates, data-base synchronization, data replication, video conferencing, etc.).While some enterprises still ask some of their employees to stop working on the network in order to protect critical applications periodically, this has become more painful, very hard to explain and justify and finally quite ineffective.

The impact of application brown-out depends on many parameters (the most important being the enterprise domain of activity). Consequences to the business are generally so important that IT managers often feel the need to put in place processes and tools to assess and manage the performance of business applications over the WAN, in order to provide their end-users with guaranteed performance - and prove it to their management.

Impossibility to forecast is the main challenge to consider when setting-up methods and tools to guarantee application performance over the WAN in large organizations. Such tools must then be able to automatically adapt to new situations, extremely rapidly. No wonder that Autonomic Networking, with its Objective-based management model, fits so well with performance guarantees: this is exactly the challenge it was designed to address.

Guarantee, first: the faster the car, the more stable it needs to be. Performance assessment and guarantee is the foundation on which enterprises may, when required, build additional performance enhancement mechanisms such as desktop virtualization, data caching and protocol acceleration.

Despite the fact that the economic impact of stable and predictable application performance over the network is difficult to evaluate in a standard manner (being tightly coupled with the enterprise organization and business), it is closely related to IT and WAN governance, extending well above “just” the IT, up to fundamental business processes. Like other “must have” capabilities, application performance guarantees are so essential that calculating its value to the business may even lead to very strange discussions (what it the NPV of your electricity supply?). Among many aspects to be considered are:

1.    Employee productivity: no wasted time because people wait for transactions to complete;

2.    Organization reactivity: antivirus definitions are updated in real time, financial reports are ready for their publication date, voice calls have the right quality, etc.

3.    Customer satisfaction: the waiting time to complete a purchase or reservation is acceptable, not too many people lining up at the desk…

4.    Employee satisfaction: nothing is less motivating for employees than having the impression that IT systems (like the other company systems, processes, organization, etc.) prevent them from performing well.

Workaholic people do not frighten me; however I decided not to hire this candidate. I was too unclear about how to channel his energy, and even wondered if it would not just disturb his colleagues and the environment without alignment to our own business and responsibility. Sometimes, less is really more…

(Thanks to Mark for this post Burtonification)