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.

Let’s Talk Information System Security

Target Corporation is still reeling from the discovery that they had been hacked and made vulnerable the financial information of millions of their customers. Other retailers have made or will make similar discoveries. Those will be announced on an on-going basis.

Information system security should be an integral part of any Enterprise Architecture program. Information system security is built in to Business-driven Enterprise Architecture because BDEA is a safeguard process as is security.

The US Federal government is under a law called the Federal Information Security Management Act of 2002, or FISMA. FISMA is the basis for various government security standards such as HIPAA and IRS Publication 1075. Frankly, these standards should be used by everyone, public and private sector, because they are rigorous and comprehensive. I would imagine that Target is thinking about them right now.

Implementing FISMA is not cheap but you can consider the cost as paying an insurance premium rather than paying an insurance claim after your system has been invaded.  At that point, your organization will have no choice but to implement a similarly rigorous security program and absorb those costs in addition to all the costs of the government fines and customer compensation that will be required.  Like the old FRAM oil filer commercial said, “You can pay me now, or pay me later”.  Paying now is far less expensive.  The cost of the negative publicity and its effect on ongoing sales will dwarf the cost of implementing the program proactively.  Implementing a FISMA-level security program does not make your enterprise instantly immune to intrusions and loss.  It does help you prove that you took all due diligence to protect data while testifying in one of the myriad lawsuits that will occur after you have been hacked.

FISMA does allow some flexibility in implementation. Once you have identified a risk, you have the opportunity to develop controls ($$) or to document acceptance of the risk with sign-off by the assuming officer. Acceptance is much less expensive out-of-pocket but the assuming officer might very well have to later justify his actions in a court of law. Another strategy is to develop a POA&M (see below) and develop the security control as the milestone.

The reference materials for these standards are quite decentralized. I have created a short primer for navigating them below. Please keep in mind that I am an Enterprise Architect and not an Information Security professional. Ask an Information Security pro to interpret these documents for you.

FIPS 200 documents the Minimum Requirements for Federal Information Systems Security.  These are the minimum security requirements for US Government agency business systems; not black ops systems.

The security model is based upon a system criticality measure for confidentiality, integrity, and availability. FIPS 199 provides the guidance to determine System Criticality.

FIPS 200 also references a Risk Management Framework. That is defined in NIST 800-37. The framework with external references is:

  • Categorize Information System (FIPS 199)
  • Select Security Controls (NIST 800-53)
  • Implement Security Controls
  • Assess Security Controls (NIST 800-53a)
  • Authorize Information System
  • Monitor Security Controls (NIST 800-53a)

FIPS 200 also specifies 17 security-related areas that must be addressed in a comprehensive security plan.  The function points (Security Controls) required to address each area are defined by the system criticality measurement.  Security Controls are the management, operational, and technical safeguards or countermeasures prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information.  The actual definition for each security control for each criticality level is found in NIST Special Publication 800-53.  There are specifications that go beyond those mandated by the standard which are deemed optional based on the environmental situation of a given system.  Criteria for auditing and evaluating these controls are found in the companion publication NIST Special Publication 800-53a.

A Security Technology Implementation Guideline (STIG) is a specific configuration for a specific technology specified by the Defense Information Systems Administration (DISA). These guidelines can also be found in the National Vulnerability Database.  The DISA versions are generally used because they are concise and well-formatted.

DIACAP is a standardized methodology for evaluating the security posture of Department of Defense (DoD) Information Systems for certification and accreditation.

A Security Finding is a specific situation where a system security control is not met.  It must be classified (Category) and have a POA&M developed.  A Plan of Action and Milestones (POA&M) is required whenever a current state of a Security Control does not meet the future state need.

Vulnerability Security Code Definitions

  • Category I – Vulnerabilities that will directly and immediately result in loss of Confidentiality, Integrity, or Access
  • Category II – Vulnerabilities that have a potential to result in loss of Confidentiality, Integrity, or Access
  • Category III  – Vulnerabilities whose existence degrades measures to protect Confidentiality, Integrity, and Access

Risk Management: Finding Risky Behavior

Risk is the possibility of suffering harm or loss.  The definition in the Free Dictionary also references danger.  Harm or loss for most enterprises either comes from opportunity lost or regulatory sanction.  Either way, the situation is bad for the enterprise.

Some risks can be eliminated but most can only be mitigated by exploiting your advantages and shielding your deficiencies.  This is the essence of risk management.

I think the easiest way for an enterprise to mitigate risk is to know what it is supposed to do and then do it.  In order to understand what it is supposed to do, an enterprise must completely understand its entire set of requirements and then implement processes that satisfy those requirements.  This is not something that just happens.  It must be planned, executed, and implemented.  It must then be constantly evaluated as requirements change.

Another opportunity for risk can be found in those processes between what we do and what we’re supposed to do.  Most exception processes are ad hoc and not well designed. They arise from a crisis situation where workers have a very specific problem to solve and so they solve it.  The problem is that they don’t have or take the time to evaluate their solution against the enterprise’s entire set of requirements.  This opens the possibilities that the new process allows people to do things they shouldn’t or doesn’t make them do things they should. Both of these are risky situations.

So, the first part of managing risk is to identify those processes where the enterprise is not doing what it is supposed to be doing.  This requires that the enterprise evaluate everything it does against its entire set of requirements.  I’ll discuss remediation next time.

Requirements: Types, Levels, and Focus

The Free Dictionary defines requirement as something demanded or imposed as an obligation. An enterprise is required by its customers to keep its products or services available or else they will go elsewhere to meet their needs. Regulators demand that enterprises conduct themselves in certain ways or else they will sanction them in prescribed ways. Management requires the employees to perform certain functions in prescribed ways or else they might face disciplinary action. Requirements come from every direction.

Most Architects are familiar with the requirements because requirements are necessary to define the functionality of the systems they build. I call these local requirements because they are requirements for the specific system being designed.  Local requirements are easy to gather and easy to track because they are a significant deliverable to the project at hand.  The Project Sponsor will want all of his requirements met.

There is another set of requirements that are generally lost in the euphoria of the project process.  I call these enterprise requirements because they are important to the overall enterprise.  Unfortunately, they can actually serve to make the current project more difficult and more expensive.  It is important to note that often times, enterprise requirements become refined into local requirements and that’s a good thing.

Requirements can be subtle or deliberate. All requirements are deliberately set forth by some constituency but they can be delivered very subtly. Local requirements are certainly deliberately set forth and delivered.  They are the wants and needs of the person paying for the project.  Enterprise requirements may not be so important to the Project Sponsor so they become more subtle.

Casting these concepts back into terms we have used previously: local requirements are generally about what we do (or want to do) and enterprise requirements are about what we’re supposed to do.  Unless an enterprise has a mechanism for tracking those enterprise requirements, they can quickly fall out of focus to the people charged with implementing them.

You Don’t Need to Develop an Enterprise Architecture

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”.

Sometimes You Pay the Fine

No project should ever be considered without considering the cost of not doing it at all. This goes for both technical and non-technical projects.

I worked in the financial services industry for many years. Every few years I was approached by semi-hysterical business leaders who wanted to sponsor quick-and-dirty projects to satisfy some regulatory mandate. The only information they could supply was that it was a mandate and there could be fines for non-compliance.

When vetting any project, it is necessary to understand the cost and benefit of every option for satisfying the need. Quick-and-dirty is always an attempt to brush over the lack of benefit by assuming that the cost is absurdly low. While that may be true in the short run, it’s rarely true in the long run when all of the facets that were missed come to the surface as unexpected consequences of the quick-and-dirty implementation. In other words, it’s a lot dirtier than first imagined. Quick-and-dirty is never a good idea and never as cheap as first proposed.

The one option that is often overlooked is the option to do nothing. Since most mandates to organizations carry civil rather than criminal penalties, no one is going to go to jail over non-compliance. When the fine for non-compliance is low or even undefined, sometimes the correct course of action is to pay the fine when levied and invest in projects with higher payback. It is vitally important to understand the deficiency in the enterprise architecture and to constantly evaluate whether changes in the regulatory environment dictate reconsideration of the enterprise’s lack of action.