When we think about maintaining a software solution holistically, we have to think about things like non-code change control and configuration management, in addition to the actual source code. For example, for maintaining a large web application, tracing:Make the following (manual) configuration change to the farm, as part of deploying this specific xx.yy.zz version of the solution package.I've implemented a fairly good model for this, but now I'm tackling the next largest problem - how do we manage changes in other systems we don't own? Let's take a simple example:We have an ASP.NET application owned by a solution team (let's call them the PLM Team). Their next release includes a change that requires the SAP team (which is under a different maintenance umbrella) to also deploy a change to one of their BAPI endpoints.Of course the actual coordination of the deployment at release time is simple human interaction & coordination, but in terms of the total SDLC:How does our example PLM Team package & trace this dependency as an artifact, both as an upcoming change and, post-deployment, a managed dependency with requirements they own but an implementation they do not directly control?What is the right information to capture about it? How should it be treated differently than non-code configuration items they do control?
Maintenance model for external artifacts
development process;maintenance;enterprise architecture;sdlc