Model-Driven Automation
On top of raw system artifacts (such as packages and configuration files), rPath layers several unique system modeling concepts. Here’s how two of the most important concepts at rPath—blueprints and manifests—work together to deliver Read more
Eight Truths of Enterprise IT
Truth is a funny word. It smacks of empirical fact and righteousness.
But truth is not that. It’s subjective—a cocktail of knowledge, experience, context and bias. I admit that an attempt to generalize “truths” about a topic as broad and complex as IT has the potential to come across as presumptuous … or worse!
But, if you look closely, complexity often betrays patterns. For me, these patterns tell a story that gets—if not to the ultimate kernel—in close proximity to the truth.
So, what are these truths of enterprise IT?
From my perspective, I see eight:
1. Drift happens—complex software systems are rarely consistent or what they ought to be. They drift and morph in definition over time as patches are applied, updates are made and IT personnel tunes, tweaks and fiddles. These changes are typically untracked and IT rarely knows precisely what is running. When they’re initially deployed, systems are opaque. Over time, they’re complete mysteries.
2. Change hurts—IT fears and avoids change because of a Law of Unintended Consequences that hangs over the data center. At the heart of this law is the reality that deployed systems and their dependencies are poorly described and documented. When change happens, stuff breaks. This is why, on the topic of change, IT tends to channel Ross Perot: “If it ain’t broke, don’t fix it.”
3. IT abhors a vacuum—As the cost of computing drops, workload demand increases. This is the force behind VM sprawl and the attendant growth in management costs. Like nature, IT abhors a vacuum. When space is made available, it’s quickly filled in. (Perot may call this “a giant sucking sound”).
4. Demand follows the path of least resistance—Like it or not, enterprise IT competes with a marketplace of alternatives. When alternatives offer comparatively better options in price, performance and availability, workloads will follow the path of least resistance. Public cloud is a perfect example of this phenomenon at work: IT organizations that fail to transform will surely watch in vain as workloads, following the path of least resistance, escape to the cloud.
5. Dependencies grow geometrically—Software is more diverse than ever, comprising an unthinkable array of custom, commercial and open source options. This means that developers have more resources to ply their craft and IT is utterly mired by complex, interdependent and constantly changing systems. It’s made worse by the ongoing abstraction of IT, from managing discrete single-use piece parts to the composition of reusable services. The network of interdependency is massive and—much of the time—poorly understood.
6. So does scale—Each subsequent architectural advancement leads to an increase in scale. Scale exploded as mainframe gave way to client-server and client-server gave way to web. Today, we’re seeing x86 architectures, virtualization and cloud are all driving growth in the volume of systems that need to be managed.
7. Proportionally, budgets will always contract—Operating budgets cannot keep pace with growth in IT scale, so even when the top-line budget is growing, the budget per managed system is always contracting. IT will always be forced to do more with less—forced to find new ways to change the economics of scale.
8. Complexity is the mother of reinvention—When IT complexity reaches the frontier of existing tools and processes, IT must reinvent. Containing complexity is like holding back a tide. The only way forward is through reinvention, embracing new tools and approaches for dealing with IT complexity at scale.
So that’s it—eight IT truths as I see them. What truths do you see?
The Second Law of IT Automation
In the early days of team software development, everyone worked on a common directory of source code—and struggled to avoid conflicting changes and premature feature release. This became completely unworkable as software became more complex and teams became bigger. Read more
Is DevOps Subversive?
If you follow DevOps, you’re probably familiar with the sentiment that this burgeoning movement could have mildly subversive motives.
As a solution to the dev/ops bottleneck, one advocate recently proposed:
“Hire wicked smart people and give them all access to root.”
While this may be a rally cry for radicals and revolutionaries, it does tend to trivialize roles and processes in IT and probably doesn’t engender trust with the mainstream—nor does it correct the perception that DevOps may breed a cowboy culture.
To be clear, I don’t at all believe that DevOps is meant to be subversive—in fact, I believe deeply in the premise of DevOps and see it as a necessary evolution for IT. But I can certainly see how some are led to fear what it stands for.
To some, DevOps seems to minimize principles of governance, repeatability, separation of duties and other good practices of mature IT organizations. To these folks, DevOps seems like the oil to ITIL’s water.
I came across a post by John Vincent that does a masterful job of describing why DevOps—for all its goodness—collides headlong with certain enterprise realities.
Advocates for DevOps often unwittingly fuel the perception that this worthy movement is one giant end run around traditional IT operations. While I’m certain this is not the intent, we’re all familiar with the maxim that perception is reality.
Like many anti-establishment movements:
DevOps is super-smart—DevOps focuses on the contributions of the most gifted few to make IT run—the script wranglers, the mavericks and artisans. It often minimizes the fact that genius is neither scalable nor repeatable.
DevOps is provocative—DevOps advocacy sometimes pokes its collective finger in the eye of the IT establishment, galvanizing the support of the few who “get it,” but perhaps alienating those who don’t—those who represent the IT majority.
Of course, smart and provocative are not bad things—in fact, they’re essential to any movement for change (can you imagine the American Revolution led by passive everymen without conviction and a strong point of view?).
The secret is using smart and provocative as a bridge instead of a wedge.
Today, DevOps is gaining traction in the world of web ops, but hasn’t found its home in traditional enterprise IT. At the risk of some heckling, I’ll go out on a limb and suggest that, for some DevOps advocates, this fact is worn as a badge of honor: Mainstream attention means that DevOps has jumped the shark.
The principles of DevOps are undoubtedly right on: Compounding scale, accelerating change and contracting budgets are forcing IT to the brink. At the same time, public cloud is emerging as a model for the future of IT: self-service, automated and elastic. The universally accepted truth is that IT is under pressure to change. Is DevOps at the heart of this change? I certainly hope so.
But the question remains: Will the revolution take hold or will it become a footnote in history—a fringe movement that fails to connect with the mainstream?
In my view, the future of DevOps depends upon cooperation with mainstream IT—perhaps DevOps thought leaders collaborating with (gasp!) ITIL thought leaders.
Maybe there’s a way to turn oil and water into peanut butter and chocolate?
I think it’s worth exploring. What do you think?
The First Law of IT Automation
What does a building architect hand off to a builder? Not a list of step-by-step instructions—that would be impossibly detailed and (impossible to revise). Read more
Refactoring IT
In successful, long-lived software projects, developers continually refactor their code. That means that in addition to adding features and fixing bugs, they clean up the hidden structure of the software. That cleaning up leads to easier extensibility and maintainability—which ultimately lead to higher higher quality and productivity.
The alternative? Software becomes steadily more complicated, becomes harder and slower to change, and eventually must be replaced wholesale or scuttled. Read more
