Using a standard notation is also theoretically useful to decision makers and personnel from different organizations because it creates a "common currency" for exchanging ideas and communicating with one another. The thought being - if you understand the notation, you can find your way around anyone's model in a short amount of time. Why do we need to do that?
It is not uncommon for decision makers to wonder, "If I make X decision..:"
- Who might be affected?
- What systems might be affected?
- What resources might be affected?
- Would we break something?
- What would give me the biggest bang for my buck?
- What information is available in the Enterprise to help me measure progress against a particular goal or objective?
In theory, the enterprise architecture model was designed to help answer these questions. It can be a useful tool when used in a large enterprise like the Department of Defense, or in one of the sub-components of the Department of Defense like the Army, Navy, Air Force, Marine Corps, etc.
Title 10 of the United States Code § 2222 requires that all Department of Defense business IT investments (modernizations, enhancements or development efforts) assert "compliance" with the Enterprise Architecture (EA). Without "compliance," there will be no authority given to spend money on an investment. If there is no "obligation authority" granted by the Defense Business Systems Management Committee (as defined by 10USC§186), then someone is eventually going to jail, paying a fine, or getting relived of duty.
The actual language states:
"(a) CONDITIONS FOR OBLIGATION OF FUNDS FOR DEFENSE BUSINESS SYSTEM MODERNIZATION. — Effective October 1, 2005, funds appropriated to the Department of Defense may not be obligated for a defense business system modernization that will have a total cost in excess of $1,000,000 unless—
"(1) the approval authority designated for the defense business system certifies to the Defense Business Systems Management Committee established by section 186 of this title that the defense business system modernization—
"(A) is in compliance with the enterprise architecture developed under subsection (c);
This notion of "compliance" with the architecture has been the subject of many debates since the law went into effect. People wonder what they have to be compliant with: the model? the content? the need to draw diagrams?
We get a clue from language later in the same statute. It tells us what content needs to be in the Enterprise Architecture:
"(d) COMPOSITION OF ENTERPRISE ARCHITECTURE. — The defense business enterprise architecture developed under subsection (c)(1) shall include the following:
"(1) An information infrastructure that, at a minimum, would enable the Department of Defense to—
"(A) comply with all Federal accounting, financial management, and reporting requirements;
"(B) routinely produce timely, accurate, and reliable financial information for management purposes;
"(C) integrate budget, accounting, and program information and systems; and
"(D) provide for the systematic measurement of performance, including the ability to produce timely, relevant, and reliable cost information.
"(2) Policies, procedures, data standards, and system interface requirements that are to apply uniformly throughout the Department of Defense."
Based on my personal experience, having conducted due diligence on more than $1 Billion of these investments, this is 1. apparently not clear enough and 2. not translating into direct benefits to the Department.
Most of the letters that I've seen assert "compliance" with the architecture are representing little more than the fact that that there is a diagram of the investment being reviewed (often referred to as solutions architecture) drawn, and that this diagram somehow has the same or similar words on it as can be found in the diagram of the Enterprise Architecture. The fact that an investment is or is not documented as compliant with the architecture has had little or no effect on business as usual. It mostly means that the file folder of paperwork on that investment just got a little heavier (due to the weight of the added diagrams and a piece of paper that says the diagrams are there). That's it.
It's not useful to anyone to spend the number of hours (and dollars) one must spend on creating a diagram as detailed as a solutions architecture - only to have it visually and semantically mapped to another diagram and make a file folder heavier. I've witnessed intelligent people spending days just changing the color scheme of boxes so that one model looks like the other. Then, when the colors are matched and the right box is in the middle of the paper, step forward and proudly proclaim "We're compliant with the architecture!"
What they really mean is they are compliant with the methodology described in the Department of Defense Architecture Framework and have found a way to make the words between the two models look the same.
What we need is a healthy dose of reality. If we can find a way to inject reality into these models, they can be extremely useful.
By way of example, let's assume that something bad happens somewhere in a theater of operations. As a former combat medic, I'll use a medical situation to illustrate my point.
A soldier is severely wounded by a road side bomb. He receives shrapnel wounds to his neck and, because there is a short window of time to treat this soldier, he is air lifted to a local NATO alliance facility. The doctors there examine him, rush him up to the operating room, repair his wound and 10 minutes later, the soldier is dead.
The medical teams are initially confused because although the wounds were serious, they were immediately controlled and the soldier appeared otherwise strong. By all accounts, this soldier should have survived. An investigation is started.
After the investigation is complete, it is determined that the soldier died from an allergic reaction to the anesthesia administered in the operating room. The NATO team did not have access to the soldier's medical records, his past medical history, or a record of what he was allergic to. The severe blood loss made this soldier much less capable of handling the allergic reaction. He died.
The report gets filed in a lesson's learned database, and is recovered by a team of proactive architects a year or two later. They read through the case with great interest. It seems to them that they have found a data sharing problem that can be solved.
They contact some military doctors, share what they've found and get their feedback. The doctors tell them that in order to prevent this kind of tragedy in the future, all NATO and field hospital medical teams need to have 9 data fields: patient demographics, past medical history and allergy information. If they can get that info in a timely manner, many lives could be saved.
The architects are excited. They take what they have learned and translate it into specific data and system requirements. Then they take their new package of requirements to leadership, explain the situation, gain approval, and express that information in the DoD Enterprise Architecture. From that point forward, the 9 data field requirement sits in the model in a place where the affected data exchange between DoD electronic medical records and NATO and field hospital units is represented.
Staff can come and go. Everybody in the investment review process may know nothing about what happened to our unfortunate fallen soldier. It doesn't matter! From this point forward, every relevant business IT investment that comes through the investment review process will be subjected to a requirement to carry those 9 data fields. Every affected business IT system will, from that point forward, be forever altered to make sure that those 9 data fields are available for the medical teams who need them. The problem that caused a soldier to die is eliminated!
Back to our legal language: by doing this, we just satisfied section (d) (2) by inserting "Policies, procedures, data standards, and system interface requirements that are to apply uniformly throughout the Department of Defense."
If we treat compliance in this way, Enterprise Architecture compliance becomes compliance with Policies, procedures, data standards, and system interface requirements that are to apply uniformly throughout the Department of Defense. We will deliberately eliminate real world problems - one investment at a time.
Isn't this a better compliance standard to live up to than compliance with a model?
To listen to a 10 minute audio podcast I made on this subject a couple of years ago, click the following link: http://www.health.mil/dbt/downloads/The%20Power%20of%20EA.mp3
No comments:
Post a Comment