Principles

The thought that the CIO role and the state of the IT organization as a stand-alone entity in the modern corporation are due for a dramatic revision soon has not exactly hit the mainstream yet, but it's on the way. Since late 2007, there have been indications that the CIO is losing what little respect and autonomy the role ever had, and the forces leading to that diminution and the corresponding fading of the IT department as a whole in the role of corporate technology provider.

The latest missive in this vein comes from the Corporate Executive Board (CEB) in their whitepaper "The Future of Corporate IT." (PDF) The CEB are projecting a 75% drop in IT headcount in the next five years in many corporations, and with the current paradigm of "big headcount = big honcho" the equation does not favor the head of such a diminished department.

CIOs seem bound to make this worse than it has to be by stalling, digging in their heels on traditional initiatives, and working to preserve their headcount and budget even in the face of solutions that could both improve their efficiency and reduce their expenses at the same time. This may work for a while--I certainly think that the 75% reduction in five year prediction is aggressive considering the corporate infighting capabilities many IT organizations have developed--but when the time comes, it's going to be a harder and more permanent fall from grace than is really necessary. Continue reading "Agile Operations and the CIO" »

One of the ancient and original objections to implementing agile was the predictable "But if we release more frequently, we won't have time to make sure we're not releasing crap!" This is probably a pretty tired argument in the ears of the agile development community, but it's starting to come out again now that agile is moving into the operations sphere.

Joe McKendrick at ZDNet is the latest to register this objection in his post "Opinion: SOA and Agile may short-change application quality." In it, he notes that "One of the concerns about automation is that in many cases, it just makes a crappy business process a much faster crappy business process" and wonders if service-oriented architectures that are pushed out with agile methods are putting the business at risk by exposing it to poorly designed processes. The solution, Joe says, is to make sure that "Application quality needs to be addressed as early in the process as possible."

This is a fine sentiment, but of course it's essentially describing the paradigm that agile is largely a reaction to: the waterfall model. Plan everything out, in detail, implement slowly and completely, deploy only after you are sure you have all the kinks worked out. All of which are great ideas... in theory. In practice, in information technology, they turn out to not always work so well, for a variety of reasons that have been well-explored elsewhere.

While the worries that McKendrick has are very real, there are also a host of concepts in the agile philosophy designed to address them. Increased communication, rigorous testing and automation designed prior to coding, minimalist and modular changes that don't necessarily implicate other parts of the system even if they do contain errors... these factors and others are specifically designed to address the risks of going faster.

The unspoken assumption remains, however, that slower and more methodical is less risky. If we can acknowledge that faster releases carry a certain risk, we should also be honest enough to acknowledge that slower has never really proven to carry any less risk. Feel free to consult the IT project failure rate study of your choosing at this point. In fact, waterfall has always carried a tremendous risk, and it's a risk that agile addresses directly precisely because it is faster: the sunk cost problem.

More methodical waterfall approaches have not proven any better at detecting and eliminating process errors of the sort that Joe fears. What they have done, however, is ensured that those process errors in many cases have become deeply and expensively embedded in systems before being detected. The cost of resolving such failures is enormous. While agile methodologies may not do any better at finding those problems ahead of deployment, what they can guarantee is that you will find out about them in production much sooner, and have an opportunity to address them more quickly and at less cost.

There is a sort of circular logic to these objections that is insidious and will likely continue to bubble up for years. Agile is itself a rebuttal to the sort of cautionary approach that Joe proposes, but it's clear that the point has not penetrated past the sort of intuitive, but incorrect, surface logic that obviously going slowly and planning ahead will lead to better results than moving quickly and not planning in detail. That's such an obvious position that it's difficult to even force people to justify it. But forcing them to confront the numbers and the complexity of technology may be the only way to move past this debate.

A recent survey by Egnyte reveals that half of respondents regularly use smartphones to conduct business, and that 13% use them with greater frequency than they do their computers. Google Europe executive John Herlihy says that company believes that within three years, most users' primary interaction with computers will be through mobile devices and that "...desktops will be irrelevant." Herlihy points out that in Japan, already most research is conducted on smartphones rather than PCs.

Of course, these developments aren't news to CIOs or anyone else responsible for meeting the needs of an increasingly mobile workforce, but it is a solid indicator that the trend will continue. It's become fashionable in certain circles to minimize the impact of cloud computing, to deny the death of the desktop, and to claim you can't do anything really significant on your smartphone, but these are all the same people that would have told you that there were plenty of lifeboats on the Titanic and anyway, it certainly wasn't going to sink very quickly. While technically they generally have a point, they are missing the forest for the trees; mobile devices are good enough for a lot of people, and those people will use whatever is most convenient and that they are most comfortable with in order to do what they need to get done. That universal truth has ever fueled the progress of industry and there's no reason to suppose it is no longer the case. Moreover, these trends are reinforcing one another; mobile devices don't have the heft or storage capacity to accomplish internally what a desktop can (and the same is true of netbooks), so users who want to get things done on them pretty much have to use cloud-based solutions. Once you are using them on your phone, it's easier to be using them on your desktop or laptop too... everything is in one place.

The challenge to the IT department in this scenario is to provision and support users with these devices and solutions. This is a far different prospect than traditional IT provisioning and support, and many IT departments are having trouble keeping up. It's not the first time IT has had trouble staying on the same plane as users when new technologies emerge, but this time, the devices and the online solutions are sufficiently cheap that those users don't need the IT department to implement them. While IT has held the keys to the kingdom for many years, there is an increasing chance that the IT department will simply become irrelevant as users bypass it for easier, cheapers solutions. As this Wall Street Journal article outlines, that day is coming.

Indeed, the Journal article should be mandatory reading for today's CIO or IT manager, as should an older post by Wired editor Chris Anderson, "Who Needs a CIO?" Both provide a good perspective on what it is your users are thinking these days, and what they see as their options. Ignore, if you will, the things that the articles miss or flat-out get wrong about the role and function of your IT department; focus on those things that the articles get right: many of your services are cumbersome, inferior, and more expensive than widely available, easily-adopted alternatives.

Ignore, too, the fact that your services have to be more expensive and cumbersome in this context. No one expects you to have the economies of scale of Google, or the burning motivation of a small start-up development team who are working on dreams and promises of an equity stake; you're going to be slower and more expensive when you try to deliver the same services, no question.

Your alternative, then, is to get out of the business of offering those services. And this is where Agile Operations comes in, because there are still services, core services, that you must deliver. Google isn't going to run your ERP system, not yet, anyway. You have to be flexible and learn to integrate public and private platforms. Continue reading "As mobile devices proliferate, agility gains..." »

DevOps and Agile Operations are often mentioned in the same breath these days when anyone is discussing the application of agile or lean principles to IT operations rather than software development, leading one to wonder why all the pundits don't just pick a term and stick with it for once. I think the reason commentators tend to use both though is that although they are closely related, there are in fact differences between the two. I think of them as two slightly different perspectives on what is basically the same school of thought, that being the introduction of agile methodologies to the system administration and operations side of the IT shop.

The basic school of thought, I don't think I am mistaken in saying, is that agile principles of the sorts that have been adopted successfully in the software development community can also be applied, with some modification, to IT operations management.

Agile Operations basically stops there (and grows out of more diverse roots, besides). The focus is on identifying agile practices and principles that can be applied to operations, irrespective of where the software and hardware involved is coming from or how it is developed. I see Agile Operations as being IT-centric, largely ignoring the question of cooperating with development, and including approaches to deployment only as ancillary aspects of the overall challenge of running an agile IT department.

I think of DevOps as primarily addressing the concerns and difficulties of developers, and particularly of those in larger organizations with considerable custom internal software, who have become frustrated at the inability of operations to keep up with the faster pace and somewhat increased requirements for communication that their agile development practices demand. That's obviously the motivation offered by many proponents. More rare are those who disconnect the two and describe it only as the application of agile development principles to operations. There are certainly ops folks who are a part of the movement, but on the whole most of them seem to also have a foot in the development world; not surprisingly, many seem to be involved with website operations, an area that has always suffered from the friction between the dev and ops worlds. If a "webmaster," that poor, abandoned title describing a role that nonetheless has never really disappeared, is not an amalgamation of the developer and the administrator, then I don't know what is. DevOps is a natural evolution for anyone in such a position.

The DevOpsday website reinforces this perspective, inviting "developer(s) with a interest for system administration, or a sysadmin(s) interested in development..." to participate, leaving out sysadmins who really just want to run their own systems more efficiently.

Personally, I don't find any real issues with this overlap. Not all that DevOps can offer will apply to IT department operations in environments where interaction with developers is not a regular feature... and I think this is an increasing number of departments as SaaS and cloud-based, targeted services become more viable options for off-the-shelf procurement of software and services. At the meta-level of IT management, if you are going to be true to the principle of Simplicity, then your first choice for solutions is probably going to be fast, easily adopted off-the-shelf products of that sort rather than specifically (and often expensively!) custom developed software. In smaller IT shops, which is most of them, in-house development has never been a significant or reliable resource and outsourced development has often been untenable and interactions with outside developers not necessarily amenable to agile practices. None of that prevents any sysadmin or IT manager from taking from DevOps what works for them, and such an approach has much to recommend it since many of the more practical agile solutions for ops are coming from DevOps practitioners right now.

James Turnbull's recent treatise "What Devops means to me" is an excellent a representation of what DevOps is about and what issues it seeks to address as you will hope to find on the net.

(Aside: I find it interesting that the four quadrants Turnbull identifies as representing DevOps are roughly congruent to the four principles of Agile Operations; both include Simplicity and Process, and I find his Relationships roughly analogous to People, and Continuous Improvement to Communication)

DevOps seeks to address the epic and historic gulf between developers, many of whom have been moving toward agile methodologies for some time now, and operations staff, a more conservative bunch who are often caught out and feeling put upon by the rapid changes introduced by agile development. The realization that changing the development side of the equation without addressing the equally important deployment side (the realm of operations) was only changing where the roadblocks were at in between coders and customers led devs to gently lead ops in a similar direction. But as Turnbull says,

DevOps is also more than just software deployment – it’s a whole new way of thinking about cooperation and coordination between the people who make the software and the people who run it. Areas like automation, monitoring, capacity planning & performance, backup & recovery, security, networking and provisioning can all benefit from using a DevOps model to enhance the nature and quality of interactions between development and operations teams.

In other words, it started to become obvious that not only could the deployment of software benefit from a continuation of agile practices after the development cycle, but that ongoing operations could as well. This is where Agile Operations picks up on the thread.

In my mind, Agile Operations deals almost wholly with the people who run the software and not at all with those who make it. In environments where it is possible to cooperate and coordinate with developers, then of course doing so is an excellent idea. But many IT departments don't have, and never will have, that option; their developers are, for all practical purposes, Microsoft, and have you ever tried to cooperate and coordinate with Microsoft? Agile Operations recognizes that most IT departments have little say in the development side of the equation, and that the focus of their operations is not only independent of the development cycle, but in fact attempts to consciously isolate its effects on operations.

AO also looks at more than simply transferring Agile Development (AD) principles to operations; the principles are more deeply rooted and come as much from lean manufacturing concepts as AD concepts (although those are, in and of themselves, closely related). This level of focus is more relevant to the holistic management of the IT department, taking in procurement, support, and service in addition to the still important, but less central, issue of development integration and deployment.

I think both approaches are valid and valuable, and I'll certainly be following, commenting on, and participating in DevOps discussions, but I'll also continue to keep Agile Operations distinct from DevOps, and oriented primarily at the IT support and service management organizations.

Just a quick note; the Principles pages of the site have been revised and updated. The principles have been narrowed down to four: Simplicity, Communication, Process, People. Each of those has a page with a brief description of what it means and how it interlocks with the others to form the core of the Agile IT operation. Expect more expansion on the topics, and illustrative examples, in the near future!

A couple of links for you today; I've been noticing AO spring up more and more frequently both explicitly and conceptually in various industry blogs but I think this is the first time I've heard it mentioned directly in a podcast. Israel Gat, Agile Development guru from the Cutter Consortium, discusses it in the context of system administration in a discussion with Michael Cote from Redmonk. Cote has the podcast and his thoughts on it posted here; Dr. Gat's corresponding blog entry can be found here.

It's interesting that the focus of the conversation is on cloud computing technologies as an enabler for Agile principles in the operations side of the house. That's certainly true but I have always thought about it the other way around... it seems to me that cloud technology is the result of agile and lean concepts being applied (not always consciously, certainly) to operational needs. I'm not sure if coming at it the other way is good, bad, or makes no difference to the implementer.

Agile development is certainly present in cloud technology development, and its influences can be seen in the deployment and release concepts popularized in cloud and SaaS services. The fact that a piece of software has been developed by agile processes doesn't necessarily make the operation of that software agile; but cloud and SaaS service operations are certainly among the most widely seen examples of agile-like operations. Rapid, iterative deployment, pushing power out to the users, and an emphasis on the processes rather than the specific output of the services, are all hallmarks of what I consider to be agile operations, and they are all exhibited by most cutting edge cloud and SaaS providers.

Another excellent point raised in the podcast is the extent to which these features differentiate cloud computing from centralized mainframe computing. The similarities are still striking and I doubt that people are going to stop comparing the two. The new, however, is not simply a repetition of the old, and while the computer industry may indeed by cyclical, these critical differences should give pause to those who are eager to consign a new concept which superficially resembles an older one into the same bin. Mainframe computing was efficient and that efficiency was necessary for computing to get off the ground when computers were new and expensive. Cloud computing is efficient for all the same reasons, but it isn't limited by the same factors that mainframes were. Thirty years of desktop and software advancement isn't going to go back in the box; blending some of the concepts of individual control and manipulation inherent in those movements with the efficiency of the mainframe model is powerful indeed.

Or so I say with respect to Joe McKendrick's Ten Half-Baked Ideas on SOA-Cloud Convergence.

SOA and cloud-based services are both important concepts for the application of agile techniques to IT operations. Both offer flexibility and efficiency, the watchwords of our movement.

Although each technology has its own adherents and proponents, who are not always interested in mixing and matching, to the independent observer it's long been clear that both are variations on a central theme, that of utility computing. Utility computing, the packaging of deliverable services in a black-box-like, discretely delivered service, is popularly conceived of in terms of external providers, but many IT departments already operate certain services in a utility-like manner internally (and have done so for years; in the mainframe era, billing by computing hour was closer to the norm than the more free-wheeling allocation of resources which accompanied the rise of the PC). SOA accentuates this means of delivery. As McKendrick puts it, "SOA could be sold as an internal cloud that provides online services inside the walls of the enterprise."

Not only is that true, but a properly constructed SOA needn't remain solely within those walls, nor do those services need to entirely originate there. Doing SOA right means having the option to bring in cloud solutions with less expense and disruption... or to switch between cloud providers just as easily. The flexibility inherent in addressing systems architecture from the service-oriented perspective pays dividends across the board... and it is a very Agile way of delivering IT services.

McKendrick's full list of ideas can be found in his article, but there are a few worth seizing on when considering rolling out or improving AO in your IT department.

"The new economy emerging from the downturn will drive SOA, WOA, and cloud computing in new directions — as vehicles for new business growth."

This is a linchpin in many of my arguments for implementing AO, and doing so now. A tectonic shift is occuring in information technology now, one which will result in a rift between the two traditional functions of the IT department; infrastructure and operations, and strategy and development. To remain useful and relevant to both functions, IT managers and CIOs will have to seize the initiative in adopting these new technologies and manage the transition with enough stability to maintain service levels, but with enough flexibility to serve the business to the extent of its demands. This, in a nutshell, is the promise of Agile Operations; but to convince the CIO, IT manager, and other responsible parties of the necessity to move in this direction, it's imperative to understand and accept McKendrick's point.

"The rise of the “Loosely Coupled Business,” built on brokered or aggregated services."

"More business users will be building their own applications. More IT people will be involved in the business."

These ideas are closely related and speak to a decoupling of traditional IT delivery functions and a need to restructure IT to become more business-oriented and more deeply involved with day-to-day business operations. This has never been a strong point of the traditional IT department, but those which do not adopt it now court irrelevance. The ability to participate in less structured organizations will be a key to survival.

"SOA, WOA and cloud will increase outsourcing, but outsourcing will take a new form — fewer mega-deals, more micro-outsourcing."

The heart of this idea actually is less important with regard to structuring outsourcing deals, as it is to structuring one's internal architecture to allow such small-scale outsourcing. Whether the function is actually outsourced or not is relevant only from an economic standpoint; the real point is that the modularity of service delivery will allow internal or external fulfillment in numerous combinations, of which the most economically advantageous can be chosen at will. The business will not be restricted to a fulfillment mechanism which includes less optimal components, as is often the case when monolithic delivery stands. Micro-fulfillment, whether provided internally or externally, allows rapid restructuring as it becomes advantageous. The smaller outsourcing deals mean less stress, less commitment, and a wider array of vendors capable of meeting the company's needs.

McKendrick says that he is offering this ideas for the year ahead and beyond, but it strikes me that the year ahead--or the one we're already in, for that matter--is the critical one. Adoption of these principles in the IT department must occur ahead of their adoption by the business... and businesses are already looking at aggressive and innovative options for restructuring. Otherwise, the IT department, already frequently tainted by bad blood, will find itself marginalized right out of existence.