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.

The Business Calendar

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.

Exception Processes

Exception Processes happen whenever an enterprise has to process a transaction that can’t be handled by its Factory Process. The usual culprit is that the submitter of the transaction (e.g. customer, taxpayer, etc) does so in a fashion that is not handled in the Factory Process.

In this previous post, I described several situations where this could occur and why. The next decision for the enterprise is what they’re going to do.

Acquiescing to unruly customer behavior may be the path of least resistance but that’s not helping your enterprise maximize its profits. The Factory Process is in place because it’s the least expensive way to process the transaction. Anything else you do will only drive costs upward.

In the prior post, I described real reasons why customer could not conform. In those cases and due to the high volume of transactions, a permanent exception process needs to be implemented. The alternative is to forego the revenue.

However, the enterprise has a worthy goal to eliminate these exception processes. This is done using a customer education campaign and fees for continued unruly behavior.

The education campaign should be applied first. Tell your customers how their unruly behavior drives up costs and therefore prices. Describe the systems you have put in place that allows them to access the Factory Process and help them convert to using them.

Next, consider eliminating stimuli that encourage unruly behavior. Get rid of the return coupons from your statements, including those on the statements you email to them. Place the URL for your payment website prominently of your billing correspondence. This will discourage paper check payments and encourage electronic check payments.

The next step in changing customer behavior might be to introduce fees for unruly behavior or discounts for desired behavior.

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

Safeguard Processes

Safeguard processes protect the Factory Process to ensure it is not being abused.  These activities ensure that you are doing the “right” things right. The high velocity of the transactions flowing through the Factory Process means that problem transactions can be completed before it is known that they are problems. This can lead to all manner of problems. Let’s use the following example to illustrate various safeguards to a factory process.

This is tax season in the United States. Taxpayers are voluntarily computing their final tax bulls for the preceding year and are squaring their accounts with the IRS. Some people owe a little more and some people paid too much during the year and are due a refund. The IRS has implemented an electronic filing system that relies on independent software developers and web hosters to help taxpayers through the process.  This results in a system (the Factory Process) that allows the IRS to process a very large number of tax returns very quickly with little human intervention.

The IRS spot checks taxpayer accounts using the dreaded tax audit.  The IRS will select a taxpayer and ask him to visit them and bring his tax returns and records for for a designated number of past filings.  The IRS will comb through those records and determine whether the taxpayer’s filing present an honest account of reality.  This is a Safeguard process for the IRS.  The threat and execution of these audits protect the Factory Process by encouraging the taxpayers to provide honest accounting of their tax years.

Unfortunately, tax audits only protect the system from real, honest taxpayers who can be located once the IRS decides to audit them.  There is an increasing business of defrauding the IRS by filing returns for non-existent taxpayers or for taxpayers whose identities have been stolen and having the IRS deposit a refund amount in a bank account from which the money can be immediately swept beyond their reach.  This scheme depends on forged documentation that is processed before its veracity is checked.  The IRS is now using more prospective methods of identity verification and cross checking employer records against employee claims.  These too are Safeguard processes because they help prevent the processing of fraudulent transactions.

So you see, Safeguard processes can be placed anywhere within the Factory Process.  Edits and cross checks are prospective or in-line Safeguards.  Audits are retrospective Safeguards.  Both types help the IRS collect and retain the maximum amount of revenue owed by taxpayers.  It is very important to find and utilize every means to protect the Factory Process from abuse.

The Factory Process

The Factory Process is that set of activities that define the essence of the business in which the Enterprise is engaged. It is the path most transactions and activities should travel.

Since this is the path taken by most of the business’ activity, it should be created as a highly automated, well-oiled machine. It is the process where the transactions have the highest velocity. It is the process with the lowest costs per transaction. These factors require that the Factory Process be protected at all costs. This protection is provided by the Safeguard processes. We’ll discuss those in a later post.

If the Factory Process is working correctly, there will be few, if any, exceptions. But exceptions will arise for many reasons, some preventable, some not. Those that are not preventable will flow into the predefined Exception Processes. Costs go up significantly when these Exception Processes are employed mostly due to the need for manual intervention. We’ll investigate these issues in another post.

What about those exceptions that arise even though they were preventable? These are generally caused by human error somewhere in the process. It may be a worker on the line (whatever the line may be in the Factory Process) who is performing their duties incorrectly. It may be a defect in the computer program that automates one of the Factory activities. Such a defect points to human error in the development, testing, or deployment of that program.

The Factory Process needs two attributes to combat these exceptions. These are a Feedback Loop and Good Supervision.

A Feedback Loop provides information about the the process. This feedback should be descriptive and as close to real time as possible. The description would ideally provide the outcome of an individual process step for an individual item or transaction matched against a list of expected outcomes. These expected outcomes would be those outcomes that can continue to be handled by the Factory Process. The near real-time nature of the Feedback Loop means that these outcomes are available to managers who can adjust the process as soon after the transaction step was completed as possible and that it is presented in a way that makes anomalies easy to spot. Most people think of dashboards and the metaphorical presentations used by them.

Nothing beats good supervision when combating problems in the process. Supervisors are the absolute front fine of management and should not only know what a process does but also why it does it that way. Having spotted a high level of exceptions originating from the area they supervise, the Supervisor should work to find the cause and escalate to find a remedy. Supervisors should be rated based on their ability to minimize the number of preventable exceptions incurred under their spans of control.

Exceptions to Exceptions (Revisited)

The problem with writing and publishing from a stream of consciousness is that sometimes you say things you might want to reconsider.  I have been thinking about my statement in the last post that exceptions to exceptions are illogical.  Consider the following…

An enterprise decides that its factory process is that it will conduct its business with its customers electronically.  Say the enterprise is a utility company.  It emails the monthly bills to every customer and includes a link to its electronic payment website.  This makes it simple for the customers to comply with the utility’s wishes.  Or does it?

Assume that every customer can receive the bill.  That doesn’t mean that every customer has the ability to pay electronically because not every customer may have a bank account or payment card.  Then there is that group of unruly customers who just refuse to make electronic payments.  Assume that these groups comprise a number large enough that failure to accommodate their needs will severely hamper collections of revenue necessary to keep the enterprise going.

The enterprise now has an exception process that must process old-fashioned payments where the customer returns a coupon or remittance advice with a paper check.  Since the volume is significant, the utility must have a reasonably efficient process to minimize costs.  So a factory process is set up to efficiently process paper coupons and checks.  It starts with the utility including a remittance coupon that the customer can print and return with his check.

The rest of the process can be built either by investing in the process or outsourcing to a lockbox operation.  The factory-compliant transaction is where the coupon and check arrive together and the check amount matches the amount that was billed.  These transactions flow right through the new factory process for the exception process.  The output from this process should resemble an electronic payment so that it can be submitted to the enterprise factory process immediately upon completion.

What can go wrong now?  We now have the following three exceptions to the exception:

  • Only the check arrives
  • Only the coupon arrives
  • The amount on the check doesn’t match the amount on the billing coupon

So what’s the lesson here?  It is that there should exist factory processes within exception processes where the incidence of exception is going to be very high and the enterprise has little way to control customer behavior.  These factory processes should be managed just like the enterprise factory process in order to maximize efficiency and minimize costs.  The output from this exception process should reenter the enterprise factory process as quickly as possible.  But there are also exceptions to be encountered that the exception factory process can’t handle.  These should be managed at the department level just like exceptions to the enterprise factory process are managed at the enterprise level.

The Three Process Types

Processes are sets of activities that have some level of definition and standardization about them.  The Enterprise runs using three types of processes.  These are Factory, Safeguard, and Exception.

The Factory Process is that process that implements the essence of the business. These activities are the “right” things to be doing.  We have previously referred to them as the “things we’re supposed to do”.  It is the core competency and operates at the highest efficiency and velocity.  Every step of the Factory Process is standard and should be automated to the highest extent possible. The Enterprise wants to push all transaction activity through it. This is the path for transactions from Customers who “play by the rules” of the game as the Enterprise wants it played.  This should encompass the majority of the transactions processed by the Enterprise.

The Factory Process must be protected by Safeguard processes to ensure it is not being abused.  These activities ensure that you are doing the “right” things right.  The high velocity of the transactions flowing through the Factory Process means that problem transactions can be completed before it is known that they are problems.  (e.g. Processing fraudulent transactions can cause money to leave the Enterprise with no hope of recovering it.)  Business-driven Enterprise Architecture and Internal Audit are examples of Safeguard processes.

Transactions that don’t conform to the Factory Process are Exceptions and run through Exception Processes.  In many cases, these are the activities that we have labeled the “things we really do”. Exceptions should only spawn from unruly Customer behavior.  If behavior within the Enterprise dictates a change, adjust the Factory Process or change the behavior back to that which conforms to the existing Factory Process.   The degree of automation for Exception Processes is thus dictated by the Enterprise’s ability to control or influence this unruly Customer behavior.  (e.g. Most Customers will need Customer Service at some point in your relationship to them and unless you are in the Customer Servicing business, it is an Exception Process.  There is always some level of Customer Service that can be automated and some level that shouldn’t be.  Perhaps the former set of activities should be considered Safeguard processes because they help the Customer play the game correctly.  The latter set is for those Customers who just demand more attention.  Understand the difference.)

The goal should always be to correct the exceptional nature of the transaction and then get it back into the Factory Process.  The idea of running a parallel process that handles the exception differently all the way through its lifecycle is both inefficient and ineffective.

The idea of an Exception to an Exception is illogical.  It is just another more obscure exception that has many of the same traits as some other exception.

Welcome to our new Home!

Welcome to the new home of the Business-driven Enterprise Architecture blog. It’s right here on our website. All of the content from the previous blog has been transferred and republished. We’ll be blogging again soon.

Happy New Year

It’s now 2013.  We’ve survived the transition from the end of one Mayan long count cycle into the beginning of the next.  Just think, only 1,871,998 weeks to go before the next media frenzy over the Mayan calendar. Oh well, the media are a resourceful bunch. They’ll find a new crisis to pump up long before then.

2013 is going to be a year of big changes in business.  The United States will either get its fiscal house in order or it will drag itself and the reset of the world into an economic depression.  The European Union may beat the US to the punch if they can’t get a handle on the economies of the smaller struggling countries.  One political outcome is sure to be more regulation on economies and a heightened need for enterprises to understand what they are doing with their capital.

It is my belief that every enterprise should look at its entire operation from requirements through implementations and consider whether they are really doing what they’re supposed to do and create plans to remedy when they are not.

I intend to help by providing some ideas on how to do this.  I’m going to change the publishing schedule for this blog from twice per week to once per week so I can provide better material.  Expect a new article to publish each Sunday night (12:00am EST).

The “Mayan Apocalypse”  was drastically over-hyped.  I don’t believe we can over-hype the challenges that will face enterprises that lack understanding of their own requirements and operations in the coming age of global governmental fiscal crisis.

Happy New Year!