I've delivered a great many presentations on the subject of Defense Business Transformation during the four years I was the Chief for Defense Business Transformation for the Military Health System. I delivered these presentations in a medical community context, but the Defense Business Transformation content easily translates to any DoD environment.
Follow this link to take your pick of 45 months of weekly presentations: http://www.health.mil/dbt/dbtcommunity.aspx
These were delivered to a core community of just under 300 people from 7 different organizations each week. They were never all in the same room at the same time, but they rotated in and out and always got the briefing by mail.
I also prepared a number of ten minute podcasts on the subject of Defense Business Transformation. Each is delivered with music and stories to make the subject more interesting.
Follow this link to my podcasts: http://www.health.mil/dbt/podcast.aspx
My favorite ones are the last three. It took me a while to get used to the format, the studio, etc.
It's all free for the taking, so if you have an interest in the subject of Transformation in the Department of Defense, help yourself!
Friday, July 24, 2009
Wednesday, July 22, 2009
Measuring Relationships from Social Media
I had an opportunity to meet Katie D Paine this afternoon at an Open Government and Innovation conference in DC. Katie specializes in public relations and measuring their effectiveness. Her commanding presence underscored her depth of knowledge, and her open and friendly demeanor in a one-on-one situation proved to me that she practices what she preaches with respect to building relationships of her own.
I bought Katie's book on the spot. Six hours later I have already found a good many nuggets of information that I believe will be useful for Transformation Agents in the DoD.
Gaining trust, building relationships, and communication with a purpose are things that many people instinctively understand are an important part of a change management program. But until now, I didn't know anyone who had a well documented methodology for measuring success (or failure) in these areas.
For anyone engaging social media as a means to an end: Katie's talk today was about how to measure the quality of relationships created through social media vs measuring the number of hits a social media site gets. The crowd laughed as she described her personal definition of "Hits" as
If you haven't already heard the question, I expect it will be a common for people holding the purse strings in the DoD to ask: what is the effectiveness of this media? We will need to be able to step up to that question with evidence.
Her book is titled Measuring Public Relationships: The Data-Driven Communicator's Guide to Success, and can be found on Amazon.com.
Katie also has a PR Measurement blog at http://kdpaine.blogs.com/
I recommend this book for anyone wanting to inject some science into an area traditionally thought of as "mushy" or unmeasurable: relationships.
I bought Katie's book on the spot. Six hours later I have already found a good many nuggets of information that I believe will be useful for Transformation Agents in the DoD.
Gaining trust, building relationships, and communication with a purpose are things that many people instinctively understand are an important part of a change management program. But until now, I didn't know anyone who had a well documented methodology for measuring success (or failure) in these areas.
For anyone engaging social media as a means to an end: Katie's talk today was about how to measure the quality of relationships created through social media vs measuring the number of hits a social media site gets. The crowd laughed as she described her personal definition of "Hits" as
"How Idiots Track Success."She made a good case for why measuring the number of hits a Web site gets is insufficient. Relationships matter more.
If you haven't already heard the question, I expect it will be a common for people holding the purse strings in the DoD to ask: what is the effectiveness of this media? We will need to be able to step up to that question with evidence.
Her book is titled Measuring Public Relationships: The Data-Driven Communicator's Guide to Success, and can be found on Amazon.com.
Katie also has a PR Measurement blog at http://kdpaine.blogs.com/
I recommend this book for anyone wanting to inject some science into an area traditionally thought of as "mushy" or unmeasurable: relationships.
Monday, July 20, 2009
Veterans Business Transformation?
It appears as though the Veteran's Administration (VA) is following in the Department of Defense Transformation footsteps. Though I haven't seen a Title 5 statute modification to force the Transformation VA-wide, it does appear that there is support at the highest levels of the VA for the kinds of behavior modification that the Defense Business Transformation program was established to encourage.
See the following press release from 17JUL09: http://www1.va.gov/opa/pressrel/pressrelease.cfm?id=1734
See the following press release from 17JUL09: http://www1.va.gov/opa/pressrel/pressrelease.cfm?id=1734
Sunday, July 19, 2009
Solving Real World Problems With Enterprise Architecture
The concept of Enterprise Architecture isn't really difficult to understand. Creating an Enterprise Architecture (EA) is simply a matter of using a standard notation to describe the people, tools and rules of an enterprise. Describing an enterprise is theoretically useful to decision makers because it allows them to see the relationships between things.
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:
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:
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
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
Subscribe to:
Posts (Atom)