As respect for design as a competitive advantage grows, companies are tackling the challenge of integrating design practices into enterprises and digital businesses. DesignOps is an emerging strategy for addressing this challenge. The UX community is now exploring best practices for operationalizing and scaling in-house design.
DevOps is an IT methodology for designing and operating complex IT systems and organizations. DevOps addresses the question of how to build and run sociotechnical systems that can scale without becoming brittle. Understanding the DevOps approach can help the UX community think more broadly and systematically about what it means to scale design.
DevOps and DesignOps are both responses to the same underlying phenomenon. We are living through a transition from an industrial economy whose focus was physical products to a post-industrial economy that centers on digital services. This post-industrial business economy isn’t just about making digital products instead of physical ones. It’s about integrating the physical and digital realms with one another—infusing each with the other.
Champion Advertisement
Continue Reading…
What Problem Does DevOps Address?
Industrialism has taught us to treat large systems like machines. While these systems might be very complicated, if we can break them into their component parts and make sure all the components work, the whole system will work. Business, in general—and IT, in particular—have developed management strategies that treat businesses like complicated machines. Digitally infused services, on the other hand, more closely resemble the kinds of complex systems we find in nature and society. Their components are dynamically and intimately interconnected. It becomes impossible to pull them apart without the entire system breaking down.
In reality, complex systems behave very differently from complicated machines. Their global structure emerges from local interactions without the existence of any explicit rules that we can design or even describe. Emergent systems are flexible and adaptable, but prone to unpredictable and perhaps unavoidable failure. We can never be sure exactly how well these systems are working or in precisely what ways they are broken.
Complex systems are sensitive to history: very small differences in their initial conditions can lead to wildly divergent outcomes. At a certain level, it becomes impossible to tell how services will behave or how people will interact with them—until people use them in the real world. Finally, complex systems co-evolve with their environments. Deploying new solutions generates new problems, which their designers could not have foreseen because they didn’t yet exist.
Because of their strange, counterintuitive behavior, complex systems evade traditional control mechanisms. Thus, they require a new management strategy that enables them to safely navigate continuously changing, unknowable environments. DevOps arose as a way to manage the complexity that comes with digitally infused services. At the heart of DevOps is a shift from machine-oriented reductionism to systems thinking, resilience, and continuous learning.
The need to steer digital services presents us with a conundrum: On the one hand, services must continuously learn and adapt in response to customers’ evolving needs and experiences. Therefore, we must create companies that align with customer needs—from front to back and top to bottom. On the other hand, services must be consistent, coherent, and holistic. How can we overcome this apparent conflict?
What Is the Solution? Microservices
The good news is that the very thing that presents us with this conundrum can also lead us past it. DevOps addresses the need for agility by breaking systems, processes, and teams into small, self-sufficient units. The smaller the unit, the easier it is to understand and, thus, to safely make changes to it. Instead of building large, monolithic applications, DevOps teams build small microservices, each of which focuses on a specific capability. These modular, independently deployable microservices together form a microservices architecture. Instead of operating monolithic applications with large, siloed operations, businesses are now creating small, cross-functional DevOps teams that operate microservices. (These teams are often called two-pizza teams because they should be small enough that you can feed them with just two pizzas.)
However, we still need an attractive force that pulls these independent units back into a coherent whole without making it brittle. Mutual service is that attractive force. No longer is it enough for Design, Development, Operations, or Security to just do what they do. Instead, these functions must shift their focus outward and upward—toward their customers and customers’ goals and desired outcomes. When functions and teams help each other—and, by extension, the company’s customers—this creates greater business value. Thus, this cooperative way of working becomes the purpose of every part of the organization.
What Does Complexity Mean for Governance?
Whether we’re talking about security, regulatory compliance, or design consistency, we need to ensure that we do things well—and in some cases correctly—in some globally consistent fashion. However, treating governance as a centralized enforcement body or as a function that does things on another’s behalf doesn’t scale in complex environments. It creates friction and brittleness. Just like every other part of the digital service organization, governance needs to shift its focus from doing things to helping other teams leverage their capabilities—whether writing security policies, conducting compliance audits, or building design systems. Making good practices feasible, viable, and desirable becomes the underlying governance mission.
How Can DevOps Inform DesignOps?
To fully understand the meaning of good practices from the perspective of DesignOps, we need to revisit our understanding of services. For services, how you make something becomes part of what you make. For example, if you try a new restaurant and the food is great, but the service is lousy, you’ll be much less likely to try it again. You experience the quality of the food and the service as part of a unified experience. The unity of functionality and operability is the fundamental premise of DevOps—and the reason we make a portmanteau out of Dev and Ops.
The unity of functionality and operability challenges Design to expand its purview dramatically, going well beyond the confines of user-interface design. It becomes necessary to design for service, not just software. For example, what is the user’s experience of a security breach? It doesn’t matter how well-designed a Web site is if a service is losing customers’ personal information, forcing them to figure out how to protect themselves against further theft, and in general, causing them frustration, confusion, and anger.
Ultimately, a service user experience results from the interactions between all of the component parts that make up that service. How can we ensure good service experiences and prevent bad ones—especially in the context of complex systems that we can’t fully understand or control, which suffer from inevitable failures? The only thing we can do is continuously learn from our failures. Just as DevOps emphasizes delivery speed, it also emphasizes feedback and learning methods such as monitoring and blameless postmortems.
The need for continuous learning means approaching our work as mutual service is necessary, but not sufficient. Delivering high-quality service necessitates continuously improving service quality. In a digital-service business that is driven by mutual service, service design becomes part of daily operations. Design becomes operations—in the sense that continually innovating on each other’s behalf becomes part of the daily cadence of everyone’s ongoing work.
The Importance of Design Thinking
Let’s look at an example of the need for pervasive design thinking. The National Institute of Standards and Technology (NIST) recently revamped their password recommendations. Their comments on their work include this remarkable statement: “Far too often security fails because we forget people are involved.” [1] The authors weren’t merely bemoaning how hard they’d made it to employ good security practices. They were acknowledging the fact that the lack of user-centered design compromised their own technical goals.
This acknowledgment implies that we need security experts to think about user experience and user experience experts to think about security. The most profound value that DesignOps can offer isn’t building design systems or creating standards for hiring or managing designers within an enterprise. DesignOps offers the greatest value by helping teams to design and operate for service. Truly service-centered digital design and operations requires weaving user-centered, creative solution discovery into the fabric of the entire organization.
As CEO of Ingineering.IT, a Minneapolis digital-transformation consultancy, Jeff specializes in helping IT teams become user-centered problem solvers. His 30-year career building systems and leading organizations spans the entire product development and operations spectrum. As an internationally recognized IT coach and design-thinking practitioner, Jeff provides coaching and workshops on agile development, DevOps, and design thinking to leading enterprises such as United HealthCare, HealthPartners, Thomson Reuters, Best Buy, CenturyLink, and Cisco. He is a highly respected teacher, writer, and speaker. His keynote talks and workshops are in demand at design and IT conferences across the US and Europe. Jeff is especially known for introducing the global DevOps community to the importance of empathy. He is the author of Designing Delivery: Rethinking IT in the Digital Service Economy. Read More
