Acquisition playbook

ARCHIVED

This section is out of scope for the initial effort that produced the authoritative data design, and as such is just a sketch of the goals of an acquisiton playbook we should create in tandem with any efforts by Corporate Development.

We highly recommend that UTA consider buidling out "Acquisition as a Service" within the Tech group, and ultimately, in the corporate functions (legal, HR, comms, etc) as a whole. Most companies of UTA's size are still using ad hoc approaches; UTA would gain considerable advantage by creating a repeatable, predictable process.

UTA routinely acquires companies as part of its business strategy. It is exceptionally important that these acquisitions be integrated into UTA consistent with the terms of the deal. Anything Tech can do to reduce integration friction will result in a superior business result:

• more informed due diligence ("how hard is this going to be?")
• a faster deal close
• a better experience for the new colleagues
• less chance of UTA becoming bogged down maintaining multple legacy IT infrastructures

Ideally, the Tech team would have playbooks "productizing" the major Tech integration workstreams:

• Identity (get them logged in)
• Collaboration (get them email and conferencing)
• Endpoint provisioning and conversion (get them laptops)
• Data integration (move their existing data to authoritative data and other transactional stores)
• Application rationalization (Move the acquisition target's legacy apps to UTA systems)

Integration styles

It would be naive to put together a playbook that assumes that all acquisitions will be integrated in the same way. Assuming this hasn't been done already, we would recommend that UTA identify the key integration "styles," and for each of these styles the steps in the playbook are different.

For example, a high level diagram (again, just for Tech workstreams) could be constructed:

	Level 1	Level 2	Level 3
Typical deal type	Joint venture	Subsidiary	Full acquisition (the old company disappears)
Identity	N/A	Maintain old domain but decomm old identity system	Move to UTA domain and decomm old identity system
Collaboration	N/A
Endpoint Provisioning	N/A	Web-based access to UTA systems	Reclaim all laptops and replace with UTA hardware
Data integration	Reports send to finance	Seperate entity in finance systems	Convert completely to UTA authoritative data
Application rationalization	N/A

UTA must first secure business buy-in on this high-level approach, and then each box in the diagram can be designed and built out.

Data integration

Data integration should be the scope of this document shouid UTA decide to move in this direction.

UTA would standardize the way it interviews and analyzes the acquistion target's tech team and stacks to get an idea of the scope of effort required to move the data to UTA's authoritative data model, and to build an understanding of what applications and processes will "break" as a result.

Authoritative data integration is a prerequisite to the other steps. The faster UTA moves an acquisition target to authoritative data, the faster application integration can proceed, and the faster UTA will get the target off its old systems.

Regulatory Issues

Regulatory scrutiny of acquisitions may or may not become a factor. If it does, the playbook would need another dimension involved with preparing for regulatory review.

A robust authoritative data system will help UTA respond to regulatory inquiries:

• When asked for data, UTA will have it in a single place
• When asked for models and documentation, UTA will have the full design (you're reading it now!)
• UTA will have a central place to track privacy and compliance status (e.g., "Have we sent privacy compliance notices to all clients who reside in New York state per local law?")

Privacy and compliance are beyond the scope of the initial authoritative data design engagement, so we're just sketching out the key issues here.