Knowledge Management – Foundational to Enterprise Architecture

Date: December 26, 2016 Author: Jeff Comments: Leave a reply

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.

Innovation and Transformation

Date: September 3, 2016 Author: Jeff Comments: Leave a reply

I was flipping through my social media accounts this morning and the theme of the day appears to be “innovation” and “transformation”. They were used in articles in contrast like maybe they were similar but different. I looked up the definitions of both terms in the dictionary.

Innovation (noun) – something newly introduced; such as a method or device.

Transformation (noun) – a marked change, as in appearance or character, usually for the better:

Granted, I picked the definitions but I used those that didn’t describe either term recursively. Here’s what I get: an Innovation is a new thing and a Transformation is a changed thing. So I guess they’re not really similar but they certainly are different. But they still might be related.

So what’s this got to do with Enterprise Architecture? I think it’s this…

Your future state is your innovation. You aim to create something new. Most enterprise architects are satisfied with this and set out to build this new thing.

Unfortunately, if you have an existing business, your starting point is not your blank canvass or empty project file. You need to start with where you are now. That’s your current state. The plan that gets you from your starting point to your end point or from the current state to the future state is that which generates that marked change. It’s a transformation.

You must completely understand your current state in order to build that transformational plan. That’s business-driven enterprise architecture. That’s complete understanding.

Knowledge Management: The Other Side of the Enterprise Architecture Coin

Date: August 14, 2014 Author: Jeff Comments: Leave a reply

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.

The Business Calendar

Date: April 1, 2014 Author: Jeff Comments: Leave a reply

Every living being has an internal clock that wants to regulate its habitual patterns. It’s called the circadian rhythm. We humans are much healthier when we allow our circadian rhythms to regulate how we live each day. Usually, we use use artificial means to awaken us earlier (e.g. alarm clocks) and stay up later (e.g. stimulants) which serves to make our bodies work less effectively because we have thrown them out-of-rhythm.

Many animals also have a circadian-like calendar that helps them manage from one year to the next. Their bodies read the changing seasons and tell them to gather food, go into hibernation, and awaken the next year. Enterprises also develop a natural annual rhythm that I call the Business Calendar.

Every Enterprise should develop, publish, and understand its business calendar. For most Enterprises, the calendar should focus on the Production Schedule. Production Schedules are easy for manufacturing concerns because that’s what they use to run the shop. They might not be so easy for service concerns because they view things more like a job shop than as a factory shop. However, recognizing your Enterprise’s ability to be distracted by non-production work is very important regardless of the type of business in which you engage.

The Business Calendar should consider the following factors:

The capacity of each department to accept non-production support work through out the year. This should be measured against the permanent staffing levels approved for each department.
The time boxes imposed by mandatory retooling work. Retooling is work that must be completed to allow the factory process to handle requirements stemming from law, regulation, or priority changes. This work generally has a firm date for when it must be completed and added to the factory process.
The time boxes imposed by peak processing loads when factory process stability is paramount. It is generally not a good idea to destabilize your factory process during peak season. You must also make sure you have a matching non-production environment in which you can troubleshoot problems in production.

Transition Management: Integrating Data to Create Knowledge

Date: December 30, 2012 Author: Jeff Comments: Leave a reply

In my previous post, I discussed how knowledge management was an important aspect of transition management. I discussed the use of content management systems to help organize documentation to make it easier for the next person in a position to learn from the person who just vacated the position. This is especially important when the person who left is no longer available to transfer his knowledge to the new person.

But having documentation available really doesn’t solve many transition management issues. Effective transition management requires knowledge and documentation is really only information. Various points of information must be integrated to become knowledge.

A case in point is a Visio diagram. These diagrams are useful for visualizing a process or a system implementation. They lack depth of information about the things they depict. That information is likely found in a separate document, spreadsheet, or presentation. Unfortunately, a decision-maker must have possession and understanding of both documents in order to move forward. That can be a challenge even when a content management system is employed because it is possible that each document was stored without relating it to the other making their association next to impossible to discern.

I know there are applications that are designed to bridge this gap. They started out as computer-aided systems engineering (CASE) tools and have evolved into enterprise architecture (EA) suites. I think these tools are generally directed toward IT professionals for building computer systems. I don’t think these tools are generalized enough to address a larger topic like transition management.

Effective transition management requires knowledge, complete understanding actually, about the current state and the future state. When transitioning people, the future state can be as simple as the current state operation with new people operating it. Transition management would employ gap analysis to create a plan for getting the new people up to speed. When transitioning processes, the transition management plan would be to create a gap analysis of what needs to be done and when to move from the old process flow to the new one. This would include process initiations, process retirements, and training.

Transition Management: Managing Knowledge

Date: December 23, 2012 Author: Jeff Comments: Leave a reply

Knowledge is defined in the Free Dictionary as the sum or range of what has been perceived, discovered, or learned. I really like this definition because it speaks to the importance of both strategy (forward thinking) and experience (recollection).

The field of “knowledge management” was really big about 10-15 years ago. This wave of technology in search of a problem introduced words like “taxonomy”, “collaboration”, and “codification” to the IT lexicon. Companies rose and fell based on ideas such as whether an enterprise really needed to get two “experts” within its far-flung employment to talk to each other and how they found each other.

The point of managing knowledge in order to manage transition is to make documentation about what an enterprise does and why and where it wants to go and how available to the people who need it. This documentation is not a single book, it’s a library of books and those books aren’t just written prose. They’re narratives, manuals, pictures, diagrams, and presentations. Most enterprises have these things. The problem is that they’re not organized and not readily available. These artifacts are strewn all over each enterprise’s network as unstructured documents in shared and unshared folders. A third problem is that they aren’t integrated.

Many enterprises overcome the organization and availability issues through the use of a content management system (CMS). This allows the employees who follow those transitioning of other responsibilities to more easily learn the nuances of their new responsibilities because the knowledge of the previous workers is made available to them. This is of course dependent of whether the previous person documented appropriately and placed his documentation in the CMS with the proper indexes and key words.

But content management systems don’t force this knowledge to be integrated in a meaningful way. It is up to the new employee to determine what he needs to know at a given period and why he needs to know it. Integration of an enterprise’s knowledge is also important for the the other part of transition management – changing what we do. I’ll write about this topic next time.

You Don’t Need to Develop an Enterprise Architecture

Date: December 5, 2012 Author: Jeff Comments: Leave a reply

If you work for an existing enterprise that has processes and systems in place, you don’t need to create an enterprise architecture. You need to understand the one you already have.

The primary reason Enterprise Architecture programs fail is because the Architects are focused on something other than the reality of the business today. Business Leaders are fine with strategic planning but they are more interested in running the business day-to-day so they can survive to the future. Many Architects appear to want to create a “big bang” project to introduce a new future state. Business Leaders understand there is less risk in morphing a business from its current state to a future state.

An Enterprise Architecture plan certainly is concerned with moving the enterprise to a future state. But in order to be successful, it is equally important to completely understand the enterprise’s current state. Think of the plan as a roadmap to the future. Think of your understanding of the current state as being the sign post – “You Are Here”.

Business-driven EA Governance and Accountability

Date: December 2, 2012 Author: Jeff Comments: Leave a reply

I suggested in an earlier post that enterprise architecture should be considered a business, not a technology, initiative. I use the term business-driven enterprise architecture to reinforce that notion. That also suggests that regardless of who the Business Leaders choose to execute a business-driven enterprise architecture program, it is they who provide governance and accountability for its success.

I generally see the governance process executed as a steering committee of higher-level executives who meet at set intervals with a project group to settle disagreements, make decisions, and approve expenditures for going forward. The problem with this is that the members of the governance board are generally not familiar enough with the workings of the project to really make informed decisions.

I generally see the accountability process executed even more poorly. Usually, the person who is accountable for getting the project completed is the Project Manager who is not empowered enough to cut through the other things that tug on his resources, time, and budget. She must report to the governance committee why the project might be lagging and only receives platitudes in return.

One approach to solving this problem is the assignment of a project sponsor who is a high-level executive who “helps” the accountable project manager get things done. The success of this approach is determined by the level of engagement by the sponsor in the project.

The business-driven approach would have the project sponsor be a member of the governance board and be the person accountable to the board for the completion of the project. All project managers report to the project sponsor and are accountable to him. It is the project sponsor who works with his peers to manage the things that get in the way of completing the project.