Architects, Are you Applying Logic During your M&A?

I was working as an Enterprise Applications Architect when the company announced it was being taken over. Below is my take on the value of Enterprise Architecture at this time and what to expect:

1) Fill the Void
One lasting memory is the appearance of a complete absence of leadership. I say appearance, because good managers don’t turn ‘bad’ overnight – but the rules around communications change. Rumours of people losing their heads – trying to work out who to serve – spread fast. It can be a pretty horrible place to work at times. Those that step up and rise to the challenge however, come out of things much better off. It is important, in my view (not shared by all those around me), to shake off any loyalty to the decisions of the past. That was then, this is now. Get over any mourning of ‘not the company I joined” as quickly as possible.

Find out the overarching philosophy. Sometimes a takeover is business as usual, with one company operating as a nearly independent subsidiary. Where two near identical companies are merging, there is often an aim to collapse the back office together, to achieve synergies. Front of shop departments may well get the same treatment. The following advice is aimed at architecture teams helping with identifying ‘synergies’. In advance of the overarching philosophy becoming clear, work on parallel scenarios, or run with the most likely option. It’s easy to find reasons to sit and wait, but that may not help your team, or your career.

2) Big Architects Value in Logical Models
In my experience, all of a sudden – people want to know three things, and the Architecture team is ideally placed to answer them. Be ready for the spotlight. (If you’re not in the spotlight then step forward – fill the void). This will happen whilst all the regulatory approval is sought.

– What systems are ‘we’ using vs what systems are ‘they’ using?
– How much does each cost us? Annual run rate is useful to know, and being able to estimate it quickly will be of value.
– What projects should we kill right now, and what do we definitely not kill?

Work hard on your logical architecture models – for the revised scope of the entire ‘new’ enterprise, and for each department. A logical model is an abstraction of what the systems do. High level buckets of business functionality, on a single page. If you don’t understand the strengths and weaknesses of your own apps in these areas, then get investigating. People are surprisingly willing to talk during M&A – some are crazy-busy but many have suddenly a lot of time on their hands. (YouTube gets a hammering.)
With your logical models in hand, at a functional level or lower, map on your systems, and their systems. This will enable a comparison – and to help structure discussions about which to keep. If you aren’t privy to the details of ‘the other side’ yet, then look in the public domain. Our team found out an awful lot through vendors websites, linked in profiles (look at skills and experience of current and former employees), and blogs.

Logical models also provide a map of how your organisation is run, its objectives, and a rating of capability for people processes and systems. If you’re in a federated / regional structure variation by region will help inform on the different characteristics and ways of working. It’s an opportunity to show the other side of what the organisation is really made up of – the good, the bad and the ugly. Now is not a time to be proud or defensive. The other side want to understand all this as quickly as possible.
Share as much as possible with those around you and above you. There are obviously legal rules on what you can and can’t share, but make sure you push things to the limit on this, as your primary value to the organisation is in communicating to each side what the other has. As soon as the wall comes down, legal day one, get out there and start sharing knowledge. The best way to combat the uncertainty of a merger is through communication.

When it comes to measuring cost – this can get very thorny. We heard some ridiculous figures bounded about, and others shrouded in secrecy. It is so easy to get a figure, but so hard to get an apples with apples comparison.  Architecture plays a role here in both clear articulation of scope, and also in the relationships between costed items that make up a service. A good view of when contracts expire – mapped over the top as a layer on a logical model is a useful artefact to build with the procurement department.

3) Federate the Architecture Work
Enterprise Architecture teams are used to focusing on the horizon which is usually 1-3 years away. All of a sudden your horizon gets sucked in much closer. Strategy work shouldn’t be rushed, but you are suddenly working at warp speed. You cannot do as thorough a job in so many areas, in such a short time. People want answers quickly, so being able to balance rigour and quality with speed will stop you getting bypassed. A focus on ‘good enough’ to reach conclusions will win the day/ suffice.

It isn’t all bad though, the business are suddenly so much more engaged. They all want to make decisions as fast as possible around applications landscape and architecture, and few of them really know what you know; the kinds of information required to make a decision and build a business case for change.

My advice would be to show your business colleagues the architecture method, and work with them to co-create the target state. For the smaller departments, given the pressures of time, you may want to just let them run with it. Encourage them to work on a ‘current best view’ rather than waiting for things to be perfect before sharing. Keep tabs on them, help them as much as you can, and collect their output to communicate the holistic picture. Share with each department the kinds of things other departments are grappling with and the principles that emerge to help decision making.

The hard part is going round again, after the target state has shaped up, synergy targets have been identified, allocated, and are already being traded. After all the initial panicked enthusiasm has died down, you need to start checking the assumptions made. New information and clarifications in strategic direction come to the fore quickly. Strategic decisions have knock on impacts and this second run through is important to identify those.

By this point, you and your business colleagues may have one eye on the exit door, and all sorts of difficult behaviours make your job all the harder. It’s at this stage I left my (permanent) role as an Enterprise Architect to join North Highland. I wish I had been bolder back in those uncertain times at positioning the role of architecture with leadership, at sharing the findings more broadly, and in getting going with the second round of refining the initial target state.

To conclude, M&A is a good reason to get everyone involved in architecture. It is acutely relevant to so much of the organisation. A decent logical diagram combined with a clear, repeatable approach can go a long way to getting the team noticed, and staking a claim for a role in the future organisation.

Related Reading