Organizing Enterprise DevOps
Cloud computing is changing how enterprise software gets developed, operated, and delivered. Businesses who are organized around traditional product development life-cycles will need to evolve to be able to compete with companies who have organized around cloud computing and agile practices such as DevOps.
Most companies I have worked at have been organized like this:
Not surprisingly this organization reflects a traditional product development life cycle (PDLC) where each department plays a specific role and has well defined inputs and outputs.
Product Management is in charge of coming up with requirements and handing them off to Engineering. Next, Engineering starts developing features and content for the release while Product Management begins planning launch activities with Marketing, Sales, Support and Operations. Once Engineering completes all features, the QA (Quality Analysis) team tests each new feature and also regression tests the full product. The testing and bug fixing may go back-and forth till someone determines that the release is good enough to ship to customers, or as is more often the case a pre-determined release date is overdue. This milestone then triggers the rest of the release launch and roll-out activities.
Smaller companies can follow this process and may still manage to release every few months. However as the company grows this process invariably slows down to one major release per year. Agile development and practices can offer some incremental benefits, but do not address the fundamental issue with the organization and the release model that it propagates.
DevOps and Lean Development
A fundamental principle of most Agile / Lean product development approaches is to eliminate departmental silos and empower stakeholders with end-to-end visibility of their products and solutions.
The DevOps movement further champions this idea. With DevOps, software developers are empowered to operate their software without having to jump through process and personnel hoops like change review boards and upgrade windows. This empowerment comes with increased responsibility and requires discipline and sophisticated automation to pull off. It would also not be practical, or cost effective, to adopt DevOps without cloud computing where infrastructure can be delivered “as a service” and can be fully automated. Newer technologies, like Docker, are taking DevOps to the next level by standardizing how software gets delivered and operated at scale.
The Digital Enterprise
The model of organization around a traditional product development lifecycle does not work well for digital products that are delivered “as a service”. It’s also not possible to get the full benefits of DevOps and agile development practices with a traditional organization as department boundaries hinder end-to-end visibility and ownership.
In a startup you are either building, selling, or doing both. Digital Enterprises are also organized in this manner, with fewer departments, and larger, flatter organizations.
Here are some key characteristics of this type of the Digital Enterprise:
- Overall, the enterprise has a fewer departments.
- Within the product / engineering team, there are several, small, DevOps teams and each team is fully responsible for the development, test, operations, and support of a software service (at a high level, a service is a software component accessible via uniform APIs). For example, Amazon uses the 2 pizza-team rule and API driven architectures.
- The product is architected to allow each team to release independently. Microservices based architectures are becoming increasingly popular, as a way to architect systems, and can offer the necessary decoupling.
- A platform team  provides the following across multiple DevOps teams:
- Common automation and tooling
- Shared software services, such as analytics and customer management
- Curation of common third party components
- Management of cloud providers (public and private)
- Continuous system testing
- Site Reliability Engineering with first line of support
- Product managers are moved closer to, or are directly a part of, the engineering teams and work closely with one or more DevOps teams.
- Product Management decisions are data driven, not based on past experience, the loudest customer, or this quarter’s big sales deal that requires just one more feature. Fast release cycles allow rapid experimentation, and data collection, to decide how the products and solutions evolve.
Ok, but can this organization model really work if you are delivering products that include hardware and software components?
Perhaps not exactly, but a clear trend is that hardware devices are increasingly becoming connected, stateless, and programmable. This shift allows complexity, and the solution value proposition, to be transferred from the hardware device into cloud-based software services.
If you design solutions in this manner, you can still build a digital enterprise and leverage the fast innovation cycles of software. Industries where market leaders have failed to make this transition remain ripe for disruption by internet-based “connected” variations of the products and solutions.
Product delivery cycles are getting increasing shorter and businesses that deliver software faster will win. Best practices, such as DevOps, are often hindered by traditional organizational structures and processes. To compete, enterprises will need to evolve their organizations to enable DevOps.
A Forrester study  shows that eight DevOps practices are the key to faster delivery cycles:
- deliver small increments of functionality;
- use dedicated, cross-functional teams;
- use loose architectural coupling;
- automate environment provisioning;
- continuously integrate code;
- continuously test;
- continuously fund; and
- provide real-time transparency.
Successful enterprises will organize in a manner that promote these practices and make Enterprise DevOps successful.
 Startup Management Best Practices #2: Startup Team Sizes, Tomasz Tunguz