Agile in Action

A bit more of the creeping insanity that has infested the Googleplex since the return of company co-founder Larry Page to the position of CEO has revealed itself with yesterday's release of the Chromebook Pixel at a whopping $1,299 entry-level price.

It's hard to imagine a device much further from the original premise of the Chromebooks, or less useful at filling the niche they were originally intended to occupy. When first introduced in 2011, the lightweight, web-based devices were an innovative stab at offering something approaching the mythical Hardware as a Service... a cheap, subscription-based alternative to expensive and fragile mainstream laptops which are frequently vastly over-provisioned for their actual uses. In fact, they were explicitly designed to address the "complex, costly and insecure [emphasis mine]" laptops already on the market.

It could be that there was no margin in the original offer of a $28/month subscription service that the devices were rolled out with. Indeed, it seems that Google has largely sidelined that subscription program and farmed out the fulfillment of the Chromebook "rental" business to another (financing!) company. But it's unlikely that the motivation could ever have been to make money directly on the devices; rather, they tended to support Google's profitable meta-goal of improving the Internet experience and making it safe, inexpensive, and easy in order to drive more users online and into the embrace of various Google advertising services.

Chromebooks have always had to face the criticism that they were less functional than their competitors, and were somewhat able to address that critique by pointing to the price tag... not simply the initial cost, but the dramatically lower ongoing support costs resulting from a remotely-managed black-box device. But the Pixel utterly destroys that argument; even the features it adds to the Chromebook experience are utterly useless in the Chromebook world. I'll let you take a quick side-trip over to Computerworld to have Preston Gralla demolish the Pixel point-by-point for you.

One thing Gralla doesn't address is the free terabyte of storage the thing comes with for 3 years, which some other reviewers have held up in defense of the awful pricetag. But finding a terabyte of storage for under a grand a year isn't terribly difficult right now, and in three years, it will be even less so. So if you want to look at it as a cheap way to purchase online storage, bear in mind that it comes with a three-year lock-in, a period during which prices are almost certainly going to be falling.

But the specific reasons the device is antithetical to the original Chromebook concept are less interesting than the question of whether or not Google's original premise of simple, safe, inexpensive, utilitarian online computing is sustainable now that Google themselves seem to be throwing in the towel on it. Utility computing in general remains a safe bet for the future of IT services; the economics of the model within the visible horizon of hardware and software are all but unassailable. But the missing piece, at least for IT operations, is the last two feet of service delivery--the devices themselves that we are pushing out centralized, secure, managed services across remain expensive, complex, and insecure... difficult to support, easy to compromise.

Solutions for our other infrastructure problems are all well-along the paths to maturity. But Google seemed to be alone in looking at the problem from our perspective; other major vendors continue to profit too much from the dysfunction of complex devices to have any motive to offer ground-breaking alternatives.

With Google out of the game, is there anyone else who will take up the problem of safe, simple, secure delivery to the end-user?

Oh, you brave BYOD supporters, your doom is upon you now, in the form of Microsoft KB 2814847: "Rapid growth in transaction logs, CPU use, and memory consumption in Exchange Server 2010 when a user syncs a mailbox by using an iOS 6.1-based device."

You did the right thing. You bucked the IT department trend; instead of locking it all down and freezing those pesky iPhone users out, you supported direct access to your expensive and coddled servers from their swarming devices. You made it as easy as you could, you didn't gripe and moan and try to force them to use OWA or install complex and invasive third-party management software on their precious phones. You walked them through the setup, held their hands, probably answered some uncomfortable phone calls in the wee hours, helping them manage the setup as they were desperately trying to retrieve that important budget memo at oh-dark-thirty. You were the good guy. You saw the curve and got ahead of it. And this is your reward? Crashing servers and, inevitably, complaints from all those very same users that drove you to this dark ledge of despair in the first place?

Well, climb back down off that ledge. I'm hear to reassure you that you did the right thing. It's not your fault. Nor, for that matter, is it the fault of your ignorant and demanding users. And while Apple is blaming Microsoft and Microsoft is blaming Apple, leading some sources to suggest that this is a pox on both their houses, and Microsoft is suggesting, snidely, that you report the problem to Apple nad in the meantime, maybe, you know, cut off all iOS devices, don't you believe a word of it. This one is squarely in Microsoft's fault box.

Public interfaces to critical servers should never be vulnerable to calls, or combinations of calls, from any device, that can crash the service. This is a security problem, plain and simple. Any attacker could be making the same XML post call (within a few days, some probably will) with no iOS device in the loop at all.

The spin is fun for folks who are looking to drum up more controversy over BYOD policies, but in fact, this is a plain old-fashioned security vulnerability, just like Microsoft has been cranking out for decades before iOS ever appeared on the seen. There are certainly real concerns and considerations to put into your BYOD policies and practices; concern about this sort of thing shouldn't be one of them.

I went to Interface 2012 last week, one of the several rolling, sales-driven technology conferences that makes its way around the country several times a year, having made the same Faustian bargain as other attendees to give way my time, personal attention, and e-mail contact information in exchange for turkey and lettuce wraps and tepid coffee.

Absolutely none of the vendors there interested me and very few of the conferences (an exception was an out-of-place presentation by Josh Thomas on cell-phone based wireless mesh networking, a fascinating concept that I'll talk about here on my general IT consulting blog). But there was a short track dealing with Bring Your Own Device challenges. Since BYOD can be an important contributory policy to IT agility, I thought I'd visit and see what they had to say.

First up was Cerium Networks, presenting a bald sales pitch for Cisco's Identity Service Engine and various other expensive related devices. The presenter went through a basic outline of the problems introduced by BYOD in terms of security and support. He went on to characterize the new world of mobile devices as requiring not simply authentication of the user, but also determining when, where, and how access to corporate resources is being engaged. ISE and the related ecosystem solves this by using client-side code to answer those questions and restrict access accordingly.

As I watched the presentation unfold, I realized that what I was watching was a particularly weak attempt at re-branding a corporate mobile device management technology as a BYOD approach. And the Cisco tool doesn't even provide complete device management... you also have to install third-party tools, all of which restrict device selection and require non-trivial setup and configuration effort. But that doesn't matter much, because it's hardly your device anymore if you have had to install a passel of management software tools and give someone else the ability to arbitrarily wipe all the information--corporate and personal alike--at the drop of a hat.

To be honest, I like the dynamic approach implied by the ISE concept as a means of increasing security in a BYOD world. Unlike the relatively restrictive and rote rules ISE itself allows, though, I would prefer a more data-driven and nuanced approach. Instead of being restricted because you are logging in from you phone, I would like the system to make an analysis of your utilization patterns, similar to what credit card companies already do, and what Google is beginning to implement, to determine if it is likely to actually be you, or an intrusion attempt. Additional levels of challenge-response could be levered against the authentication process if it seemed questionable that it was actually you, or the attempt could be denied if it were deemed too unlikely.

Next was a seminar by Structured Communications. Strictly speaking, the presentation was terrible… one of those which consists almost exclusively of the presenter reading off his monotonous list of PowerPoint bullet points as they are splashed up on the screen in front of the dazed audience. Please, just e-mail me the article instead!

But the information was all good, and it was clear that the engineer making the presentation had real experience and insight driving BYOD initiatives. He covered the cost savings, satisfaction and productivity benefits, and need for overall systemic changes in order to make such projects successful. He also emphasized a manageable, rationale, stair-step approach, starting with only small, key business units with clear business cases for BYOD approaches instead of attempting to bring the entire company on board at once. The only thing he failed to note that we cover in our own article on the topic is the support benefits.

From the attendance at both presentations it's clear that there is considerable interest from IT departments in how to handle BYOD issues... as both presenters noted, this is a matter of when, not if, and almost every business already has a segment of BYOD users whether they realize it yet or not. But it's also clear that there are a lot of consultancies and vendors out there who have not truly adjusted their thinking to the reality of consumerized IT services, and it's going to be an expensive side-trip for folks who catch the Cerium presentations of the world and miss the Structured Communications approach.

There is a dark side to agile processes that we like to cover up by presenting only the optimistic perspective; namely, that rapid iteration can serve to create bad changes to systems as well as good ones. What we tell people when they point this out is that mistakes are inevitable, and it's better to make them quickly and then take advantage of the same rapidly iterative process to correct them more quickly than would otherwise have been possible. That's not wrong, and agile is a real benefit when it is used in that way by well-meaning, attuned professionals sharing a common goal.

But agile isn't always used by such people and some of the effects it has when used poorly by people with alternative agendas are chilling.

Google is becoming something of a poster child for this abuse of iterative development. Sometime in the last couple of years, the company realized that Facebook had landed on a product paradigm that could unseat it as the advertising king of the Internet, and began over-reacting, Microsoft-style, to the threat. As folks have noted, this has not been a boon to their consumer-facing products. Even within the company, this volte-face has been seen as extreme and unpalatable.

Though proceeded by a vanguard of PR, neither have these changes gone unnoticed by the people using the products. New products developed under the regime have failed to attract many avid users, and old products that have been radically revised have alienated their existing user bases.

Moreover, in the process of rapidly iterating through these changes, the company has broken, on a temporary or permanent basis, much of the functionality that appealed to users in the first place. Older Android phones slow to molasses with updates, many of which do not even offer them the new functionality; Chrome's advanced integrated web services fail when used via tethered Android devices where newer and simpler competitors such as Duck Duck Go work just fine. And old, longstanding bugs or feature requests have been ignored in the rush to socialize the diverse application base. Not having a plan becomes an excuse for not doing things.

This all may be a particularly diabolical reading of the situation. I have argued before that there are certain sorts of products that just aren't amenable to the sort of close-knit relationship between developers and users that many agile development frameworks envision. The large, widely-used products that make up Google's core offerings (Docs, Gmail, Search, Adsense and the like) may fall into that category... there simply may be too many divergent use cases and types of users for the traditional agile feedback loop to even begin to function properly. And without accurate feedback, perhaps those products are simply destined to drift off course even without evil intent.

But one of the benefits of agile is the ability to correct your course quickly and with gentle nudges. If Google is doing this, then what you end up with is their intent. Agile takes away a lot of excuses when it comes to implementation; a traditional development or service organization can take requests and point to their lengthy backlog and say, "Gosh, we wish we could get to this, but it won't come out until we release our next version in two years." If an agile outfit ignores something for two years, it's not because they didn't have a chance to get to it: there's a reason behind it, and if they're not willing or able to articulate it clearly, it's time to worry about their intentions. This shows exactly how important intent is to customers served by agile organizations.

Process is not the sole arbiter of outcome. It's important, but it's no substitute for having good ideas, good user relations, and a steady hand at the helm.

Bridget Botelho at TechTarget brings up an excellent hidden gotcha in the Bring Your Own Device movement: enterprise licensing agreements! In "BYOD and mobile cloud apps lead to licensing compliance issues" she points out that some of the most common enterprise software licensing agreements (Microsoft's, in other words) require licensing any device used "for the benefit of the company" under the terms of the enterprise agreement.

This isn't particularly surprising to anyone even halfway familiar with the morass of licensing terms spewed out by major vendors; you can pretty much assume that you are required to sacrifice your first-born child and those of all your employees on the demand of any anonymous lawyer or third-party sub-contractor even remotely affiliated with Microsoft, Apple, or Oracle. According to Keith Norbie of Nexus Information Systems, a Microsoft Gold Certified Partner, this means that even if your employee purchased licensing for the device when they bought it, you are still committed to licensing it again under your enterprise agreement.

Botelho goes on to provide the conventional advice for dealing with this new vulnerability; run audits, exercise more control, implement policies, etc, etc. I can't help but feel that almost entirely misses the point of BYOD and does away with many of the advantages it can offer. If you have to exercise that degree of control, then it probably is more efficient to do so by eliminating BYOD in the first place and mandating corporate-issued devices only.

Of course, you tried that already, didn't you? Consumerization is a ride you can't get off of, and enforcement just adds costs. Half-measured approaches such as those suggested in the article don't seem much of a solution.

What is the solution? Go all in; avoid archaic and arcane licensing restrictions from old-school vendors by switching to alternate products. Gmail doesn't care what device you, or any of your employees, are using to access it. Or, as the article also suggests, move primarily to virtualization for provisioning apps with restrictive CALs.

The pushback on this is likely to be that key features are missing from the alternatives or that those other vendors have their own difficulties and ulterior motives to bring to the table. That may be true, but from the larger perspective there are two major factors to consider. One, do you want to saddle your operation's horses to legacy on-premises software vendors when it is becoming increasingly clear that utility computing is the future? Two, without some sort of market pressures from good consumers such as yourself, do you imagine that licensing terms are going to change favorably for you?

As with most decisions, you have to pick your poison here, and dealing with the teething problems of BYOD and utility computing services seems to me to be the more forward looking position. Taking a view of other legacy industries that have been outmoded by other vast changes in technology, it seems likely that all you will see from the Microsofts and Oracles of the world here will be increasingly desperate and grasping terms as they turn to their massive legal horsepower to drag them out of the pit of declining market share. The article points to exactly this factor, noting that Microsoft has not yet begun enforcement of these provisions, but is likely to as PC sales in general drop.

Klint Finley at Silicon Angle asks "Is DevOps Destroying Jobs?" If you are a fan of DevOps and of agile approaches in general, you had better hope that the answer is "Hell yes, DevOps is destroying jobs!" If it isn't, then you need to question why any reasonable business would want to implement it, or any other agile approach.

Since I can hear some of the objections already, let's back up a bit and look at what information technology is all about in the first place. Primarily, the automated processing of information is about creating efficiency. It allows us to perform certain tasks in less time than they would take to perform manually, and in some cases creates the possibility of performing tasks that were untenable or simply unimaginable in a manual, non-computerized world.

Many, and probably most, of these tasks are already being performed somehow, and they are being performed by real, flesh and blood people who are getting paid to do them. When the tasks are automated, those people aren't necessary to the performance of the tasks. It may be that there are other tasks within the organization which they are qualified to perform; it may be that other organizations haven't automated those tasks yet and those people can find jobs with those. It may even be that, in having automated those tasks, new types of tasks are generated that these people can instead move on to perform.

Like the Hackett report referenced in Finley's article, we like to kid ourselves that growth will lead to new jobs to absorb all of those poor outmoded furriers, telegraphy editors, and sysadmins. Those are all relatively rosy outcomes, however. The reality is that most of the time, automation removes a manual task and adds value to the organization, but not the employee. That is, and must be, the motivation that leads to automation and efficiency in the first place. Job creation is an expense for businesses, not a revenue center. New jobs are often created in the economy as a whole out of this automation, but the people getting the pink slips are only qualified to perform them by occasional happy accident.

Finley asks what IT can do to increase jobs, but that's an antithesis to the premise of technology in general. If you're adopting or advocating a technology for business that isn't decreasing jobs, it's probably not a good business technology. Making things more efficient and easy is often a boon to humankind but that's a separate question from increasing jobs.

Proponents of agile operations, such as myself, can be expected to spew out a litany of justifications and suggestions for implementing the philosophy in the real world. However, you may rightly be skeptical about such cheerleading; if you don't subscribe to the philosophy and you don't find our arguments persuasive, then all the suggestions carry a taint as well.

So from time to time it's useful for us to point out what other folks are saying in support of our arguments. Ars Technica has recently published the results of a protracted discussion in comments over the question of what the top change that existing IT departments could make to improve productivity in their organizations. The article and comment thread that spurred the summary article are also worth a read. Here is what they came up with:

Embrace Consumerization

The primary objection to allowing BYOD is rooted in support (followed closely by security). But there is a broad misunderstanding about support and the support function that may render many of these objections irrelevant. Broadly speaking, folks in the IT community who spend a lot of their time doing support sometimes forget that support is only a task that originates when behavior in the system is not as expected. When the system has not been designed to work with disparate devices, then of course support will become onerous. Addressing the issue by upping support resources is the wrong response, however. Fixing the system so that it will work smoothly with individual devices is a better solution. Whether it is cost-effective depends on the cost of adjustments versus the cost of support, but the latter is frequently so high, and the benefits of supporting individual devices so great, that it quickly pays for broad system alterations.

Similarly, some have difficulty conceiving of scenarios where security can remain under control while still allowing the use of independently owned devices. But, pulling perspective back from corporate IT slightly, it is clear that protecting data while still allowing users to interact with it is a problem that has been given substantial consideration and has had many potential solutions built over the years. Any major interactive website deals with these issues, and most of them quite successfully, and they have done so for years. There's nothing magical about enterprise systems that prevents this from happening with them, just a limited mindset and certain budgetary realities.

Train users, give them the tools to control their own destiny

I've never been a big fan of training and I don't think that training necessarily falls into the agile approach; if you have to train people on it, you've created a system that is too complex, and time spent training is time wasted actually doing things. But giving tools to users is a worthy endeavor, and I suppose I should differentiate between training people on overly complex systems and educating them about their options for automating their own work directly. On balance, I think it's a good call.

Virtualize

This goes hand-in-hand with embracing consumerization safely and economically. The relationship may not be immediately obvious, but one of the fastest and best ways to accomodate users on disparate devices without exposing your data to loss or hopelessly confusing your support scenarios is to virtualize the access to your systems. That's on top of all of the other benefits virtualization brings to agile operations.

Stay out of the way

I would have phrased this differently but the sentiment is correct; IT should be an enabler, not an obstacle, to the main effort of the organization. This is simply part of the next conclusion...

Get the basics right

Being solid on the basic services is part of what allows all the rest of these steps to occur. And fortunately, this also leads to a virtuous circle where less time is spent fighting fires, leading to more proactive and user-benefiting investments, which leads to still fewer fires. It's easy, particularly with agile, where people aften try to confuse motion with substance, to forget that you can only truly pivot quickly if you have a solid base to do so on. Making sure your infrastructure is solid, your policies are sound, and your staff are competent is the necessary first step to embracing agile operations.

The cost of fixing poorly written code is apparently going up these days, leading to the question of how much good agile development is actually doing in the modern enterprise.

There are a lot of assumptions packed into that question and few hard answers so I will stipulate up front that this post is filled primarily with crass speculation. Let's look at what we know and what we don't.

What we know is that Cast Software maintains and analyzes a database containing 365 million lines of code from 160 different companies. Last year, automated analysis of that code base for certain structural defects was run and costs to fix each defect was estimated at $2.82 "per line of code in the application." This year, the cost rose to $3.61 per line of code in the application. On that basis, Information Week concludes, "hurry-up development passes along problems to enterprise IT."

This sounds like a job for... DevOps!

But wait... let's talk about what we don't know. We don't know what development methodology was used for each of those apps; since agile is getting more play in and outside the enterprise, it's quite possibly one factor, but we don't have any idea how large of one or what the increase in the surveyed base agile projects might comprise. We don't really know how the cost to fix the code is arrived at; Cast mentions some assumptions for programmer costs and time-to-resolve but it's not clear if those assumptions were identical year-to-year or not. The cost to fix also makes the assumption that the problems are being fixed, which may not hold try in many cases since "The 'violations' that it [the analysis tool] finds are not necessarily going to stop an application from running." In some cases, it's not certain that the identified practices actually result in reproducible bugs in the production environment.

I am a fan of hard data in the service of practice analysis, and so I applaud the efforts here to put some real numbers behind code maintenance. "Technical debt" has become a popular buzzword lately, deployed most frequently in support of arguments that it is worth taking the time to do things right the first time. But those are mostly theoretical arguments, and although this study attempts to put some numbers behind them, they are overly general for use in actual decision support. Abstractions are a necessary part of coding, but if you need to evaluate technical debt in your organization, base it on measurable outcomes and not theoretical studies of somebody else's problems.

Originally, this post was entitled "BYOD isn't about retention", written primarily in response to Rachel King's post at Between The Lines titled "Accommodating Personal Devices at Work and other IT myths" which discusses recent survey reports indicating that a Bring Your Own Device friendly policy is not seen by executives as a personnel retention strategy. Nor should it; getting your work done in the most effective manner shouldn't be seen as a perk. But then I caught Andrew Nusca's post today for the same blog asking if IT consumerization is top-down or bottom-up, which questions a New York Times article suggesting that senior level executives enamored of Apple products are largely driving the BYOD trend.

Together, these posts underscore a deep misunderstanding of the dynamics of BYOD, both operationally and politically.

To be fair, King's article is primarily questioning the growing perception that BYOD policies are becoming commonplace in the businessplace. Like most buzzword-driven trends, I believe this one is being over-hyped and adoption is lagging the reporting, so King is likely correct (as her citations suggest). The interesting thing is that she ascribes this largely to executives failing to see BYOD as a tool for driving recruitment and retention. This makes some sense if you are viewing the whole thing through the prism of much other recent reporting highlighting the difficulties that businesses are having employing Millenials; seen as entitled, disinterested, un-motivated, but tech-savvy, it may well be that some hiring managers are of a mind to simply throw every possible technical benefit at them they can. Since Gen X is relatively small and Y is going to have to be tapped at some point to become the majority of the workforce, one can sympathize with the plight.

But from the IT perspective, BYOD makes sense for much more direct operational reasons, and assessing it as a possible strategy for business needn't, and probably shouldn't, try to account for its attractiveness to potential employees. BYOD is about driving down procurement and operating costs and leveraging IT expertise where it can have the greatest impact on the bottom-line. Stipend-based procurement and device support provides more predictable (and often lower) device costs, and allowing users to work with devices they are most personally familiar with reduces training costs and internal technical support cases. Moreover, the general re-orientation that is required for IT departments to support web-based and multi-device access can have the effect of creating more focused, disciplined, and stable operations framework for business use. IT can spend less time focused on repetitive, costly support cases and more time securing and stabilizing the back-end systems which they are best qualified to work with. Turning corporate data-access into a centralized black-box does away with a raft of other common IT issues, while still improving access to front-line users; a win/win for the business.

But, getting to Nusca's post, this isn't something that is broadly recognized yet. He shares the popular narrative of BYOD with King, that of renegade Millenials simply bringing their phones in and effectively forcing their businesses to open up for iPhones. So, in response to the Times, he asks,

Is it really fair to conclude that just because senior-level executives are more likely to use Apple products at work, they are therefore disproportionately driving the change?

What about the designers, sales reps and other employees? As a group aren’t they just as likely to affect change?

There are a couple of things going on here. First, if you for some reason don't conclude that senior-level executives are capable of disproportionately driving change, then you have to ask yourself, what exactly do senior-level executives do? If they don't have greater control, can you even call them senior-level executives? If designers and sales reps are just as likely to affect change, then they need a salary bump and a title change. Now, recognizing that in fact that may be the case in some organizations, the fact remains that ultimately IT goes where the guys who sign the paychecks point. I know many companies where lower level staff started bringing in and attempting to use, with varying degrees of success, their own technology from home. In none of them did this become widespread or officially supported until a senior executive got behind it. IT is often resistant to BYOD for their own reasons, and unlikely to support low-level staff trying to drive that change on their own (even though IT staff, themselves, are frequently at the forefront of this effort... but only inasmuch as they find convenient for themselves).

The reality is that most companies should be run more as Nusca seems to believe they are, with input from the front-line staff effecting dramatic operational changes. But a quick glance at any Scott Adams book should disabuse him of the idea that they actually are run that way today.

While I believe the BYOD improves operational agility and has sufficient economic drivers to be worthy of consideration, corporate executives are people too. Their personal proclivities have been driving company policies and acquisitions since the corporation is invented and there's no reason to think they are not continuing to do so today.

Three years ago, when online game streaming company OnLive started up, there was a lot of disagreement in the gaming community over whether or not they would actually be able to take high-performance, demanding games and stream them over the public Internet at a rate that would preserve the single-user, first-person game experience on low-end devices or set-tops. It beggared belief at the time that the bandwidth would be sufficient, that the stability of the connection solid enough, and that the technology would exist to effectively pipe a game that required top-end desktop hardware to run at home to provide a satisfactory user experience... all for ten bucks a month or less.

Today, the service is still in business, and having used it personally, I can say that it is not a hundred percent infallible, but that it comes pretty close to the mark. In fact, the actual game experience and stability is superior to their ordering and customer service applications, which are the less fraught technologies involved in the business. The games themselves play virtually identically to their desktop-based counterparts. In fact, if one accounts for the myriad difficulties of keeping an individual PC up to the state of the art, and messing around with various minor hardware incompatibilities and tweaks that are still sometimes necessary with the most advanced games, the OnLive experience can actually be superior. It's certainly more economical.

This week, OnLive has announced the release of a Windows 7 virtual desktop available on the iPad. This is a day I've been waiting for; back in 2009, I noted that if you could successfully stream such demanding and performance-intensive applications as games over the Internet, you could certainly do it with any business desktop application. The economics are bound to be as advantageous as they are with respect to gaming, and the intangibles might be even better... virtualization in general has already proven itself in those respects.

The example of virtualization demonstrates that this is not an unprecedented advance in desktop delivery. The real difference in the OnLive approach is that it consumerizes the technology. To date, if you were interested in provisioning virtualized desktops to your users, you were responsible for putting together most of the backend and support for that service yourself. There are a handful of companies who will provide virtual desktops on an instant, pay-as-you-go basis (a la any other sort of cloud-based service) but none that have approached it with the consumer-standard instant and automated provisioning that OnLive will provide. That sort of flexibility is a boon to IT departments interested in exploring virtual desktops without large up-front commitments.

For now, OnLive only plans to offer this service to iPads, but if it proves successful I would imagine they will follow their pattern and expand out to other devices soon. And other providers may follow their lead with a more explicitly business-oriented offering.

There are an increasing number of examples of uses of the Fragile Support concept in the wild lately. One of the best of the recent crop can be found at the Avon Community School Corporation in Avon, Indiana, as articulated in this ZDNet interview with Jason Brames and Jason Lantz of the Avon Community School.

The school has undertaken a major desktop virtualization initiative as a means of coping with both aging machinery and increasing pressure to allow students to bring their own devices in for use in the classroom. Along the way they have seen all the other benefits of centralized desktop virtualization in the form of reduced licensing costs, better security, and broader access for users, but what is of the most interest here is the positive feedback loop introduced by reducing support requirements by outsourcing or obviating physical machines and freeing up IT resources to implement and perfect centralized, core services. This is a classic example of the benefits of the Fragile Support model.

The emphasis in the classic conception of this is on pushing support outside the organization; using device suppliers or individual owners as the support provider of first resort for basic equipment and software issues. But an alternative formulation of the concept relies on retaining the support function internally, but simplifying it by standardizing and virtualizing the systems being supported. The Avon experience demonstrates the efficacy of both approaches.

By virtualizing their desktops, Avon has been able to not only realize all the conventional virtualization benefits, but has also been able to allow students to bring in their own devices to use safely and securely in the school network. This sounds good on the face of it, but when you consider it in terms of computing requirements, it gets even better: with a twenty percent increase in the number of students able to bring in and use their own devices, that's effectively a twenty percent reduction in the required capital expenditures for school-owned equipment. And the school-owned equipment in place will have an effectively greater useful lifespan with the lighter resource requirements posed by virtualized desktops.

It's about bringing IT's focus back into core competencies and getting IT concerns and process out of the way of users. The classic equation for determining IT support staffing is heavily dependent on the number of devices in the organization. Virtualizing these devices essentially collapses the support requirement down into a figure of 1 image. That's a powerful force multiplier for the average IT organization, which may be perpetually understaffed for supporting the number of physical machines in use in the company, but which by this alternate criteria may suddenly have an embarrassment of manpower available to support the virtualized systems. Understaffed, IT is faced with a constant inability to get ahead of demand curves. The department is forced to deal with issues reactively instead of proactively, and frequently finds the same issues cropping up to be dealt with using the same patchwork fixes that satisfy neither users nor IT staff.

With all the resources available in a virtualized environment, IT suddenly has room to be more proactive. Support responses themselves should become a gold standard of service and responsiveness with more staff available to service them, but they should also become more infrequent as IT staff has more time to polish and perfect their service delivery. This virtuous cycle continues to feed itself as chronic bugs are squashed by permanent solutions, and more attention is paid to user requirements and satisfaction.

It's possible to get so wrapped up in discussing DevOps or agile development, or agile anything, really, that you miss the point of the concept: to better serve the "customers" of the processes you are agilifying. In fact, I suspect much of the bad rap that agile adherents get is a result of spending a little too much time being agile, and not enough serving the larger objectives of the organization.

This has been on my mind watching Google fumbling around lately. Although their internal processes remain shrouded in mystery, as far as customer-facing interaction goes, the company has been a poster-boy for the agile approach: release early, release often. But the larger it has become, the more that philosophy has come to conflict with the basic need to satisfy customers. More and more Google products are drawing more and more fire as they are either discontinued, rapidly obsoleted, their feature sets radically altered, or their interfaces jammed into a new and poorly considered standard.

These are classic techniques (or symptoms, depending on your point-of-view) of agile processes... try small things, get them out the door, prune what isn't working aggressively. The problem comes when there is no overall vision behind this, and when what "isn't working" is judged from the perspective of the producer rather than the consumer. Alienation and distrust are what you get when you decide to discontinue a popular, though niche, application, service, or feature set. Those are not outcomes that support the banner of either customer collaboration or individuals and interaction.

Like any tool, agile can be used poorly. Consider how you are using it and make sure you can see the forest for the trees.

The headlines on TechMeme yesterday were a little overblown: Google Engineer Disses Google+ on Google+ because he couldn't figure out how to post on Google+ privately, ha ha ha. If it was a little amusing, it was also a distraction from the main message of the now-archived post: Google has conceptual trouble building platforms and Google+ is a "pathetic afterthought" because of that.

I basically have two responses to that. One, of course it's true, Google has pretty consistently cranked out a series of interesting, innovative products that have failed because they neither provide nor support a larger platform. Buzz, Wave, Google Video, Knol, Orkut... one could go on. But, two, none of that really matters because in few or none of those cases, nor again with Google+, was it really necessary to create a successful platform or product; it was enough to provide enough a semblance of one to spur the competition to improve their own.

I can't speak to the motivations internal to Google, but if you examine their incentives, it's clear enough: Google succeeds financially on the basis of Internet advertising. To the extent that more people use the Internet, for nearly any purpose, Google benefits. It is, in fact, a massive waste of their resources to create a platform if other people are willing to do it for them. They simply need to foster that growth. Releasing the modern equivalent of vaporware seems to have that effect. Of course, Facebook represents an ad-revenue competitor, so that's a bit more complicated, but notice how the company reacted like a scalded cat as soon as Google+ was released. Google is still moving the needle.

None of that really relates to agile operations, though, and the only reason I really read through the post was that the engineer's name rang a bell. A little searching and I realized I had read one of his posts before. And it was about Agility!

I thought it was interesting because some of the concepts he touts in the earlier post, the absence of project management and the emphasis on the individual engineer, could fuel the problems he describes in the current post. Google engineers are churning out products, not a platform, because when you are working in small teams without external direction, a product is pretty much what you can build.

This is not a problem that relates directly to agile, but it does serve to highlight some of the flaws of avoiding any methodology at all. His conception of good agile revolves around the emergent system formed of offering individual incentives, but at some level, that's bound to fall apart without additional coordinating levels... the dreaded project managers or their ilk.

In my view, that's exactly what agile gets right, in that it continues to recognize a need for that level of coordination, while at the same time seeking to make it as un-encumbering as possible by emphasizing individuals, collaboration, and flexibility over the traditional constraints of PM-centric methodologies.

Of course, that's not going to help Google, because you can still have all that and fail to have the vision to make use of it. Yegge confirms my long-held notion that Google doesn't have that vision (although I don't necessarily agree that they need it; serving ads doesn't require it). If they got it, though, you have to question how they could leverage the internal methodology he describes to act on it in the way that an Amazon or a Microsoft did.

Based on my own anecdotal experiences, agile operations and DevOps have garnered quite a lot of buzz in the past year or so, but are still far from being commonly used in practice. Steve Shah at Citrix has written a post that seems to echo that observation, while clearly and concisely explaining why that is the case and why it isn't necessarily a negative commentary on the methodologies involved.

Steve points to a factor I have often mentioned, that for many organizations DevOps just doesn't make sense, and ties in two other factors I had not: the natural conflicts of human enthusiasm with actual capabilities, and the general business perspective of CIOs that many of the advantages of adoption will naturally cascade out of other IT initiatives, namely the general migration to utility computing solutions. The first I often overlook in my own enthusiasms; the second reflects another long-held belief of mine that it is vital to get management on board when attempting to implement these methodologies. If there is a groundswell of support for them but little effort to bring management on board, what you see is exactly the attitude that Steve reports, and the adoption levels point to the actual influence that IT management has over these efforts, be they stealthy or not.

My gut take on agile development adoption is that it occurred fairly rapidly. But then programming conventions have often adopted rapidly; new languages propagate quickly, why not new organizational techniques? Programming teams tend to be smaller and less rigid by nature than operations teams so it makes some sense that they could swivel to agile more rapidly.

I suspect that agile operations adoption will swell first in mid-sized organizations, those large enough to require some sort of IT organization, but not so large that the organization is self-sustaining. The low hanging fruit for agile operations is in organizations with expanding technology requirements and increasing challenges from consumerized technology.

They are so agile now, they can't even slow down for version numbers!

That's not strictly true, of course; in fact, their new more rapidly iterative release cycle has resulted in the perennial problem of skyrocketing, complex version numbers, a problem the developers would just as soon hide from the average user, and understandably so. Google has done something similar with Chrome, with little comment.

However, while this has worked out pretty well for Chrome, it bodes ill for Firefox. The rapid release schedule already has corporate IT on edge. It's going to further muddle prospects when troubleshooting has to happen between corporate ops teams, developers, and users in the field. The disparate levels of support in browsers for web applications is already a thorn in the side of developers attempting to use agile to spin out web apps for corporate applications. When you can't even easily tell your user how to determine whether their browser will work with your system or not, there is bound to be a lot of misunderstanding and distrust.

Chrome gets around this in two ways. One, it automatically updates, keeping a pretty fair level of homogeneity in the deployed base. If all else fails, a simple "restart your browser" can generally get the developer and user on the same page. Two, Chrome has done a quite good job of maintaining consistent support of standards and paradigms. Firefox may eventually improve in this respect, but since it's a more freewheeling effort, it also may not. When you start seeing big changes in short release cycles, versioning is going to become pretty important.

Mozilla has been pretty clear that they are not interested in corporate use, and maybe corporate users should start to take the hint and move on.