Knowledge Management – Foundational to Enterprise Architecture

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.

 

Knowledge Management: The Other Side of the Enterprise Architecture Coin

I have two passions in my professional career.

The first is Enterprise Architecture (EA). I have been interested in this subject for the past thirty years. This passion started when I designed a system supporting the risk analysis and decision support requirements for an insurance enterprise. As I have continued my career, I realized that architecture had more to do than just with systems. It needed to understand the business and processes supported by those systems.

My other passion is Knowledge Management (KM). I became interested in this subject in the early 1990s when the ideas began to emege within the business and technology communities about the necessity to preserve the knowledge in the heads of the baby-boom generation as they began to retire. We are now about 25% of the way through that wave of retirements. How is your knowledge management program working?

Rather that being torn over which of these passions to pursue or spending only half of my time on either, I have determined that EA and KM are two sides to the same coin. It is my belief that in order for an EA program to look forward and take the enterprise into the future, it must be built upon a foundation of understanding the enterprise’s current state and how it got to be there. This requires a comprehensive knowledge management program.

I have also determine that EA and KM must be integrated. This is because EA relies on existing knowledge that has been preserved and managed in order to understand how to move forward and the act of moving forward creates new knowledge that must be preserved and managed. Unless these two activities are tightly integrated, there exists the probability that the KM knowledge base will grow further and further out of synch with the reality of the enterprise as it progresses. This then inhibits the EA function’s ability to utilize up-to-date knowledge as the enterprise makes new moves forward.

I plan to write a new set of essays about how EA and KM feed each other and how they can achieve the level of integration required to make them two sides of the same coin. Please look for them in the coming months.