How can DevOps help with multivendor projects?
In this day and age, outsourcing is a common practice. Gone are the days of end-to-end development of large-scale products that are cultivated by a single group. This could mean working with another part of your existing company, collaborating with another company locally or using global resources. And it raises the question: How can DevOps help in the delivery of a product that involves multiple vendors or contributors?
Multivendor projects are everywhere
Look at some of today’s large industries: automotive, healthcare, IT. Very few of the companies that operate in these industries work in a vacuum. Portions of the work are being done by multiple vendors, whether internal or external.
IBM is no different; we also work together across our product lines and can benefit from the use of DevOps. For example, IBM Systems and Technology Group (STG) is a globally distributed development team collaborating on many product lines.
Consider, as an example, a multivendor project from my great state of Minnesota. Minnesota is one of the many states currently working to implement a new healthcare program, and projects like this require processes and solutions to manage product deliverables that involve more than one contributor. The current MNsure project requires the collaboration of multiple vendors, each responsible for a piece of the puzzle. How are they collaborating such that each knows about the project status and cross-vendor issues, and how are they ensuring faster decisions and functional delivery?
I see the same challenges in the delivery of the IBM PureSystems family of offerings. Integration by definition means the act of combining parts into an integral whole. Notice in the diagram below the level of integration occurring. How are the operating systems collaborating with storage, networking and systems management teams?
DevOps to the rescue!
DevOps can help with multivendor projects like these.
First off, the principles behind continuous delivery and the underlying agile code development philosophy imply that smaller, more consumable pieces of code are delivered more frequently. DevOps reinforces that through the development lifecycle by enabling automation of testing, deployment for both test and production, and the provisioning of any necessary environments.
Within the STG DevOps solution team I manage, we’ve deployed a centralized and consolidated Rational Collaborative Lifecycle Management system where the key component is a common defect called STGDefect, which is our work item type within Rati
This common defect process simply means that for the teams contributing to IBM PureSystems offerings, a single defect—no matter where it’s found—can be routed to the proper team. In most organizations and projects, the first temptation is to develop a process and tool set for each deliverable. Since IBM PureSystems requires contributions from multiple organizations, a way to route and share artifacts from the hardware to firmware to operating system to application development teams is extremely important.
The idea of collaboration extends beyond just defects for projects like MNsure or IBM PureSystems. Think about project planning and management or normalized reporting. Each is now possible as a result of using DevOps fundamentals implemented using IBM Rational solutions. Without DevOps, you’re bound to spend more time, resources and money to deliver value to customers.
How do you think DevOps could help with the rollout of your collaborative, multivendor project? I welcome your thoughts and personal experiences.