Discover PerformanceHP Software's community for IT leaders // March 2014
Software-driven business means no more IT ‘projects’
IT consultant Damon Edwards talks about a critical mental shift IT leaders need to make to be successful in today’s marketplace.
As software increasingly defines how a business serves its end users, we asked IT/business consultant Damon Edwards how IT leaders should react. When software is more than just a supporting tool of your business—in fact, an increasingly major interface between you and your customers—how do you change the way you run IT to reflect the changes in IT’s value?
Edwards, who talks about the software-defined enterprise in the March issue of HP Discover Performance, says a key to getting the speed and quality that today’s light-speed business climate demands is to shift from IT’s traditional project-driven mentality.
“While the concept of a project isn’t problematic in and of itself,” Edwards says, “the idea of aligning, organizing, and funding your IT organization based on projects is out of sync with today’s business needs.”
That leads to several critical implications for how you manage your IT staff—and the skills they and you will need to succeed.
Q: You’ve said that project-driven IT is a major inhibitor of IT and business success. How so?
Damon Edwards: The traditional IT mindset of being optimized to deliver discrete pieces of software or infrastructure with, say, quarterly or yearly cadences is just not in sync with the demands of today’s business environment. Most businesses aren’t project-driven. Manufacturing, financial services, retail, SaaS—their normal operating mode is that of providing a service to their customers. Their competitiveness relies on being able to continuously react to the market and provide the right service at the right time at the right price.
IT needs to operate with a service-provider mentality. When you’re running a service, the service—by its definition—is never done until you decide to shut the thing off. In between the first time you deploy the service and when you finally decommission it, there is no other “beginning” and “end.” This is especially true if you look at it from the most important point of view: the point of view of the customer. If customers don’t see value in the form of projects, then why are we organizing ourselves in those terms?
Q: How does being “service-oriented” change the way your IT team actually works?
DE: That’s a long conversation because it touches on so many different areas, but there are a few key indicators that we look for—traits we see in IT organizations with a service-oriented point of view.
Resource allocation is the first one. You don’t see engineers being moved from project to project. Also, you don’t see such clear delineation in phases in their service delivery lifecycle, where one group, say dev, does one type of work and then goes off to do something else entirely different, while another group, say ops, picks up that same piece of work and does something else with it.
You will see people organized by customer-recognizable services, working in integrated teams to do constant incremental improvement to the features and operations of those services. Of course, individual people get reassigned or move on all the time, but the role they were in doesn’t disappear or end, as you’d see with a traditional project.
Another interesting indicator is the idea of ownership and responsibility. In high-performing, service-oriented organizations, the person responsible for a service is usually the person who wrote it. It’s the “devs wear pagers, too” mentality. Control and responsibility are pushed as close to the source of the work as possible, rather than being centralized.
The best organizations also treat operational requirements—or “non-functional requirements”—as first-class citizens, along with feature or functional requirements. Uptime and performance are features too. Don’t expect uptime and performance if you don’t make explicit investments in them, like you would any other feature.
Another interesting aspect is the role of tickets. High-performing organizations treat them truly as “trouble tickets”—expectations or problems rather than a way to manage day-to-day work activity. They use self-service interfaces and tools for almost all required activity that falls outside of an individual’s capability or focus.
Q: Is that last point similar to what HP’s Paul Muller calls “ticketless IT”?
DE: Yes. You could also call it “IT as an API” or “operations as a service.” The old way of working is: “I need an environment, so I’m going to open up a ticket, and someone is going to get around to doing this for me.” The new way of thinking is: “I need an environment, so I’m going to press a button, and an automated service will give me exactly what I asked for.” No more long waits. And IT staff, who used to spend all their time on the oppressive slog of responding to and closing tickets, can now build services that provide self-service to others.
Request queues and waiting around for someone to do something for us is simply not the most productive way to work—especially when it comes to non-standard, fast-moving knowledge work. IT operations can’t just be a collection of request-doers, fielding and closing tickets all day. Just from the pure numbers perspective, ops is always going to be outnumbered, so why not leverage the rest of the organization instead of being the bottleneck?
Ray Rappaport at Netflix does a presentation that provides a great example of these principles in action. He shows how Netflix turned a classic aspect of IT operations, monitoring and metrics, into a service. Now, as a developer at Netflix, you don’t go through the old process of logging a ticket so “the monitoring person” can configure something so that you eventually see a graph in a dashboard that may or may not be the information that you expected it to be. Netflix gives developers the APIs and self-service tools to just do it themselves. The “metrics and monitoring team” is now the “metrics and monitoring service maintainers.” They only get a ticket if something is wrong with that service. In this model, individuals who are doing work that needs metrics and monitoring are safely in control—there aren’t any bottlenecks blocking their way, and they can experiment and look for new ways to add value.
Damon Edwards, co-founder of consultancy DtO Solutions and host of the DevOps Café podcast, talks about how to make the software-defined enterprise in the current edition of HP Discover Performance newsletter. Sign up now and don’t miss an issue.
HP Software’s Paul Muller hosts a weekly video digging into the hottest IT issues. Check out the latest episodes.
Introduction to Enterprise 20/20
What will a successful enterprise look like in the future?
Challenges and opportunities for the CIO of the future.
What the workforce of 2020 can expect from IT, and what IT can expect from the workforce.
Data Center 20/20
The innovation and revenue engine of the enterprise.
Dev Center 20/20
How will we organize development centers for the apps that will power our enterprises?
Welcome to a new reality of split-second decisions and marketing by the numbers.
IT Operations 20/20
How can you achieve the data center of the future?
Preparing today for tomorrow’s threats.
Looking toward the era when everyone — and everything — is connected.