Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
On a recent ‘virtual panel’ session, many questions came in real-time from almost a thousand attendees around the globe. I’ll try to cover the most interesting questions in this column over coming weeks, but one that came through many times is very typical of the discussions I have with my customers and others, especially those from larger enterprises:
Q. How can we implement a DevOps approach with external contractors, consultants, vendors and service providers?
Many of my customers regularly use external programming shops and third-party consultants, from across the street and across the globe. A majority also use third-party service providers, especially cloud and hosting services, to help delivery the on-demand infrastructure that fuels DevOps.
The good news is that you can definitely incorporate these third-party vendors into your DevOps approach, even in a large enterprise, starting with a few simple steps.
Establish Open Communication
Establishing open communication lines is critical to DevOps, and no less so with external contractors and service providers. This open dialog should start at the planning stages, working together to establish common goals and expectations, including timelines, work methods, pace of delivery, and generally ‘how things work.’
I recommend connecting face-to-face if at all possible, even if you can only do it once or twice, whether you meet at their place or they come to you. There is something special about meeting in person that brings to life many important DevOps concepts – like empathy, sharing, communication and cultural understanding.
For large and globally diverse teams, in-person meetings can be cost- and time-prohibitive, but you can also achieve similar outcomes through virtual conferencing. Here I recommend immersive ‘tele-presence’ style systems, rather than the more common ‘cheap-and-cheerful’ web conferencing tools. Grainy headshots taken with low-res webcams, displayed seven-to-a-row in tiny windows, simply will not create the deep personal connections the same way as high fidelity communications.
Maintain Ongoing Collaboration
However, inexpensive web-based technologies are ideal for maintaining ongoing collaboration, once you have established those initial lines of communication. Use web–based video-conferencing to bring external consultants into your teams’ regular communications, from planning sessions and standup meetings to post-mortems and ad hoc chats.
Also consider integrating external teams into your internal messaging systems, providing them with corporate e-mail addresses, including them in mailing groups and directories, connecting them to your chat and IM applications, and providing access to collaboration tools like shared workspaces and shared storage. None of this requires them to be on-site, or even in-country, but will help immensely to make them part of a collaborative, integrated team.
Share Access to Internal Technologies
Speaking of technologies, I have also seen multi-national and other cross-silo teams using common tools to share SDLC activities, status reports, system views, operational insights, and even vocabularies. Sharing access to common tools between contractors and employees alike – for example to share goals and assignments during planning, manage and report on project or backlog status, check code in and out, perform QA and integration tests, integrate new code into existing repos, release code updates into QA or prod, monitor and triage operational performance, or provide feedback from one system or team to another – definitely helps to connect and integrate external teams with internal teams.
Share Processes with Automation Tools
Automation tools in particular will help to integrate third-party contractors into established DevOps practices and processes. Shared automation allows you to make your ‘known-good’ processes a repeatable and reliable shared resource to all your teams, internal and external. Providing shared access to automated processes for check-out/check-in, code integration, test data management, provisioning and configuration, code release, and more helps external teams to adopt the same approaches, and implement change in the same ways, as internal teams – while also providing essential audit and control.
Use Virtualization to Span the Globe
Virtualization technologies especially will help to abstract internal environments for external workers – across the street or across the globe. Server and OS virtualization (and related approaches like containerization and cloud computing) allow easy exchange of common platform and build environments; network virtualization allows remote teams to code for abstracted internal networks; service virtualization allows multiple teams to develop and test in parallel even without shared access to internal systems; virtual storage allows teams to easily swap in or out common shared datasets; exposing functions or microservices as virtual APIs allows remote specialists to work independently yet still leverage others’ work; and of course virtual private networks allow secure access to internal systems for remote users anywhere.
Find Your Own Approaches
Fundamentally, there is no reason DevOps will not work with external contractors, consultants, vendors and service providers. Communication, collaboration and integration can certainly face new barriers at the enterprise’s edge, but these are not insurmountable. Ultimately you must find approaches that work for your enterprise – and I would love to hear about them in the comments below or on Twitter – but if you establish mutual goals, ongoing communications, common processes, and shared tools, you will be well on the way.
