Skip to main content
Software Engineering

Return to Answer

edited body
Source Link
Robert Harvey
Robert Harvey
  • 200.7k
  • 55
  • 470
  • 683

I have dealt with this in the past by using what iI believe someone in the comments referred to as "shadow IT". If we need something done by one of the large lumbering orgs, we figure out a way to do it just well enough to get us what we need at the time, and plan to integrate the result from that external team at some point in the future.

For example, if we were to need to get a new VM to run a binary package server (nuget, etc.), but we know that can take a month, we would first set one up somewhere that we have control over. I think of that as prototyping, so that we can make sure it works before we make a potentially expensive request to IT. We make sure to implement things on our side so that we can easily switch the "real" server once it's in place.

You could do the same thing if you have a dependency on getting a database configured. Do it on a developer box for a while, then switch to the "real" one once it's available.

An advantage to this approach is that you can work at your own pace, and it sort of forces you to make sure the systems you design aren't heavily intertwined.

I have dealt with this in the past by using what i believe someone in the comments referred to as "shadow IT". If we need something done by one of the large lumbering orgs, we figure out a way to do it just well enough to get us what we need at the time, and plan to integrate the result from that external team at some point in the future.

For example, if we were to need to get a new VM to run a binary package server (nuget, etc.), but we know that can take a month, we would first set one up somewhere that we have control over. I think of that as prototyping, so that we can make sure it works before we make a potentially expensive request to IT. We make sure to implement things on our side so that we can easily switch the "real" server once it's in place.

You could do the same thing if you have a dependency on getting a database configured. Do it on a developer box for a while, then switch to the "real" one once it's available.

An advantage to this approach is that you can work at your own pace, and it sort of forces you to make sure the systems you design aren't heavily intertwined.

I have dealt with this in the past by using what I believe someone in the comments referred to as "shadow IT". If we need something done by one of the large lumbering orgs, we figure out a way to do it just well enough to get us what we need at the time, and plan to integrate the result from that external team at some point in the future.

For example, if we were to need to get a new VM to run a binary package server (nuget, etc.), but we know that can take a month, we would first set one up somewhere that we have control over. I think of that as prototyping, so that we can make sure it works before we make a potentially expensive request to IT. We make sure to implement things on our side so that we can easily switch the "real" server once it's in place.

You could do the same thing if you have a dependency on getting a database configured. Do it on a developer box for a while, then switch to the "real" one once it's available.

An advantage to this approach is that you can work at your own pace, and it sort of forces you to make sure the systems you design aren't heavily intertwined.

Source Link
Jon E
Jon E
  • 51
  • 2

I have dealt with this in the past by using what i believe someone in the comments referred to as "shadow IT". If we need something done by one of the large lumbering orgs, we figure out a way to do it just well enough to get us what we need at the time, and plan to integrate the result from that external team at some point in the future.

For example, if we were to need to get a new VM to run a binary package server (nuget, etc.), but we know that can take a month, we would first set one up somewhere that we have control over. I think of that as prototyping, so that we can make sure it works before we make a potentially expensive request to IT. We make sure to implement things on our side so that we can easily switch the "real" server once it's in place.

You could do the same thing if you have a dependency on getting a database configured. Do it on a developer box for a while, then switch to the "real" one once it's available.

An advantage to this approach is that you can work at your own pace, and it sort of forces you to make sure the systems you design aren't heavily intertwined.