Articles for December 2016

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.


Know What You’re Buying

I had a conversation earlier this month with a colleague, Marc.  He is active in the Enterprise Architecture forums on LinkedIn.  Marc asked me to review some material he had developed for a book he is writing.  We had been corresponding for a while but we decided to conduct a call for a more free form discussion.

Marc’s work will fill a large void in the book of knowledge for EA.  He is working towards definitions of Enterprise and for Enterprise Architecture.  I applaud him for his efforts and respect him for the amount of grief he takes on trying to vet his ideas in a forum with worldwide reach.  There are many people in the EA world who are too deep into the weeds to have a strategic view of the Enterprise, what it does, and how it should do it. Marc’s book will hopefully re-calibrate those discussions.

One thing became evident in our discussion.  Marc and I have different views as to what architecture means.  We both use the ideas of structure, architecture, and documentation when we discuss the domain of the Enterprise Architect.  I use structure and architecture synonymously  to describe the state of the enterprise.  I believe the failings of EA to gain traction in many organizations is that the architects are always trying to define the end state while ignoring the current state.  You will find more about my thoughts here.  The bottom line is I think you need to completely understand your current state before you can move the enterprise to a new place.  You gain that understanding from documentation.

Marc understands structure and architecture to be different concepts.  Structure is the state. Architecture is the documentation.  You can read his work on LinkedIn to get into his development of these ideas.

I don’t think either of us is wrong.  I know that our approaches are different.  As the buyer of EA services, it is incumbent on you to understand what the practitioner is selling and how he will deliver his work products.