change control 3rd party apps

How does (or perhaps should) change control work for applications your users use which arent owned/hosted by yourselves. Say for example a key application which is a web based app hosted on someone elses infrastructure. When they announce they are due to move to a new release and upgrade their system - how should that tie in with your internal change control systems? As the end of the day your end users could still be affected.

I know one element of change control is user acceptance testing - which again I find hard to see how and when you get the opportunity to do so when the system is external.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
that is is especially relevant when your organisation  e-Services and online digital asset are dependent on their functionaity. E.g the use of their service for searching, calling their exposed API, using their content mgmt web service, etc. it is less impactful if it is mainly change of apps that is solely used as general public (but not the case if it is heavily customised for your organisation e.g. a specially whatsapps features created and embedded in that special version..).

Looks like the prior notice need to be concurred way up front in legal terms and contractually binding for back to back support trial prior to release in production. The SLA and helpdesk must be able to handle in specific to such FAQ in each changes including for emergency patch due to exposed security vulnerability in their apps or services (known to them private to them initially). they need to notify with rationale to end user on severity and impact where applicable - best have it black and white as obligation. Of course this will also depends on the tier of level signed and procured in the agreement.

For example, Google Apps has such incorporation for material changes to inform user early - see the "Modifications"  and "Change of Control" @

in related note for third party software usage, such prior use will already have you agreed to their "EULA" that accepted the proper use and actually you may not have say beforehand (e.g. use at own risk). Like the recent heartbleed and shellshock case,  we are all end user and left to "fate" of supplier whom used such libraries or related platform to give the consumer the remediation piece...esp relevant to open source community where it is understood the public already has the right to use the program (e.g. under the GPL), and this right cannot be withdrawn.

It is tough to full control except to establish back to back support and prior notification to cater for the changes required. Commerical binding will still be good to maintain as leaving it open and free are assumption that will (definitely) be binding and break in time of emergency or dispute. We want to avoid (or minimize) that . Here is another article for sharing - note we also need supplier (whoever giving the 3rd party services) to ensure integrity of the service (and not backdoor0ed)
A good practice is to make sure that such components are declared well in advance before you sign an agreement to source software, specifically if there are inherited restrictions or obligations pushed on to you and your customers. Make sure that the sourced software doesn´t come with an undetected Hydra-head embedded in the license. If there is Open Source with obligations to disclose code to end-users this will affect you or your customer, or your customer’s customer.

You will then be able to anticipate what distribution rights must be catered for in the contract, and to prepare for a change in the process if you cannot win these rights in the license.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
David Johnson, CD, MVPOwnerCommented:
When they announce they are due to move to a new release and upgrade their system - how should that tie in with your internal change control systems? As the end of the day your end users could still be affected.

you pretty much have to start from scratch every time they do a change.. and live with it.. you may have to work around things..  but you have absolutely no control except with your wallet.  Perhaps you could negotiate getting beta acceptance for your testing prior to the change over.
btanExec ConsultantCommented:
i will also add in the case for any changes, there is always the agreement whereby if there is direct contact the provider or the main supplier whom you signed off with, they must still in no circumstances, in breach or not able o fulfill the service level of proper testing and releases - you own internal user testing is transparent to them and they would be more of answering to you so you have to manage it. If the service need to go proper test lab, they have to do so as the contract is based on "cleared" product on signing and changes may indirect be non compliant..
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.