How to Manage Successful Tech Outsourcing Partnerships
Delivering software that is critical to your digital business growth and transformation relies on your own operations model as well as a network of reliable and trusted IT service providers to outsource all or part of your digital requirements scope.
Maintaining a healthy relationship with those potential partners relies on clarity of purpose, scope, and communication. That sounds logical and simple.
However, reality is not that straightforward and I am sure your own experience managing numerous digital and IT projects have led you here to find solutions to the typical challenges that plagued your capability to deliver the desired results.
So, what are the most important things you need to watch out for when outsourcing to IT service providers?
Read on...
1. Project Code Implementation
Enforce project code to be implemented at your own code repository and not on the provider.
Setting up an enterprise account on bitbucket and hosting all your project codebases there is strongly recommended. Get any third party to write the code on those repositories only so you’re able to track code commits and software commit processes.
2. GIT Access and SSH Keys
Get any software team members working from a third party to submit their ssh keys to issue git access.
More common than not, Git access can get messy especially when you have internal and external software engineers working together. Its very important to streamline the access directly from engineering teams' machine SSH keys to ensure that they can be revoked and refreshed should any issue arise.
If you’re using GitHub, you can follow those steps to issue and add SSH keys to your github account.
3. Documentation. Documentation. Documentation.
Ensure that your software managed teams submit and maintain the following documents:
Software Technology Stack document: This should list all technologies used on all components of the software.
Software/App Architecture document: This should list the design of the platforms. Components and software communications design and anything that should be understood on the application level.
Infrastructure Architecture document: This should list the design for the servers, networking, database and all infrastructure related items for each of the environments the projects is running (Dev, staging and production). This should also include: Network firewall rules, exposed posts, DNS records for all public facing URLs and Load Balancers.
Release Management document: This document represents how the teams release software to any of the target environments. The Release Management document should at least feature:
- Software build process including branching for each environment.
- Server roll out procedures. Basically how the new release or code is released to the servers.
- General Pre release checklist
- General Post release checklist
4. Ongoing IT Support Tools Needed
- Quality assurance requirements are quite important and a full test plan should be requested and maintained by the partners. This can be in the form of an excel sheet that QA teams run on each release or one of the many test pan systems in the market.
- CI/CD (continuous integration / continuous delivery) pipelines. This is crucial to ensure software releasing is actually automated and doesn’t require manual or human intervention.
5. Accessibility and Security
As project owner; accessibility to all tools will be critical to ensure hassle free transitions and change management. A common scenario to highlight is when you’d be forced to quickly ramp up your teams and resources; the last thing you want is the hassle of seeking access.
Important tools that you must always have access to include:
- SSH or VPN access to the main platform infrastructure that is correctly rotated.
- Access to the kube config or the deployment code base
- Access to the main logs server or software (sentry, kebana, log stash, or just plain server logs server)
What should you require from your partners:
- Monthly owasp zap report. Code changes happen and gets released on each sprint and very often than not new security vulnerabilities will pop up continuously. Oswasp zap gives your the lowest barrier but is indicative of in your face problems that can ring the alarms.
- Their secret keys management. Given the number of environments and tooling associated with it. How does the partner store, rotate and injects the passwords and main keys to the code build. Do they use a key rotation schedule, or do they use host password software.
6. Protecting Intellectual Property and Codebases
Typically when you work with partners and vendors, you will host very precious intellectual property at their premises, and its very important to make sure they have the basic governance in place to protect your intellectual property and codebase.
The following are the minimum confirmations you should get when attempting a partnership.
- Do they have a secure firewall on their network and are they designed to monitor internal traffic?
- Do they have physical access control?
- Do they have a laptop access policy or are they co-sharing machines?
- Does your software only run on the target environments that are agreed by your company?
7. Mobile and App Management
Mobile app distribution is as important as everything else. Here are the top things to make sure your partners are working against:
- No manual distribution of apps. Apk or otherwise.
- Make sure the partners are using a proper distribution platform like app center, testapp.Io, google play store or a comparable tooling.
- Just like with the CI/CD, it is encouraged to also build the app by code so we can always have a programmatic way to generate targets.
- You will need to keep track of all members internally or externally who installed unverified builds (in testing builds) and have a log of their phone IDs.
- Their formal procedure to submit the app on the stores and their API backward compatibility checks before production releases.