This article gets into the most important part of preparing the Statement of Work (SOW) with a vendor, and how you need to protect your business from the factors that could be lost in translation as you are getting excited about using this vendor’s APIs and UI interface.
Yes, you need to analyze this vendor’s APIs and see if their business model fits into your business model.
Yes, you need to analyze the vendor’s front-end tool that business could be using and you need to make sure that it will meet your requirements.
Yes, you need to make sure that the vendor’s overall feature set will meet your requirements or they have a roadmap where in short-term they will have features that you will need.
Yes, you need to identify what custom items your vendor will need to implement and fully understand their timelines and those timelines align with your timelines.
Yes, you need to identify the level and type of engagement. There are companies that are still based on the waterfall approach and that might fit well into your agile methodology and how engineers in your company approach software development.
However, the most important thing that needs to be specified in the SOW is the performance and load metrics that this vendor can handle. None of other things matter if this is not satisfied. You can spend weeks and months developing the system on your side integrating with this vendor’s APIs and it will all work fine in pre-production environment. Then when you deploy your code to production, you may realize that the performance is not on par and then you end up polluting your design by introducing crow-bars in your code in order get around these deficiencies. All of this can be prevented by spending time with the vendor’s engineers and first understanding the performance and loads they can handle. Then ideally you would want to perform the actual load test with them. Then all of this needs to be specified in the SOW.
Thank you for reading.
Almir Mustafic.
No comments:
Post a Comment