The road to DevOps can be rocky. Larger enterprises often cite cultural barriers such as the "developers vs. operations" mentality as the biggest obstacles to achieving DevOps, and much has been written about how to break down those barriers.
But while these organizations struggle with the relationship between developers and ops staff, they often neglect the equally tricky relationships among different parts of the development organization itself.
Products and silos
Large organizations that work on multiple products typically structure their development staff as independent silos of teams and individuals working on one product. The teams in any given silo might be structured as component teams, where each is responsible for one or more components or layers of the product. Alternatively, and more commonly in organizations that are adopting agile methodologies, they’ll be structured around features, with each team responsible for the end-to-end functionality of their user stories.
Either way, the teams within each silo have to collaborate well with one another in order to ensure that the final product is a smooth integration of the work produced by each of the teams.
Integrating products
But when it comes to integrating different products, it’s a different story. Each silo has its own management structure, its own goals and objectives, and its own deadlines and commitments. When one product—let’s call it Product C, for "consumer"—needs to integrate functionality from another product—Product P, for "provider"—the C team is on its own. In the best case, Product P will have a documented API that it can use. But if there are gaps or bugs in the API, Product C will have to submit enhancement requests and defect reports to Product P, whose team will then prioritize those issues relative to their own tasks. The result is that Product C is stuck until Product P gets around to implementing the functionality the C team needs.
In the worst case, there isn’t an API, and Product C will have to hack the integration. If it somehow manages to create the integration, there’s no formal contract between the products, so the next version of Product P is likely to break any assumptions that Product C has made. Even if Product P agrees to create an API for the integration, the team will invest only the minimum effort. The API is likely to be delivered late, with no support and no documentation, and probably not good enough for Product C’s requirements. It’s also likely to be fragile, since no one in Product P uses the API, and the team won’t invest much effort on automated testing to catch any breaks.
Eroding the development barriers
Since they know it best, developers from Product P should be responsible for creating the API. But they should create the API from the perspective of the Product C team, who are the ones that will actually use it. To achieve this, they can temporarily reassign a developer from Product P to the team in Product C that will be using the integration. That developer’s task will be to create the API.
Now, because someone from Product P is part of the team that will be using the API, the integration is far more likely to succeed. Consider the reasons why:
- The goal for the Product P developer becomes “Make the integration work” rather than “Create an API.” The definition of done for the API becomes tied to the purpose of the integration, rather than creating an API just for the sake of being able to say “Yes, we have an API,” and handing it off as quickly as possible. The Product P developer will go back to Product P once the goal has been achieved.
- The integration can start in parallel to the work on the API. Because the developer from Product P has access to the latest build in development, the Product C team doesn’t have to wait until Product P’s release. Stubs and service virtualization can make this even easier.
- Integration testing can start early for the same reasons.
- The developers from Product C will write regression tests that will be run on Product P as part of Product P’s continuous integration to ensure that Product P’s developers don’t break the API.
- Because the developer creating the API comes from Product P, he can work with the other Product P developers to ensure that the API is generic enough to support future integrations with different consumers, and not tailored to work only with Product C.
- The developers will have cultivated personal relationships that cross the boundaries of the silos, leading to natural collaboration between them.
- Once the integration is complete, the developer can go back to Product P with a greater understanding of the integration scenario and will be better aware of the context of the API. Conversely, the Product C developers will gain a better understanding of how Product P works and how it’s built.
There is, of course, a price to be paid for this approach of integrating developers from different silos. Product P must lose a developer for the time that it takes to develop the API. There are also logistical challenges in larger organizations; for example, the product teams might not be collocated. Nevertheless, the integration must be created, and by working together, aligning the Product C and Product P teams with the goals and requirements of the integration should increase its chance of success.
Eroding other barriers
There are other barriers that can be overcome with a little effort. An organization that's finding DevOps too complex to embrace at the moment can start looking at other parts of their silos and finding places where there could be greater cooperation and sharing. This can plant the seeds for an organic DevOps transformation. For example:
- You can pair testers from Product P with testers from Product C, to share knowledge and to bring a fresh perspective on the integration.
- The integration might require the operations staff of Product C to support a new web server or database once the integrated system is deployed. They might be faced with new security concerns as well. As with the development teams, you can temporarily reassign one of the Product P operations staff to Product C to ensure service availability and share knowledge.
- The Product P teams may be using different processes and tools from those in Product C. As they work together, they will naturally share their knowledge and experiences about their processes and tools, which in turn may lead to one of the silos aligning with the other. If a bug is found in the integration, it is much easier to share the information necessary to resolve that bug if the two silos are using the same systems and processes to manage their defects.
In parallel, you can:
- Establish communities of practice and open them to people from all silos. This exposes people to others with similar specialties, such as Java programmers, user-experience specialists, or security architects, and enables the exchange of information and ideas across different parts of the organization. Collocated events such as lectures, shared lunches, and meetups or virtual forums such as discussion boards and newsgroups break down interpersonal barriers and help create new relationships.
- Foster an innovation culture that encourages people from different silos to work together on new ideas.
A happier and healthier organization
Organizations that have adopted agile and DevOps practices across the board will already be collaborating well. But those that are still structured as independent silos can take some simple steps to overcome obstacles that hinder progress.
Start by eroding the barriers between people with similar functions in the different parts of the organization, and encourage a more collaborative environment that will make everyone more productive. Ultimately, that will make the road to DevOps less rocky.
Image credit: Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
