Balancing the work it takes to improve capability against delivery work that provides value to customers.
Download a free copy of Building an Optimized Business, a curated collection of chapters from the O’Reilly Web Operations and Performance library. This post is an excerpt by Jez Humble, Joanne Molesky, and Barry O’Reilly from Lean Enterprise, one of the selections included in the curated collection.
In most enterprises, there is a distinction between the people who build and run software systems (often referred to as “IT”) and those who decide what the software should do and make the investment decisions (often called “the business”). These names are relics of a bygone age in which IT was considered a cost necessary to improve efficiencies of the business, not a creator of value for external customers by building products and services. These names and the functional separation have stuck in many organizations (as has the relationship between them, and the mindset that often goes with the relationship). Ultimately, we aim to remove this distinction. In high-performance organizations today, people who design, build, and run software-based products are an integral part of business; they are given — and accept — responsibility for customer outcomes. But getting to this state is hard, and it’s all too easy to slip back into the old ways of doing things.
The secret to successful infrastructure automation is people.
“The trouble with automation is that it often gives us what we don’t need at the cost of what we do.” —Nicholas Carr, The Glass Cage: Automation and Us
Virtualization and cloud hosting platforms have pervasively decoupled infrastructure from its underlying hardware over the past decade. This has led to a massive shift towards what many are calling dynamic infrastructure, wherein infrastructure and the tools and services used to manage it are treated as code, allowing operations teams to adopt software approaches that have dramatically changed how they operate. But with automation comes a great deal of fear, uncertainty and doubt.
Common (mis)perceptions of automation tend to pop up at the extreme ends: It will either liberate your people to never have to worry about mundane tasks and details, running intelligently in the background, or it will make SysAdmins irrelevant and eventually replace all IT jobs (and beyond). Of course, the truth is very much somewhere in between, and relies on a fundamental rethinking of the relationship between humans and automation.
Pragmatism now rules in team structure, technology, engineering practices, and operational innovation.
Ancient history in computer science (2004) provides a gem about the personas that Microsoft envisioned as users of the development environment Visual Studio. They developed three:
- Mort, the opportunistic developer, likes to create quick-working solutions for immediate problems. He focuses on productivity and learns as needed.
- Elvis, the pragmatic programmer, likes to create long-lasting solutions addressing the problem domain, and learning while working on the solution.
- Einstein, the paranoid programmer, likes to create the most efficient solution to a given problem and typically learns in advance before working on the solution.
These designations received a lot of negative press, particularly around the Mort persona, but I want to focus on Einstein and Elvis.
Formerly, software architects exemplified the Einstein persona: isolated from day-to-day development details, focused on building abstractions and frameworks. The isolation is so common that it spawned its own “Ivory Tower Architect” derogatory phrase. But the realities of building systems that scale as fast as the business does invalidates that approach. Now, Elvis, the pragmatic developer, has ascended to architect while simultaneously descending from the Ivory Tower. Modern architects don’t have the luxury of isolation from the gritty realities of software development today. Pragmatism now rules in team structure, technology, engineering practices, and operational innovation because:
How inclusivity, complexity, and empathy are shaping DevOps.
Over the next five years, three ideas will be central to DevOps: the need for the DevOps community to become more Inclusive; the realization that increasing Complexity of systems is the underlying reason for DevOps; and the critical role of Empathy in the growth and adoption of DevOps. Channeling John Willis, I’ll coin my own DevOps acronym, ICE, which is shorthand for Inclusivity, Complexity, Empathy.
There is a major expansion of the DevOps community underway, and it’s taking DevOps far beyond its roots in agile systems administration at “unicorn” companies (e.g., Etsy or Netflix). For instance, a significant majority (80-90%) of participants at the Ghent conference were first-time attendees, and this was also the case for many of the devopsdays in 2014 (NYC, Chicago, Minneapolis, Pittsburgh, and others). Moreover, although areas outside development and operations were still underrepresented, there was a more even split between developers and operations folks than at previous events. It’s also not an accident that the DevOps Enterprise conference took place the week prior to the fifth anniversary devopsdays and included talks about the DevOps journeys at large “traditional” organizations like Blackboard, Disney, GE, Macy’s, Nordstrom, Raytheon, Target, UK.gov, US DHS, and many others.
The DevOps community has always been open and inclusive, and that’s one of the reasons why in the five years since the word “DevOps” was coined, no single, widely accepted definition or practice has emerged. The lack of definition is more of a blessing than a curse, as DevOps continues to be an open conversation about ways of making our organizations better. Within the DevOps community, old-time practitioners and “newbies” have much to learn from each other.
Think your IT staff can protect you better than major cloud providers? Think again.
I just ran across Katie Fehrenbacher’s article in GigaOm that made a point I’ve been arguing (perhaps not strongly enough) for years. When you start talking to people about “the cloud,” you frequently run into a knee-jerk reaction: “Of course, the cloud isn’t secure.”
I have no idea what IT professionals who say stuff like this mean. Are they thinking about the stuff they post on Facebook? Or are they thinking about the data they’ve stored on Amazon? For me, the bottom line is: would I rather trust Amazon’s security staff, or would I rather trust some guy with some security cert that I’ve never heard of, but whom the HR department says is “qualified”? Read more…
Six months in and there is much to celebrate and plenty of work still to be done.
Implementing O'Reilly's new IT strategy is like swapping out airplane wings mid-flight. We're making considerable change, but at the same time we can't disrupt the services and projects that are already underway.
Understanding why an IT leader operates a certain way can net better results for everyone.
It can often appear there is only one type of person leading IT. That's not the case. Understanding an IT leader's motivations and needs will ultimately benefit all involved.
The best IT managers have a background in IT and general management.
Being a good IT manager is hard. Being a great business leader is harder. What separates them is not just the ability to continually and uniquely inspire, but to also be a well-informed and skilled business manager.
Federal CIO Kundra has released a 25-point plan to reform the troubled federal IT sector.
The Obama administration has proposed a 25-point strategy to reboot how the federal government purchases and uses information technology, including new consideration for startups and a "cloud first" approach to new investments.
We're embarking on a journey that will transform how we deliver and support our technology needs.
O'Reilly's new IT strategy had to consider the company's culture of innovation while introducing the right level of predictability. Too much unmanaged innovation or codified predictability would limit our ability to grow and be a recipe for IT failure.