I once worked for a company that was in the Mergers & Acquisitions business. Their strategy was to build a large company by acquiring smaller companies and consolidating their operations to save costs. Several teams throughout the organization who responsible for the various projects required to complete the assimilation of each acquisition.

It quickly became apparent to the employees at each acquired company that the consolidation would result in most of the people there losing their jobs. Our company had a team whose job was to move quickly to collect as much knowledge as possible from these people before they left. We documented most of this knowledge using the EVP method (Excel, Visio, PowerPoint).  The goal was to quickly learn how the acquired company operated and then pick it up, move it, and operate it in our location.  The intent was that the customers wouldn’t notice the difference.

As you can imagine, the architecture of our company changed with each acquisition.  We kept our own documentation as the collection of EVP artifacts gathered from each company we acquired.  We never integrated these documents and thus our company became harder and harder to manage and never really understood our enterprise or its architecture.  Eventually, this lack of understanding lead to management mistakes that ultimately contributed to the demise of the company.

Senior management was running an M&A business.  Middle management was trying to run a customer servicing business because the companies we were buying had existing customers that we wanted to leverage and whose products needed to be serviced.  The needs of the former drove the complexity of performing the latter through the roof.  Our environment devolved into a situation where it took twenty-four months to fully train a customer service representative (CSR).  The average tenure expectancy of a CSR was about seven months.  Talk about a death spiral!

Management decided to consolidate business onto several strategic platform systems in order to simplify.  These projects were very complex. They required often dirty data to be moved into new data structures and business rules embedded deep within very old code bases to be harvested and re-implemented.  These physical realities would not be fully documented during the business consolidation efforts that had occurred years prior, the documentation for which may or may not had been readily available.  Needless to say, things didn’t always go well.  There were times when our new processing deviated from the contractual requirements of the products. This led to numerous lawsuits and distracting litigation.

I formed my views on Enterprise Architecture in this environment and developed my sense that EA must be driven by the business.  An enterprise is not a static object.  Most are not as dynamic as the one i describe above but they are all constantly changing and adapting to new realities they face daily.  There is some business manager in your enterprise who is fighting for his very survival.  He really doesn’t care about your big plans to move the enterprise forward in a rational way.  He finds you to be totally irrational because you are more worried about your needs than about his.

I am not saying that you shouldn’t try to have some grand plan.  I am saying that your plan must account for those daily realities and consider them part of your challenge and not a distraction to your work.  In order to do that, you must completely understand your current environment regardless of how it came to be.

This is more of a knowledge management exercise than it is an enterprise architecture exercise.  This is a situation not well served by the EVP methods most of us have employed in the past and are probably still using.  What we need is a way to quickly gather data about our enterprise and to quickly update it as things change.  This data must be integrated and available for analysis. We then need to use it to develop plans that resonate with the business leaders by addressing their needs.  EA must become part of the strategic business planning process through its role as curator of knowledge.  This will enable the architect to gain a seat at the executive table in order to facilitate change.

Knowledge Management, that’s the fuel for complete understanding.

 

Leave a reply

required

This site uses Akismet to reduce spam. Learn how your comment data is processed.