Michael Ibarra | 03/30/2015 | Application Development | Thought Leadership
Throwing it Over the Fence
DevOps…It’s become a term that has devolved to describe too many of the wrong things. Job titles like “DevOps engineer” and “Director of DevOps” and even DevOps training and certification programs hide an important issue of what DevOps was originally meant to be…
If you’ve ever read “The Phoenix Project“, “Release It” or “Continuous Delivery“, (and you should) you probably already know that DevOps was never intended to be a title nor a department. DevOps is an organizational pattern. It’s what you get when development teams stop “throwing code over the fence” into production and start working together with IT operations personnel as members of cross-functional teams.
Cross-Functional Teams
Many so-called cross-functional teams usually consist of developers and testers; and sometimes even a business analyst or product owner. This is not what cross-functional means. True cross-functional teams include members representing the full spectrum of disciplines required to bring software from idea to production. Such teams include product owners, functional analysts, UX designers, developers, QA, DBAs, enterprise architects and IT Ops personnel, and these teams have full responsibility over all aspects of their software product until it is no longer in service.
For many organizations, this is a bold departure from tradition in which development teams hand off completed software to a separate operations team for deployment and maintenance in production. The philosophy driving the DevOps movement seeks to eliminate this separation. But why?
Handoffs are Wasteful
Anytime the responsibility for a software product changes hands, even under the best of circumstances, some knowledge is inevitably lost. Additionally, each transfer of knowledge and responsibility along the production chain lengthens your product’s lead time, incurring unnecessary costs. These costs might include time spent in meetings and writing detailed documentation instead of coding, plus delays in realizing revenue and ROI the longer your product takes to get to your customers.
In Lean manufacturing and lean software development, any step in the process that moves unfinished product from one stage to another, making no changes to bring it closer to the state for which a customer would pay, is considered “waste of transport” – one of the original 7 forms of waste. One of the key goals of Lean is to reduce such waste, and one way to eliminate these handoffs is by having one team responsible for all aspects of the product. From the inception of ideas all the way into production—including bug fixes and production support—have one team communicating and working together all the way, making Conway’s Law work for you.
Conway’s Law and Systems Architecture
Over 40 years ago, programmer Mel Conway publicized his observation that the design of software systems reflect the communication structures of the organization that built it. This has since become known as Conway’s Law and recent studies have validated the idea. The truth behind Conway’s Law is that, almost always, communication and activities in organizations follow the path of least resistance.
For example, if the development team has to deal with too much red tape to get a database script into production, they’ll write a workaround in the application layer instead, which they control.
This is also why most organizations in which development teams hand off code to ops teams wind up with code that is written well enough to pass acceptance tests in development and QA environments, but fail to take into consideration concerns like performance, security and scalability in a production environment. Teams that are structured to share information across departments and given autonomy to make decisions are better equipped to develop highly robust and cohesive systems.
Not every team needs a dedicated architect, DBA, or Ops person. Depending on the needs of your organization, people in these roles can belong to multiple teams, providing much needed communication and consistency between their respective product teams and their departmental teams.
In summary, organizing teams to be truly cross-functional, together with the application of Lean manufacturing principles, is how you can start to build a DevOps culture that will continue to deliver quality software for years to come.
