Pervasive computing. Sounds awesome, doesn't it? But, what is pervasive computing, exactly? Well, IBM defines it as the ability to manage information easily.

More specifically, it will enable people to accomplish an increasing number of personal and professional transactions using a new class of intelligent and portable devices giving them convenient access to relevant information anywhere, anytime. Wow. What a mouthful!

In theory, pervasive computing will simplify life by combining open standards-based applications with everyday activities. It will remove the complexity of new technologies, enabling us to be more efficient in our work and leaving us more leisure time. Again, this is a loose interpretation of IBM's definition of pervasive computing. It's truly a powerful vision for the future. Clear, crisp, and concise. More importantly, tools like WebSphere will enable this vision to quickly morph into a reality.

So, will pervasive computing become the utopic computing environment of the future, in which everyone will carry a handheld device of some type? Will it really allow people to seamlessly and securely (right) connect to the "network" and do all sorts of nifty things, all from anywhere and everywhere? Sounds kind of like one of those futuristic car ads from the '60s, doesn't it? But, unlike what the automobile manufacturer's hype of four decades ago promised, technology such as WebSphere already exists. Not simply an engineer's futuristic concept of "tomorrow," this new technology has brought companies to the brink of revising the way they think and do business.

When someone questions the reality or practicality of pervasive computing and how it may affect our everyday lives, ask them some simple questions. Like, do they or their kids use a notebook computer at home, school, or work? Can their e-mail follow them wherever they go? Have they ever relied on a handheld device such as a Palm or cellphone (yes, cellphone) to schedule tasks and communicate? Do people around them rely on this technology at work? Have they thought of purchasing one of these devices recently? Can they envision any of this helping them to do more, or progress further? Chances are that they will answer a resounding "yes" to some of these questions - and there you have it. Pervasive computing is real, and in use today. Widespread and meaningful use of pervasive computing is what everyone on the software and manufacturing sides of the business is banking on. Wireless applications and technology are hitting the streets daily. Prices are falling. Microsoft and IBM are drawing battle lines as you read this. Let's face it; WebSphere Everyplace was made for this stuff! These evolving applications and technology are golden opportunities for all involved, for many years to come.

Mission-critical applications, with this technology at heart, will compose the computing frontier just over the horizon. For instance, a pharmaceutical salesperson may soon be able to check the entire inventory and order history of his largest customer with the click of a pen on a hand-held - all while waiting for his meeting with that client to start. Armed with this knowledge, his company's sales will increase. In the end, this knowledge and power help assure that your local pharmacy has enough of a widely prescribed medicine in stock to cover the demand. That's pervasive computing at work. That's reality. That's the type of application that will require guaranteed availability. With everyone clamoring for a piece of the pie, and billions of dollars at stake, what will become a leading differentiator between "Provider A" and "Provider B"? The Service Level Agreement.

Background
Service Level Agreements (SLAs) are many things to IT professionals. An SLA can be as informal as an understanding of how things will be addressed between customer/supplier relationships within a single company. It can also be a 100-page legal document outlining specific roles and responsibilities between a service provider and a large client, where failure to meet the requirements of the SLA can result in multimillion-dollar financial penalties. Now, more than ever, the presence of an SLA in complex contract negotiations has quickly become the rule, rather than the exception. This article examines past, present, and future trends in this arena, and the long-range effects they will have on applications, service models, and enhanced offerings within the computing industry.

As a point of reference, I mention the term service provider throughout the article. Let me clarify what this is. I use the term rather loosely to describe an organization chartered to provide ongoing support of an application or system. Holistically, this includes all infrastructure, software, upgrades, break/fix duties, monitoring, reporting, inventory, etc. If you are in the game, whether as an in-house entity or an outsourced provider, an SLA may affect you.

In the Beginning
Not so long ago, the idea of a provider offering an SLA was little more than a sales tool. I say this because of the way in which these instruments were crafted, where any meaningful recourse on the client's part was conspicuously absent from any contract clause. Sometimes this SLA verbiage was incorporated into the provider's sales or service agreement, while other times it was found in separate documents. I can remember one Web-hosting provider's SLA, which boldly stated that if a client's site was down for more than eight consecutive hours, all monthly charges to the client would miraculously disappear. Nice, huh? Well, that depends. Once you really got into it, all the provider was really doing was giving the client the month for free, but buying the remainder of that month to remedy the problem. That's right! The agreement stated, in essence, that the client's site could be out of service or severely degraded until the cows came home (or at least until the month ended). Regardless of the monthly charges, what client can afford to have their site down for eight hours in the first place? But what was the client's recourse? Move out? Doubtful - what's the likelihood that a client is going to go through all the trauma and drama of negotiating a new contract and moving, perhaps only to wind up with a provider inferior to the one they're running from? Service providers know this, and take advantage of it, no matter what they tell you. In fact, they bank on it!
Another Web hoster made all sorts of promises as to their network's reliability. In the end, however, all that robustness was buried in confusing and contradictory legal terms, where "downtime" had to be determined by the client, using tools that were either unavailable or didn't exist. It also required the client to notify the Web hoster of the downtime event within a certain time period, or lose whatever miniscule reduction in monthly charges allowed as compensation. That's right; the SLA wasn't worth the paper on which it was written, but it looked nice. I'm pleased to say that customers are a whole lot smarter these days.

The Validity of Wanting an SLA
With all the horror stories and the hassle, why go with an SLA in the first place? Primarily because a well-written SLA is a very useful thing to have, for all parties involved. A poorly written, or one-sided, SLA almost assures an ongoing but hostile relationship. The real purpose of an SLA is as an instrument that sets rules, metrics, quality relationships, and measurable expectations between parties. The net result is a legal, binding, and enforceable agreement that gives and takes, punishes and rewards, and when all else fails, provides a mechanism for the client to walk away, with minimal risk. Remember, the SLA should never be crafted with only punishment in mind. It is merely a tool to help ensure system performance and reliability. Impossible you say? Never happen? Well, if you truly believe that, you're wrong.

Plan, Organize, Measure, Execute...
SLAs come in many flavors, shapes, and sizes. There are literally thousands of things that can be included in an SLA. For example, SLAs can include desktop support, server support, LAN support, WAN support, and Help Desk duties. Specific "time to repair" limits are typically required and serve as the measure of whether or not the provider is within SLA compliance or not. Other SLAs aren't component-specific in nature, dealing primarily with the "system" or "application" and whether it's available for some percentage of time or not. In either or all cases, and regardless of the specific content, the ability to successfully deliver service within the confines of an SLA lies in planning, measurement, and execution.

Planning. There's that word again. Crafting a comprehensive SLA is a complex effort. If you are a customer including an SLA in your RFP, you may be unpleasantly surprised to learn that your SLA requirements have added gargantuan hardware and support costs to the purchase price. This happens quite often. If you are on the receiving end of an SLA, you'd better do your homework. Analysis of all the requirements and long-range impacts on platform design, monitoring, and support must be comprehensive and detailed. Anything less is a sure recipe for business disaster, especially where stiff financial penalties are included for noncompliance. If your client relies on any WebSphere application or product to power their business model (yes folks, business model), including Portal Server, WES, Commerce Suite, et al., this affects you. If any are at the heart of the system, and you don't believe that these applications or components will need to be near-bulletproof when wrapped in an SLA, then you need to wake up!

Measurement is also key. It is, perhaps, the single most important aspect of and requirement for any SLA. The SLA sets all terms and conditions for performance and reliability. Most well-written SLAs will also set specific thresholds, benchmarks, and metrics. These factors may include latency and response-time criteria for LAN, server, and WAN components and circuits. It may also include repair-time thresholds and restoral time, as well as many other reliability and support parameters. The criteria will either be met, or not. To determine either instance, the ability to track and measure these factors is absolutely critical. A bit of advice, though; stay far away from any service provider that puts any of these measurement and notification responsibilities on the client! Some do, some don't. Those who do will quickly need to smarten up.

SLA Analysis and Understanding: A Key Component to Success on Both Sides!
SLA analysis is typically broken into two distinct pieces: business issues and legal issues. Here's where internal conflicts begin. For instance, some corporate attorneys believe they have the final say on the SLA document in its entirety. Better attorneys know that when it comes to the business issues, their job is to counsel and advise their business and technical counterparts. When it comes time to make the final decision regarding operational or business issues, the attorney leaves that up to others. Conversely, the attorney reaches out to the technical and business folks for counsel when he or she needs to understand something. Codependency is a crucial concept to understand and embrace in this type of effort. The team approach is the best methodology, as it is a key component for success on both sides.

Beyond the legal-technical friction that sometimes exists, friction between sales and operations is also quite common within vendor organizations and service providers. I have seen many an SLA cross my desk that included unreasonable performance guarantees, both in terms of vendor and client expectations.

Getting back to core analytical tasks, the true purpose of this undertaking is to separate which portions of the document can and cannot be achieved or properly supported. This means understanding the business, applications, hardware, data flow, and infrastructure before going any further. Once this knowledge is attained, the analysis of whether the computing environment will support the SLA begins. A simple example of this is a requirement for near-continuous uptime, with a proposed infrastructure that isn't truly fault-tolerant. If you're the service provider and you're aware of this clause, run for the hills! If you are the customer, and have dictated the environment for a provider to follow, you may be heading to Unpleasantville. If either party is dealing with budgetary restrictions, don't kid yourself into thinking that lofty SLA requirements are attainable at a low cost. Even if they were, chances are that the environment will eventually fail and the SLA parameters will be blown. Picture yourself being called on the carpet to answer basic questions, such as, "How did you think this could possibly work?" Yes, Mr. IT Professional, your job is to separate fact from fiction, and sales hype from operational realities. Also, never underestimate the critical importance of the application developer in an SLA analysis, as there may be some requirements that the application simply cannot achieve. Having the software experts participate in the analysis from the beginning is key and cannot be overlooked.

The initial analysis will determine whether the environment proposed will, or won't, support the requirements of the SLA. It's black and white. If it won't, documentation must be crafted and assembled to support your position, along with a viable solution either in terms of modifying the SLA or enhancing the environment itself. If the environment supports the SLA requirements, the second step of the analysis begins: operational realities and business process architecture. Fancy words for putting the physical measures in place to support the SLA. For instance, if the SLA requires a 45-minute turnaround time for problem resolution, you'll need spare parts and people to meet this goal. If the SLA requires continuous on-site monitoring, prepare to either build and staff a Network Operations Center, or outsource the task. This is typically where the hidden costs of doing business come into play. A 24/7 staff of 6-7 people quickly adds up. Systems and network management platforms can also add huge costs to the project. But, regardless of who performs the support tasks, it will likely be costly.

A New Twist
A recent trend in SLA negotiations, propagated by some service providers, is the belief that penalties and rewards are somehow bidirectional. What this means, in simple terms, is that the service provider reaps an additional financial benefit for meeting the terms of the SLA, while still increasing the one-time and recurring monthly support charges needed to mitigate the risks associated with it. The client is, in effect, billed twice; once for supporting the SLA and again for successfully complying with the SLA. There are sometimes relational scales associated with how close the provider came to complying with all of the terms.

Now pardon me, but I thought that "close" only counted in horseshoes and hand grenades, so the logic behind this whole thing fascinates me. Let's think about this: Provider A has won my business, and agrees to the terms of a rather stringent SLA. Let's say the SLA calls for high system availability and a 45-minute turnaround for problem resolution. Knowing that Provider A is a responsible ser-vice provider, I'm confident that they've factored costs into their proposal that mitigate the risks associated with the SLA. The solution calls for a more fault-tolerant infrastructure, server clusters, systems and network management solution, people, spare parts, and so on. Now someone must pay for all this stuff, right? Usually, it's the client. After all, service providers are in business to make money.

So, will someone please explain to me why the service provider is somehow also entitled to be financially rewarded for meeting the terms of an agreement that he or she priced, analyzed, and signed up for in the first place? Well folks, this seems a bit strange to me. It's like paying the car dealer extra money because your new car didn't break this month! Would you do it? I know I wouldn't! Isn't that the reason we decide to pay more for the cars with the most reliable service record? The same logic applies for the costs associated with an SLA. The client knows what's important, has dictated the terms, and pays the costs associated with supporting the SLA. So, why anyone would agree to additional charges based on a success rate is beyond me. Nevertheless, some service providers are proposing it - and getting away with it, to boot.

An at-risk pool of money is also a popular way to mitigate any financial exposure to the service provider. This methodology builds a certain percentage of the one-time and recurring charges into an SLA fund. The financial penalty for noncompliance is calculated on a sliding scale of sorts, whereas the at-risk pool continues to grow and is capable of sustaining a hit. Other firms have tried to have their SLAs underwritten by insurance companies. This is a nearly monumental task. Although the likelihood of hardware and software failures can be curtailed through sound design practices, human failures, on the other hand, are much more difficult to prepare for. Insurance companies have a real problem with some of this, especially when a large financial penalty hangs in the balance.

Communication and Its Effect on the Decision-Making Process.
Once the analysis is done, and major issues remain, the most productive way to deal with the decision to accept the terms or walk away from an SLA is through simple communication. If you are the client, ask yourself why you have included certain things in the SLA. If you are the service provider trying to make sense of it all, ask the client why they have included the things they did. See things from the other side. Would you accept the terms? Would you have asked for what your client is asking for? Is any of it reasonable? Can these parameters be measured? How much risk is involved for either party? Ask these types of questions. Do some soul-searching. Remember, the idea is to build trust. With trust comes confidence, which will eventually lead to long-term and successful relationships.

If you're not sure how to do it yourself, reach out for help. There are a number of independent firms available to assist with SLA assembly, evaluation, and negotiation. I can't stress how meaningful a well-written, measurable, and enforceable SLA is in today's computing environments.

The Relevance of SLAs to Pervasive Computing
So, where does this all fit into the pervasive computing environment? Well, think about it. Wireless communication and computing is already upon us. But, if pervasive computing is to truly be more than a lark or multibillion-dollar boondoggle, nonstop data streams, communication modalities, and applications will need to be available 24/7 worldwide. Continuously updated databases will be the norm. Open standards and architectures in computing and communication will provide the mesh that is required to make it all work. Everything will be "always on," and behind it all will stand the guarantees that will be the de facto standard for any enterprise client betting their future on pervasive computing. These guarantees will absolutely be required before entrusting any piece of that future to anyone.

You need to understand the costs associated with converting an enterprise business model to take advantage of all of this. It's huge, not only in the cost of hardware and software, but also in soft dollars. Don't kid yourself; this is a megadollar adventure. Wrong decisions could cost people their careers and could ultimately bankrupt clients and service providers alike. SLAs can be nasty double-edged swords. Clients will demand guarantees, and service providers will demand high-end infrastructures and support models to help mitigate risk, while still making it cost-effective for both sides.

Conclusion
The terms and conditions outlining these relationships will come in the form of complex Service Level Agreements. For the service provider and client alike, it will simply become a willingness to put their money where their mouth is. Those who rely on slick and meaningless legal mumbo jumbo will fail. Those who understand the business and how to fairly and equitably mitigate risk while supporting a computing environment backed by a performance agreement, will flourish. It's that simple. Welcome to the world of pervasive computing.