There was a challenge I posed to the list called Moving Sale:

Continuing the theme of the week lets look at what prep work would be required prior to the close of the sale. In this case, Acme Inc. went in on the cloud software offering by offering Anvils as a Service, and this will be offloaded to Widgets Inc. as its own unit including about half the current employees working on the product. The product itself is also cloud based, but runs on a different cloud provider from what Widgets Inc. uses.

What common pieces would be impacted as a part of this carve-out, but would not be conveyed to Widgets Inc.? As a follow-up question, would you make the common pieces available, and if so, how?

The first part of the answer looked at the end user/employee aspect as common enterprise data where nothing else would be conveyed so it would be up to the acquirer to figure out how to integrate. The second part looked at the tech side of users not just as users, but also their underlying data. The third part looked more at the applications themselves.

I was about to end it there, but forgot the follow-up question of whether to make the common pieces available.

This along with the rest of part 3 would require some context. In most of the scenarios, it would normally be a flat no as most common components are very much company/org specific.

…yeah but…

With code, and even with codified infrastructure using tools such as Terraform, there is the concept of DRY: don’t repeat yourself. This provides the common infrastructure required for custom apps to interoperate within a shared ecosystem such as a common identity provider like Okta or a common cloud provider like AWS.

The plus side is that there is a way to make the common parts accessible without giving them your custom logic. In a lot of environments, there is a concept of interface libraries. This is a contract between the code and the service that dictates the inputs, outputs, and expected data. By exposing just the interface, the application may not even need to be touched, but the integration team will need to have an implementation ready to go such that the custom applications being conveyed can be migrated with the minimal amount of work required.

What could qualify?

  • Identity access management (authentication/authorization)
  • Database access
  • Cloud based infrastructure services (AWS vs Azure for example)

Mainly, any integration points involving a third-party is fair game, but especially parts where your organization has a pre-defined pattern for how to access the resource and what to look for.

What other things can you think of? Reply and let me know so we can keep the exchange going!

cab