DevOps in Health and Health Care

Six months ago, our CIO presented me with the opportunity to establish a totally new DevOps team. He started our conversation by asking, as soon as I sat down, “What is DevOps?” My answer was that he posed a trick question — there is no agreed definition. His immediate riposte was the challenge to stand up a new DevOps team; a week later we had the team in place. In one way, I might still stand by my noncommittal answer, with multiple definitions of DevOps floating around in the IT and business literatures.

However, the DevOps community (or more accurately, DevSecOps) is close to finalizing and evangelizing its new manifesto. Originally, the term merely connoted closer cooperation between development and operations teams. But quite a few authors have posited a more expansive and transformative vision of what DevOps could, and should, be.

Since that conversation, I have been mulling over how this vision might be applied in our health and health care industry. While this broader way of thinking can apply to any industry in general, each has its own nuances and concerns. Getting my ideas on paper (figuratively) should help me refine and strategize toward what our new team should strive in the next few years. Admittedly, that is almost an eternity in the world of IT, so as befits a DevOps team, our approach and goals will change as we continuously learn from the experiences, metrics, and feedback which will serve as signposts for how we need to adapt. But before I can expand on how I have come to view the DevOps movement within IT and especially IT within the health and health care industry, I should perhaps level-set where my current thinking has reached. Hopefully, you will agree with much of what I am about to limn, but if not, at least you will know from where I am coming.

As I noted, there have been several authors who have fundamentally shaped my thinking. Examples include Mark Schwartz (A Seat at The Table); Gene Kim, Kevin Behr, and George Spafford (The Phoenix Project); and Matt Stine (Migrating to Cloud Native Applications Architecture). My intent here is to boil these in-depth and insightful, while expansive, presentations down to a very concise set of bullet points. Such broad strokes will, by definition, gloss over far too much of the well-developed and powerful arguments supporting these ideas, so I highly recommend reading each and every one of the pieces listed here. I plan to explore how my slant on this emerging wisdom may apply in the health and health care arena later, but I will be assuming some familiarity with the underlying logic and reasoning presented by these IT leaders as I move forward. Common themes I see as important include:

• Fully autonomous, cross-functional teams fully responsible for one atomic piece of business value (a “product” in the small sense), with all roles represented and participating, including especially customers/end-users
• Measured and continuous learning based on experiential and studied knowledge gained by team members and users
• Rapid adaptation, directly based on that continual learning and feedback
• Encapsulation of the business value, or “product”, through the use of contractual APIs, separation of duties, late dependency-insertion/definition, context-independent configuration, and standardized resources, such as databases or other dependencies
• Horizontal scaling using micro-services based on scripted, automatically-deployable, independent, and on-demand infrastructure
• Clear and consistent focus on reducing technical debt and constraints
• Rapid, iterative, incremental moves to expand the target business value with a narrow focus
• Self-healing infrastructure, infrastructure as code, and rapid deploy cycles (CI/CD)

The first bullet is often the most difficult to sell and therefore I will tackle it in this first post. Given my somewhat syndicalist roots, trusting team members to do what they know how to do just makes sense. But management seems all too often to be a system of creating governance, processes, and procedures to strip autonomy from those we initially chose to hire based precisely on their expertise, knowledge, and skills. This feels especially true, as others have noted, for the field of IT and its historically rocky relationship with the rest of the organization.

When we do our stuff really well, IT can seem either like magic or invisible. And it used to be that IT knowledge appeared as mystical arcana available only to a gifted few. If that was ever true, it certainly is no longer the case — most, if not all, members of an organization possess a sophisticated understanding of technology, and IT folks now often interact with organizational members who have more extensive and in-depth niche-knowledge.

As a consequence, and as these authors and others so poignantly present, there is no longer any justification for the enterprise and IT to be viewed as either separate or in opposition. Historically, IT may have been the people who “always say no” or create unreasonable obstacles in the way of others adding value to the enterprise. Now though, there are few, if any, enterprises where IT is not a central part of the organizational raison d’être. The enterprise now consists of IT, and IT is core to the activities of the enterprise. To build on Mark Schwartz’s example, viewing IT as separable from the modern enterprise makes as much sense as viewing Finance as separate or in opposition. But IT has also changed the enterprise. Going all hoighty-toighty for a moment by borrowing from Hegel, what we have seen over the last few decades is large, slow organizational structure (thesis) meeting its antithesis in rapidly changing information technology, dialectically resulting in a synthesis of new lean and agile organizations built on and infused throughout with information technology and expertise. This synthesis has fundamentally changed the economy and the workplace.

In this new environment, strategic leaders need to focus on enterprise objectives, understanding that IT is essential to reaching those goals, even if IT itself is not the outcome. IT leaders then need to translate that strategic grand vision into business value products that will need to be created and sustained. The task of these products is then handed over, en toto, to autonomous, cross-functional teams to create that business value. These lean and agile teams continue to work on the product for only as long as that product continues to add business value to the organization.

Moving the other direction, IT folks need to understand that their goal is to add value to the enterprise. Nothing else matters. Nothing else needs to be done. When they are blocked or need help coordinating cross-team collaboration, they can call on IT leadership for assistance. They also provide the continuous feedback upon which IT leadership can act upon to adapt and which they can distill even further to provide feedback to further the learning of senior leadership.

Admittedly, this is a strongly syndicalist read on what the DevOps movement authors are urging us to adopt. But the control model of management, perhaps once appropriate for exploitive work-relations in early factories, really makes little sense in a knowledge-based economy. We no longer live in a Taylorist world where employees are nothing more than finite muscle-power to be commanded and used in full. In a world where we hire people for their skills and knowledge and where they must acquire an extensive lore of institutional knowledge before reaching full effectiveness, starting with an assumption that employees are opposed to exercising and expanding their skills or to creating business value through applying that knowledge not only no longer makes sense, but in the end is dysfunctional for the enterprise.

Academic/clinical medical centers and medical schools (I did say I was going to talk about them a while back) comprise a setting where this is particularly true for IT folks. In an economy where these highly-skilled people can command higher salaries and garner bonuses and equity working in other industries, our particular niche tends to attract those who seek to use their knowledge to benefit others and create social good.

In order for the enterprise to succeed, management must strive to make each and every position meaningful for its occupant — which means enabling them to make the best use of what they know how to do. Sure, a small number of employees might take advantage of this autonomy, but it hurts the organization far more to start from a position of managing to the occasional deviant. Better to quickly excise the rare malignant worker than to treat everyone in the organization as initially unhealthy and in need of close hospice.

I have always used this approach with the teams I get to coordinate. So far, I have had an issue with only one team member when I have started from a position of trust. The feedback I more typically receive when people are enabled to do their best based on what they uniquely bring to the organization, as opposed to me assigning them tasks and deadlines based on what I know, is a sense of excitement and enthusiasm. And purpose; most especially, a sense of motivating purpose.

One of the things I needed to face when I got begrudgingly moved to management was the realization that I would never again be the person at a team meeting with the most current and in-depth knowledge on a particular IT topic. All I would be able to bring to the table would be a broad view of the what the whole team does and an ability to facilitate collaboration and intercede on blockers. An important role in its own right, perhaps. But I would suggest it is of no more, if not less, importance than the roles occupied by those who “do”.

It may seem that I have strayed far from a discourse on DevOps in health and health care into some, perhaps biased, ramblings on what used to be known as “political economy”. I strongly suggest otherwise. The trust model I have been expounding is incredibly central and integral to the DevOps approach. Without the trust underlying truly autonomous, cross-functional teams completely focused on adding business value, we are merely swapping domains for teams. Existing silos for new silos. Old frustrations for new. We cannot ask people to create value through applying their knowledge if we deny or constrain their ability to apply that knowledge and skills. We cannot ask people to create value while denying them a sense of internal purpose driving them to create value and to innovate. We cannot ask people to create value by keeping them within the limits of our own abilities instead of helping to stretch their abilities. The trust model of teams is central to moving away from centralized, static, long-term, anticipatory, deadline-driven plans, committee governance over design and change, and all the other detritus from the fear-based control framework, and toward maximizing business value as defined by an evolving strategic vision using lean, agile teams of motivated and enthusiastic workers.

I am quite fortunate to be working in a very new academic/clinical medical school whose mission is to “rethink everything” about health and health care delivery. The IT team here takes that mission quite seriously. My goals in that regard over the next few years are to see how far we can safely push and implement these ideas from the DevOps movement into this setting and industry, in order to improve health and health care delivery and to fully take advantage of what the rapidly changing field of information technology can bring to our work. Specifically, building on the vision of the CIO, I want our enterprise to be one of the best places for meaningful and rewarding IT work and to be a place where IT is highly regarded for responsive, innovative, and collaborative participation in the essential work of the enterprise.