␡
- 1.1 Building a Site from Scratch
- 1.2 Growing a Small Site
- 1.3 Going Global
- 1.4 Replacing Services
- 1.5 Moving a Data Center
- 1.6 Moving to/Opening a New Building
- 1.7 Handling a High Rate of Office Moves
- 1.8 Assessing a Site (Due Diligence)
- 1.9 Dealing with Mergers and Acquisitions
- 1.10 Coping with Frequent Machine Crashes
- 1.11 Surviving a Major Outage or Work Stoppage
- 1.12 What Tools Should Every SA Team Member Have?
- 1.13 Ensuring the Return of Tools
- 1.14 Why Document Systems and Procedures?
- 1.15 Why Document Policies?
- 1.16 Identifying the Fundamental Problems in the Environment
- 1.17 Getting More Money for Projects
- 1.18 Getting Projects Done
- 1.19 Keeping Customers Happy
- 1.20 Keeping Management Happy
- 1.21 Keeping SAs Happy
- 1.22 Keeping Systems from Being Too Slow
- 1.23 Coping with a Big Influx of Computers
- 1.24 Coping with a Big Influx of New Users
- 1.25 Coping with a Big Influx of New SAs
- 1.26 Handling a High SA Team Attrition Rate
- 1.27 Handling a High User-Base Attrition Rate
- 1.28 Being New to a Group
- 1.29 Being the New Manager of a Group
- 1.30 Looking for a New Job
- 1.31 Hiring Many New SAs Quickly
- 1.32 Increasing Total System Reliability
- 1.33 Decreasing Costs
- 1.34 Adding Features
- 1.35 Stopping the Hurt When Doing This
- 1.36 Building Customer Confidence
- 1.37 Building the Teams Self-Confidence
- 1.38 Improving the Teams Follow-Through
- 1.39 Handling an Unethical or Worrisome Request
- 1.40 My Dishwasher Leaves Spots on My Glasses
- 1.41 Protecting Your Job
- 1.42 Getting More Training
- 1.43 Setting Your Priorities
- 1.44 Getting All the Work Done
- 1.45 Avoiding Stress
- 1.46 What Should SAs Expect from Their Managers?
- 1.47 What Should SA Managers Expect from Their SAs?
- 1.48 What Should SA Managers Provide to Their Boss?
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.9 Dealing with Mergers and Acquisitions
- If mergers and acquisitions will be frequent, make arrangements to get information as early as possible, even if this means that designated people will have information that prevents them from being able to trade stock for certain windows of time.
- Some mergers require instant connectivity to the new business unit. Others are forbidden from having full connectivity for a month or so until certain papers are signed. In the first case, set expectations that this will not be possible without some prior warning (see previous item). In the latter case, you have some breathing room, but act quickly!
- If you are the chief executive officer (CEO), you should involve your chief information officer (CIO) before the merger is even announced.
- If you are an SA, try to find out who at the other company has the authority to make the big decisions.
- Establish clear, final decision processes.
- Have one designated go-to lead per company.
- Start a dialogue with the SAs at the other company. Understand their support structure, service levels, network architecture, security model, and policies. Determine what the new model is going to look like.
- Have at least one initial face-to-face meeting with the SAs at the other company. It’s easier to get angry at someone you haven’t met.
- Move on to technical details. Are there namespace conflicts? If so, determine how are you going to resolve them—Chapter 8.
- Adopt the best processes of the two companies; don’t blindly select the processes of the bigger company.
- Be sensitive to cultural differences between the two groups. Diverse opinions can be a good thing if people can learn to respect one another—Sections 32.2.2.2 and 35.1.5.
- Make sure that both SA teams have a high-level overview diagram of both networks, as well as a detailed map of each site’s local area network (LAN)—Chapter 7.
- Determine what the new network architecture should look like—Chapter 7. How will the two networks be connected? Are some remote offices likely to merge? What does the new security model or security perimeter look like?—Chapter 11.
- Ask senior management about corporate-identity issues, such as account names, email address format, and domain name. Do the corporate identities need to merge or stay separate? What implications does this have on the email infrastructure and Internet-facing services?
- Learn whether any customers or business partners of either company will be sensitive to the merger and/or want their intellectual property protected from the other company—Chapter 7.
- Compare the security policies, mentioned in Chapter 11—looking in particular for differences in privacy policy, security policy, and how they interconnect with business partners.
- Check router tables of both companies, and verify that the Internet Protocol (IP) address space in use doesn’t overlap. (This is particularly a problem if you both use RFC 1918 address space [Lear et al. 1994, Rekhler et al. 1996].)
- Consider putting a firewall between the two companies until both have compatible security policies—Chapter 11.