DevOps and ITIL

Recently I had a few things to say about DevOps. In a nutshell, DevOps is a niche approach to service design and delivery, which won't have much impact in the near future on traditional Operations of core systems. The concept of better integration between Dev and Ops is good, but the cultural issues and most of all the risks speak against it. And the way some people interpret it is downright dangerous. Now I want to zoom in to look at the relationship between DevOps and ITIL.

My e-quaintance Botchagalupe (well he used to speak to me before these posts) pointed me to two ITIL-specific DevOps links, then our subsequent attempt to debate the content on Twitter (like having a boxing match in a phonebooth) led to this post.

In essence, there is a core of thinkers within the DevOps community who understand what IT management is about and are sensible about the use of ITIL within a DevOps context; and there are others with a looser grasp on reality in general and ITSM in particular. They range from the gentle hippies who just want a nicer ITIL, to rabid cowboys who prance about declaring the end of ITIL because DevOps has apparently rendered it irrelevant or inapplicable or outdated. (I hasten to point out that Botchagalupe - John M Willis to his family - is in the thinking camp; his CALMS model of DevOps is great).

This range in views comes through loud and clear in many DevOps-related links when you look at comments or threads.

Ben Rockwood would have us believe "ITIL is kool again" because DevOps is turning on and tuning in to such rad concepts as change control, and the "new ITIL" is a grass-roots driven people's movement rather than "forced from the top down" by "executives" (read: The Man). Yeah whatever dude. In the walled gardens of DevOps this may be revelation, but in amongst the big iron ITIL never got lost.

Ben is right that DevOps is "is currently mostly affecting SMB and startups which have been, for the last 3-4 years, greatly influenced by the webops shops." That about sums up the home range of DevOps, yup.

Actually I shouldn't hang it on Ben. Gen XYZ may not have discovered the realities of running a business yet, but he clearly identifies that DevOps is a cultural movement, not a bunch of cool tech toys. I'm all for that cultural movement (I've advocated closer cooperation for years via Dead Cat Syndrome) - I just don't think we need an agile revolution, fast change, or automated Chefs and Puppets to achieve it in most IT shops.

So I liked Ben's post even if I didn't buy all of it. I liked the comments even more (down to the spam ones - Ben, do some housework).

Then I wandered into the other thread John sent me, a forum discussion. It starts out well with common sense posts but then starts to go downhill. One person said

If I understand ITIL right it means "no ticket - no service".

Clearly you don't, Marcel.

Reading the thread, watch the developers uncover exciting new concepts like ticketing

using a ticketing system with Scrum or Kanban gives my management and peers a lot more visibility into not only the amount of work I am doing but also the exact amount of time it requires. No more underestimating the time or resource requirements. :) ... Not tracking my work through a ticketing system would be a nightmare!

though others were still having trouble grasping the concept

I believe people shy away from ticketing systems because they are used as a heavy abstraction layer. They don't like to open tickets because the request will get lost in a sea of other work, etc.

Others stumbled across change control

I found that the proper enforcement of change control procedures (all changes go through "development" and staging phases, even our own) actually made my concerns a non-issue. Not only did I have to perform the work multiple times, but I sometimes found flaws in the deployment/change plan.

Oh wow, like amazing. This thread reminded me of teenagers debating whether money is a good thing. The naivety and lack of conception of what ITSM is and why we have it is just amazing. In their sheltered little development workshops, it seems some of these guys have no idea what the real world of service delivery is about. They are blissfully (and often willfully) ignorant of the requirements of Sarbanes Oxley, of managing to a budget, of profit and loss, of reputational damage.

I've seen DevOps folk mention the book Visible Ops several times as if it were some sort of holy grail. This makes sense: Visible Ops is a primer for the dysfunctional, an emergency kit for sites with zero process. (Read the cover: "starting ITIL". Must have been a fertile field in the USA a decade ago). If you don't know jack-shit about ITSM then Visible Ops would seem like a masterwork, and ticketing and change control would seem like road-to-Damascus visions.

Perhaps ITIL is an excuse for bureaucratic assholes to just be obstructive because they enjoy it (in which case shoot the messenger not the message) but when I read

I still feel however that ITIL appeals to a certain kind of corporate bureaucrat. We have had ITIL service management "imposed" and it is seen as the holy grail by our central services managers. I have attempted to bring devops and agile practices into the conversation but the suits are not interested.

I still feel that the attitude problem might be on more than one side. This smacks of a hippy-dippy anarchistic resentment of authority and rules which misses the whole point of organisations: to generate value and to protect it.

ITIL is as flexible as the culture that adopts it. I said in comments after the previous DevOps post, holding up worst-case scenarios of bureaucratic change control as a justification for rejecting processes is as bad as my characterisation of dev techs. Change management without Standard Change is inexcusable - if only ITIL made that explicit. And I'm a huge fan of people actually talking to each other... but so is any good manager. Change management will only ever achieve successful cultural acceptance if it minimises pain and maximises efficiency, which is all about Standard Change and easy CAB and all the "agile change".

It may be in years to come that the anti-ops factions fall away from DevOps, and Agile becomes proven to be safe, and deployment and control can be automated in cost effective and low risk manner. That will be a happy day.

Until then i'll go on promoting standard change, operational readiness (dev/ops collaboration), evolutionary process improvement, and most of all cultural change programmes, all within existing ITSM frameworks such as ITIL.


nothing is gospel

I found this a very interesting article. I've worked in a Change, Configuration & Release Management for 15 years. In every organisation i've become frustrated by the divides that exist between development and operational teams.

Development do have a "bung it over the fence" mentality and Operations generally don't have a full view of the SDLC and think the change cycle only starts when something is ready to go into production (despite ITIL v3 introducing life-cycle concepts). Breaking that silo may never happen but making people aware of what goes on "either side of the fence" would really be of benefit to everyone. That's the positive i see of Dev Ops.

Release Management is often a point of contention about where the RM Team should sit. Development teams concentrate on the scoping and planning elements i.e. which CR's from the business and fixes should be bundled together and delivered through the cycle. Operational teams generally aren't aware of this and believe RM is more about the preparing and deployment into production. Any simple IT person reading this can then just say RM is a process across the full SDLC, but do development teams and operational teams accept this?? not from my experience they don't!! same applies to Change, Configuration, Asset, Problem, Incident, Knowledge etc

I quite like ITIL but have always seen it as descriptive rather than proscriptive. The problem arises from the militant operational people who actually carry the little ITIL book around in their back pocket to justify their arguments. Too many have lost the capability to understand its just a framework and often works best when you cherry pick the vital bits that work for your organisation

I quite like agile but again agile itself is only a philosophy hence its descriptive rather than proscriptive. The problem arises from the cowboy development people who carry the Agile Manifesto around in their back pocket to justify their arguments. Too many have lost the capability to understand that "working software over comprehensive documentation" doesn't mean they don't have to provide detail to those that need to look after the software for 95% of its life.

Therein lies the problem, people taking these things like gospel and unable to see the bigger picture. It would be a shame if Dev Ops, which originally aimed at breaking down these ideas, becomes a self fulfilling prophecy and people take the ideals of DevOps too literally!

ITIL : OPS :: CISSP : Security

I know automation has been around for 10+ years. The reality is however, until recently there has not been a critical mass of engaged developers or systems engineers participating in those efforts. And now that there is, that critical mass is innovating in the field like never before. Virtual machines and "cloud" providers are the reason for that critical mass. Now a web startup shop isn't one rack of servers. It's 100 VMs maintained by 5 guys total. And that means that the requirements for management of systems on small and medium scales are changing. More to the point, large deployments are about to change drastically as well. The incentive is there for change in a big way.

ITIL was focused on enterprise deployments, and a procedure that was focused on drawing value from cost-benefit analysis based around an economy of massive scale. That economy does not exist for many of the newer innovators in the field, and ITIL doesn't account for that. More to the point the innovation that is occurring today isn't building on past efforts. And many innovative movements in the operations field today ignore ITIL because the scale at which ITIL methodology becomes relevant ignores the people pushing this new technology.

The result is ITIL is being put to it's first real scaling test. And because ITIL was written in part by bureaucrats and less so by actual operations folks, many of us are pretty much waiting to watch it collapse in on itself. It may survive, but if it's going to, it's going to have to change. I predict there is no functional mechanism for that.

DevOps "culture" will standardize. The question is, will it standardize faster than ITIL? Will closed shops be able to convince a younger generation of kids as well as open source communities to listen to even a fraction of their advice?

History says not a chance, and we'll all be better for it.

it's called service management

It's just possible that what you say is true and ITIL doesn't scale down well. But I think you're wrong. The success of FITS in schools, and the success I've had with ITIL in SMBs, both tell me your wrong. I suspect you're speaking from the prejudices of a perception of ITIL.

Even if you were right about ITIL, that doesn't mean ITSM no longer applies. That's "dot bomb" bubble talk. Everyone needs and does ITSM, whether they call it that or not.

It's academic really because I still don't think DevOps matters in the grand scale of things, just like Cloud doesn't. I'm using Cloud solutions usefully for SMBs right now, and I'm glad I have that option. But I think Gartner are about right: Cloud will account for 3.4% of IT spend in 2015. I can see me using a DevOps solution in some context too, hypothetically. that doesn't mean we are witnessing some revolution that sweeps all aside.

You can puff on about winds of change and a new generation, but it din't work in the 60s and it wont work now. the rules of business are based on reality. the reality is that businesses exist as much to protect assets as to build them. IT has that accountability to the owners. Delivering is about balancing increased value with controlled risk, and that's called service management, sonny-Jim :)

As one well experienced in ITIL in smaller companies (it's a little country I live in) I'm pretty comfortable that ITIL will meet our ITSM needs for many years to come, including in my clients who are cloudifying, and including in those who adopt DevOps and other agile approaches - if they do. You grow your hair and chant in the parks if you want but it won't have much effect in the Establishment.

regarding service management reply

I'll grant your right to disagree, and certainly you make some very good points. However, I feel you need to let go of "cloud" the term. It was never a very good term.

And the reason I say that, is going to be a little involved. So please bear with me.

VMWare just raised their costs considerably. For some of their smaller customers it's something like a 2x raise in already expensive licensing fees. And for many of them, they have no choice but to pay it. At least for now.

The problem for VMWare, and the real coup for open source cloud software such as openstack, is that people are now looking for opensource alternatives to vsphere. And there openstack is waiting for them. An amazon API compatible virtual machine management environment that's got huge open source support and immense development effort under way. And that's just the open source front that I am aware of.

So, for many cloud doesn't mean hosting in the cloud marked internet, as it means using cloud provider technology in place of vmware at home.

And I am starting to see serious people, seriously consider this. And that's just the tip of the iceberg on the give and take in technology here between your younger developers and your systems operations folks.

When I first heard the term DevOps, I thought... "how is that different from systems engineer?" Then I realized it just means "good systems engineer". And yes the term was largely invented and pushed by people who had never seen systems engineers in the wild. So maybe it was ignorant of them. But there is going to be a lot of culture clash in the coming years and it's going to be important to look past the terminology and focus on the technology and what it can and cannot do.

exciting business results

I never focus on technology. I focus on people, culture, business and process. Technology its a servant, a tool. Tech doesn't change the world, what people do with it changes the world. Take QR Codes as an example. Solution looking for a problem. Damp squid. Non event.

So I don't look at the tools, I look at what we are doing with them. I have now heard of openstack, thank-you. Guess how important I think that is. "huge support" eh?

Likewise DevOps. The pioneers are welcome to play with it at someone else's expense. When I begin to see exciting business results i'll take note. And not just a few rigged vendor case studies or demented dispatches from the tech frontline. Real results. Until then I'm not handing dev the keys to Prod and that's final.

I agree about Cloud terminology. I dislike "private cloud": it is just virtualisation and an abuse of the term. Cloud is "out there somewhere and I don't much care where" (other than sovereignty issues). SaaS, IaaS and PaaS are proving useful to me in business for my clients, so I take them seriously now.

Until then new developments are just toys for the boys, a distraction to the other 95% of us doing a real job running the business.

Damp squid

Sorry, couldn't resist this when I saw your reference to it.

A humorous interjection into a serious topic!


Ignore the Technology

Ignoring the technology and focusing on the policy / culture is a sure fire recipe for disaster. And anyone with any experience at all in the Industry will be glad to inform you of that.

You talk about OpenStack like it's unproven technology. And yet Opsware, and vsphere are both heading into the same convergence where it resides. Judge it as unproven as a rival, by all means. But this isn't a solution without a problem. It's anything but.

As vsphere closes off their users as well as their strategic partners from under the hood access to their hypervisor nodes, they cause stagnation in their own products. None of the mature UNIX implementations have stood up to Linux. Not because Linux was better, it certainly wasn't. In many cases it still isn't. But the culture moved on. And the culture is moving on now. ITIL is being ignored by that very same culture, thus your posts. So by all means pay attention to the culture. Divine the roots of the issues that are causing these cultural shifts. Figure out whether or not a technology is important because of that.

Software like openstack is important because of the cultural shifts occurring today. Not because it's better than vsphere or even capable of addressing a 10th of the capabilities of Opsware. The reason it's important is because there is a growing open source community. And that in my opinion is the ultimate measure in success for a technology in our field. And sure you can ignore it for a little while longer, because it's not on your radar yet. But, you shouldn't for the very same reasons you care about ITIL. When things develop in an environment very different from your own they will grow in fundamentally different ways and when it finally does wander onto your radar, it's not going to be the technology that changes to meet your policy. And teaching policy makers with blinders on that particular point is usually a lesson learned in blood.

DevOps is Nothing More Than Marketing Hype

Hi Rob,

DevOps, to those that have been around long enough, is nothing more than a marketing label that has been used in attempt to rebrand and Systems Development Life Cycle (SDLC). The reality is that you can come up with as many different marketing terms or cool acronyms as you like, however, in the end the SDLC "never" goes away. Experienced and mature enterprises always have a solid SDLC in place and they proactively manage and constantly improve their SDLC and all aspects of it, as an Industrial Engineer would work to improve all aspects of a firm's manufacturing solutions (which is exactly what SDLC represents to IT... A Systems Manufacturing Solution). The fact is that SDLC the pipeline must exist to deliver and will always exist to deliver.

"DevOps" is a term that has been fabricated by marketers to shorten the representation of the entire SLDC, as if shortening the name will shorten the amount of work that needs to be performed, by trying to push a philosophy that tries to segment handling of the pipeline in a way that almost never works, in the long run. Experienced IT professionals know the full SDLC can never go away. Naive IT professionals buy into IT, as if it's the next savior. Remember "Agile" and how it would become the savior? Remember "Extreme Programming" and how it would become the savior? Remember "Software-as-a-Service?" Remember "Web 2.0?" Remember "Web 3.0?" The marketing machine is never ending and will continue to pump out new marketing hype.

The fact is that there will always be someone who comes up with a new marketing spin on pieces of the SDLC. It's the true professionals that can see past the marketing nonsense and who realize that your SDLC is your pipeline and it will never go away. These professionals work on clearly defining their SDLC pipeline and they work to constantly improve it, because to improve the pipeline means to improve delivery and operations, both, within any phase of the SDLC and across all phases of the SDLC.

The above being said about DevOps, ITIL deserves its part in the conversation, as well. ITIL focuses on certain areas of the SDLC and, in having been designed from the tail end of the SDLC pipeline, has been criticized for having ignored and/or forgotten critical linkages to upstream SDLC activities. The simple example revolves around the appearance that ITIL presents itself as being "Production Environment-centric," seemingly ignoring all of the critical work that is performed in upstream phases and environments of an SDLC. For example, how many intelligent and experienced IT professionals truly believes that you should not perform Incident Management, Problem Management, Change Management and Configuration Management activities (and track it all) in all of the environments that precede your Production environment? Not to do so spells doom for most enterprises, yet it appears that ITIL completely ignores most of it (or at very least diminishes all of its importance).

The truth is that almost all IT idealisms have good and bad associated with them. Smart and experienced professionals don't get hung up on the marketing. They focus on the fundamentals and perform the work that is obvious and necessary to be successful, regardless of any marketing hype. Intelligent and experienced IT professionals also make sure they're well-informed by learning about as many of these philosophies as possible, taking them with a grain of salt, and harvesting the few ideas that are good from them.

Anyhow, I hope this adds value.

My Best,


Frank Guerino, Chairman
The International Foundation for Information Technology (IF4IT)

Devops is not about the marketing

Frank, all,

I beg to differ. I've had the luck of being there from the beginning of devops; and no marketing scheme is behind it. It's a community driven effort not vendor driven. Of course there are vendors trying to re-brand their tools, but they are not very well appreciated for that.

Sure, it's about the SDLC, but in a lot of the implementations it feels like a throw it over the wall mentality as people don't feel responsible for the whole cycle. Using cross-silo collaboration we hope to break that. The tools will support that by automating some of the flow, but the main point is people collaborating. The whole delivery cycle is too complex to be handled by one group at the time.

DevOps is Not New

Hi Patrick,

When you write that you've "had the luck of being there from the beginning of DevOps," do you mean:

1) The beginning of such best practices, decades ago, long before they were coined with marketing terms such as "DevOps," which started to appear only in the 2008/2009 time period?


2) The beginning of the coined and used marketing term "DevOps" to describe best practices that have been followed by many IT professionals (but not by enough IT professionals) for multiple decades, long before such coined terms existed?

My Best,

Frank Guerino, Chairman
The International Foundation for Information Technology (IF4IT)

origin of devops


I am responsible (for good and bad)for the term devops. It was a result of the first devopsdays in Ghent inspired by a lot of ongoing ideas circulating around it. There were no companies, no marketing involved then . I never intended it to be a phrase. My first idea was "Agile System Administration" but I found it too restrictive, and being involved already in the agile dev community (but coming from an ops background) , I choose that term. 55 people with like minded ideas got together through a mailinglist and twitter. Again , no marketing here. A blogpost put the term on the internet and from there it took off in the practioners world.

Only recently this year, the term has been increasingly picked up by marketing folks/analysts from big companies. Still when you go to devopsdays conference, I'm delighted to say it's still a community of practitioners and people eager to solve/help in the problem space from the SDLC. It's people fed up with the traditional silos and restrictions created by that. Still I don't mind if this brings the problem space closer to the audience.

The marketing is something you can't stop and seeing big companies wheel their marketing machines is scary for me. I'm willing to believe that companies can help this space, but the way I see it, the core will not get owned by a company. Fighting buzz machines is hard. But I hope we keep up.

I make no claim that I've invented any of the ideas, there are people much smarter than me who contributed to it's space. Still I do my best to promote, gather/channel/synthesize ideas so others can learn from it.

More on the origins of the word devops, has been recorded in the postcast .


Hi Patrick,

It's a pleasure to meet you, even if only in virtual space.

I get what you're doing and I'm all for it. The industry needs as many people as possible who work, genuinely, for its constant improvement.

I'm also very familiar with what marketing machines do to try and keep their people and their enterprises "relevant" and different. I've watched them overwhelm and overrun many well-intentioned efforts. My favorite is, first watching the marketers redefine the original definitions and intent of a topic space, like "Web 2.0," and then watching less than well informed people in the industry start to quote the marketers, destroying the original intent and definitions, even further.

I hope you fare better at keeping it all under control.

My Best,


Frank Guerino, Chairman
The International Foundation for Information Technology (IF4IT)

DevOps is new and helpful


I've got enough white in my beard to be as cynical as anyone else. But my reading of DevOps is that it is a genuinely new contribution to the profession, not just same old same old.

First, we all know that there are no silver bullets. Fred Brooks laid out the reasoning there better than anyone else. If we look at any new "movement" in either SDLC or ITSM as bounded by that constraint, we can manage our expectations. There will be no order of magnitude improvements in the SDLC.

Briefly, what is new about DevOps? Read Humble and Farley's Continuous Delivery and you will not find marketing. Instead you will find a detailed technical treatise on how to accelerate the delivery of new functionality so that change windows can become systematically smaller. How what were once high-risk changes can become lower risk; how changes requiring approval can become standard changes. (They may not be using that terminology, but those are the implications I drew on reading their work.)

Beyond the specific, useful practices that reportedly have enabled some companies like Netflix to release multiple times in a day, there is a specific philosophical innovation that I only started to fully appreciate from Jez's post above:

To reduce change risk, introduce more change.

Essentially, it's a form of practice makes perfect. But if you think about it, it complicates the mental model many of use have that change and stability are purely oppositional forces. To have stability, change more often. Get good at changing. Automate as much of it as you possibly can. Including rollback in nontrivial cases (e.g. major database refactorings). It's this kind of rich, practical, specific guidance emerging from the devops community that I think is of great value. Is it a silver bullet? Of course not. But like the trends you mention above, it is becoming part of the landscape. I for one find it helpful. It's not just hype.

Charles T. Betz

DevOps... Not new concepts

Hi Charles,

Let's start with your request that I read "Humble and Farley's "Continuous Delivery." I have. I am also very familier with Martin Fowler's "Continuous Integration." First, let me say that I love their material. They documented what experienced software developers have understood to be conventional industry best practices for Software Development, Delivery and Support. Second, let me make this very clear... Nothing in any of these books is "new" material to anyone who is very experienced at software development and who has been intimately involved with the design, development, deployment and support of complex and distributed software solutions, over the last few decades. The authors simply did a great job of capturing many of the concepts and titling them, in their books. But, if you are pitching to the public that these concepts are new and innovative, you clearly misrepresenting the material that has been a part of good Software Development for decades. I worked with companies that lived, breathed and ate such concepts as the core of their software operations, as early as the late 1980s and early 1990s, long before anyone put labels like "Continuous Integration," "Continuous Delivery," and "DevOps" on what, for decades, have simply been considered "the right things to do with respect to software development." The reality is that with the Dot.Com revolution came the hiring of so many people that truly were under-qualified to work in IT. If you could say "Technology" and fog a mirror, you were pretty much hired by anyone. Remember the days when HTML coders thought they were true software developers? (I say with tongue in cheek.) It was during the Dot.Com period that so many companies got sloppy and started to accept cutting corners on Software Development.

People like Fowler, Humble and Farley have not given us anything new. They've documented what is old. To those people that were never brought up with such best practices engraved in their professional being, these things look new and cool. To people who have been doing such work for decades, this is old hat.

Here is a very small list of the many companies that were performing Continuous Integration, Continuous Delivery, and DevOps long before anyone labeled them with such marketing titles...

  • Raytheon
  • GTE (Government Systems Division)
  • Prime
  • DEC
  • Racal Redac
  • IKOS Systems
  • Cadence
  • Mentor Graphics
  • SilcSyn
  • Stratus
  • Divisions of Morgan Stanley Dean Witter
  • Divisions of Merrill Lynch
  • Divisions of BlackRock
  • etc.

I can go on and on and, if you really dig in, you'll find that thousands of companies were doing so by as early as the mid-1990s, long before anyone put fancy marketing titles on such best practices. I was a part of some of these companies and a few of them were performing 10 - 20 releases a day, let alone 10 - 20 a week, which is being pitched as some major accomplishment in this more modern age. The rule is simple... Automate everything and eliminate human labor from as much as the process as possible, because human labor is slower, less predictable, littered with more errors, more expensive, and so on.

The concepts documented by Fowler, Humble and Farley are not new, Charles, nor would any experienced Software Developers ever pitch them as new and innovative. It's only the "titles" for these concepts that are new... Titles are the results of modern marketing to sell books, in this case. Back in my day, they simply called these concepts by the boring title: "The Right Things You Should Do for Good Software Development." If anyone thinks that things like automating their SDLC (both within phases and across phases) is new, then they really should re-evaluate whether or not they belong in Software Development. The SDLC has existed for decades and smart enterprises and IT professionals have known for decades that the secret to rapid, stable, low-cost, high-frequency and highly repeatable delivery is to automate, automate and automate your SDLC.

People like Fowler, Humble and Farley (God bless them for doing so) have only documented, quite recently, what has been known to be conventional industry wisdom for decades. Anyone who has been around long enough knows this and does not pitch such concepts as new and innovative. It's more like getting back to basics after a decade of very sloppy IT, which I personally believe is due to the Dot.Com period causing the hiring of so many under-qualified people into the IT field. The problem is that most people in IT, most of which who are not well trained and experienced Software Designers and Developers, forget that the very existence of IT is all about Software and Automation of handling Data, Information and Workflow, so they cut corners thinking that they can still get good results by doing less. We all know how well that works.

Here's a simple test... Have IT people describe the differences between Delivery and Deployment to you and see how many truly understand the differences. The good ones do.

In summary, Continuous Integration, Continuous Delivery, and DevOps are not new concepts. They're just new labels for what has existed for decades.

My Best,


Frank Guerino, Chairman
The International Foundation for Information Technology (IF4IT)

Proto-devops movement?


Your statements are at such variance with both my experience and so many stories I hear I don't know what to say.

I spent time at a number of Fortune 500 shops as well as at Accenture, as an architect and developer. I did come in as part of the dot-com generation. My hands-on experience of those deployment processes was significant under-automation (deployment approaches often bespoke by application, and too often nothing more than a sysadmin's workstation with two FTP sessions open), poor dev/ops handoffs, painful rollbacks, 1-2 week change windows, and a lot of nail-biting around release and change and a corresponding desire to over-analyze and delay it.

It appears you were fortunate in your career path, working in the most elite shops of the era. At least, I suspect that those deployment pipelines at the companies you reference required significant internal effort, as compared to the commercial and open source tools now available.

I don't believe I have seen discussion of the proto-devops trends you describe in the software engineering literature of the time (Yourdon & the rest), which surprises me a little if these practices were as common and accepted as you imply. So, references much appreciated, as I am something of an IT historian. Perhaps this was an unfortunately undocumented movement, falling in the cracks and therefore now being re-invented to some extent.

I'd also encourage you to consider writing up your experiences in proto-devops in the '80s and '90s; I'm sure the industry would benefit from specific case discussions.


Charles T. Betz

PS Was this mainly mainframe, or early distributed?

DevOps implementation

PS I took a stab at a systems architecture for a mature DevOps/Release Management use case here.

Also, Jez's comment on change vs. stability was on another thread, here.

Charles T. Betz

Syndicate content