Blogs

The link to the paper "Part Two: StratML Toolkit & StratML Cloud" is available at the following site:
http://xml.fido.gov/stratml/references/StratML-Toolkit&Cloud.pdf

While I hope that the ISO version of Part 1 will now become stable for a fair amount of time, I personally don't believe that lack of stability in the standard has much to do with the lack of implementation.
For example, MarkLogic developed its prototypical StratML query service even before the ANSI version of Part 1 was finalized. The reason they did not maintain it is that a paying customer did not emerge.
By contrast, Andre Cusson has put a whole lot of work into his StratML portal, presumably because he believes in the vision of the standard and that the business case for his application will eventually be recognized by those willing and able to pay for the capabilities it provides.
Thus far, the StratML Committee has not focused on the business case in the sense of how money will be made by vendors of applications and service applying the standard. Even now, I do not believe it is appropriate for the Committee itself to do so.
Instead, I believe we should continue to focus on the elements and structure of the standard itself and leave it to entrepreneurs, who may include members of the Committee acting on their own behalf, to innovate ways of leveraging the standard to make money.
As hss been pointed out, however, this is a bit of a chicken-or-egg situation, because potential customers may not recognize why they should pay for StratML-related services until they can literally see the benefits of doing so while, on the other hand, application and service developers may not be able to justify to themselves the investments of time, money, and effort required to demonstrate such benefits.
Of course, too, an underlying fact of life is that individuals and organizations don't particularly want to be held accountable even for documenting what they aim to accomplish, much less being held responsible for actually doing it.
As long as their stakeholders allow them to continue not to do so, they probably won't.

William, the StratML Committee operates by volunteerism and consensus. So if others share your interest in focusing on Part 3, you and they are certainly welcome to do so. As you know, for example, I believe more fully functional CMS applications will be required to deal with the complexities of Part 3, whereas relatively simple forms-based interfaces work reasonably well for Parts 1 & 2. However, thus far, my InfoPath form is the only implementation of Part 3 of which I am aware. If you think you might be able to implement it in a CMS application, that would be great. In any event, until organizations start rendering their own plans in StratML format, I personally will probably continue to focus mostly on converting them to Part 1 format, with occasional efforts to create Part 2 files (which take quite a bit more work). To the extent that organizations may have performance indicators in machine-readable format, I'd love to partner with others to automatically render them in Part 2 format, as Gannon Dick and Andre Cusson did for the FACA committees.

Whilst I see StratML is or maybe was primarily designed for fairly static models like desk-heavy organisations, it would be a much more engaging and testing POC if we worked on something like http://en.wikipedia.org/wiki/Typhoon_Haiyan
Assigning members as players maybe. It would certainly push StratML.

We are ready for a POC.
One with input that will allow us to build to outlined goals and objectives. Sound familiar?
Data pulled from a like data source going over real networks.
There are many talented people on the team like Owen, Andre, Gannon, and Sylvia who can make this happen, but they need support.
Could we pull-off a solid POC?
My gut says yes.

I agree about the need for maturity. What resources do we have available for building something?

The toolkit must be able to show in a somewhat mature manner how to create and deploy StratML.
It will be a WIP progress effort that will take time, but will deal with issues such as data extraction and bi-directional flow paths to related entities within, and outside of an ecosystem

Do you think StratML is ready for uptake by DHS/FEMA?
Maybe we should work on the mechanics of a small POC with selected members acting in roles, just to see how it pans out before we whitepaper. That way the tech needed can come out of the requirements, a sort of form follows function approach.

A Three Step Process
1) White Paper (What it is and how it can be leveraged)
2) Toolkit (How to build it)
3) Portal - Exchange - Repository (Finished Product)
Two paths. Conceptual and Practical.
We need to work on both concurrently.
Part Two of Toolkit shows the visual model, and or models. We need to get to second base, and this will be of great help in getting people to better understand the concept.

We have outlined things like 1906 SF Great Quake, Sandy, and 9/11 in the White Paper, along with an oil spill in the Toolkit.
The goal here would be to agree on a POC or Test Case and then have a soundboard over at the DHS/FEMA, or some other reputable government entity rip into it. The more, the better.
While we want to show our prowess, we are outsiders. People at the DOD, DHS/FEMA, and NSA deal with the real stuff on a day-to-day basis and their input would be of great value.
As a result, we need to craft things like the White Paper and toolkit to establish our credibility.
A POC or Test Case is the next step.

Russ: I wanted to use this opportunity to ask you to share on the blog how you see organizations (like DHS/FEMA) can pick up the Toolkit and use it for a StratML Implementation? What should be part of the package, and how could it be presented?

Also the stakeholders could be included from the off, which might make any response a little less chaotic and blind as they always seem to be.
Does the soon-to-be affected are actually have any metalled roads? Will the telecoms withstand what is about to happen?
Is there enough fresh water stashed safely?
Will the hospitals cope?
Etc

One thing that always struck me about the responses I've seen to most of the disasters, is that the weather men are warning everyone days before but the response is always AFTER the disaster. Why not drop a few thousand water purifiers, tents, medikits or whatever before the hurricane hits. StratML my be leveraged beautifully for this sort of planning.

A dry run of a real-life scenario, say hurricane Sandy might be interesting? Perhaps start with something smaller but it might highlight any problems with the format.

I suggest that there are a few reasons for lack of take up.
1) There is almost always a disincentive for any organisation to be measure, in case they don't measure up, so they might be tempted to use say PDF because it is after all "machine readable". Not in a meaningful way but machines can read it so that satisfies any edicts they might be subject to.
2) The assessors can't see an easy way to readily assess progress using StratML, so are unlikely to enforce its use.
So maybe if there were some "templates" for say a health department or a transport department or even disaster relief committees that could be the recommended formats to use?

Here is where the rubber meets the road.
We have a pretty good idea where StratML could be used, and now we need to get a few Proof of Concepts (POCs) in real-world environments to expose its capabilities.
These POCs will show us what needs to be changed to work in true heterogeneous environments.
It will be painful, but it is all part of learning process to build something that an entity such as the DHS/FEMA could really use in the Enterprise.

I agree, maybe we should set up a war gaming style test run to see how StratML performs in a life-like scenario?

Glad you clarified William. Yes, there is a follow-up diagram I am putting together based on the outline Russ put together, depicting both a public and private repository. Based on your feedback, I'll make sure to include multiple parties pulling different aggregates of the same data.
The first diagram focuses on the simplest scenario -- displaying StratML data on the Web.
The premise that many of us have is that current lack of adoption is due to organizations unclear of the "start to finish" process of StratML -- i.e. "Where do we put it?" My sense is that this i the #1 reason.

I see DHS/FEMA as natural clients because of StratML's ability to create public & private sector agreements, which could improve responses regarding manmade (e.g., oil spills, terrorist attacks, etc.) and natural events (e.g., earthquakes, hurricanes, etc.) events.

Maybe the problem is the perceived lack of stability? With V 3 waiting in the wings, organisations might be waiting for that to stabilise before making a move?
The lack of backward compatibility is an issue too I would think.

Maybe we should concentrate on why there is a lack of take up?

What I see the potential for is that StratML is, or could be, a repository for the aims and the current state of play. So being machine readable I expect that eventually the StratML will be taken up by some aggregator(s) and from them it could be re-purposed to provide info on how things are progressing with x department compared to y department. Which in turn might be used by another analyst to judge effectiveness or whatever. To do any of this though the metrics need to be in a standard format perhaps agree before hand.

May we please focus on this before we move forward?
Do not want to lose it

The team over the last couple of months made very convincing arguments on all sides of this issue -- there is no clear decision. However, I'm going to stand with the argument that Part 1 IS low-hanging fruit with a lot of traction in the form of conversions already done...and far less complex. We'll build processes to upscale to Part 2 and/or 3 -- even though those specs are not formally compatible.
As for using StratML -- organizations are for the most part playing wait-and-see / chicken-and-egg. The purpose of the Toolkit is to encourage orgs not to play wait-and-see anymore by presenting an easy implementation path.

I think we have to look at it as that we are in the early adoption phase.

Thanks Russ. Yes, I think so. This Toolkit Part Two will come in very handy in helping people see the place for StratML. William: You mentioned a circular diagram. Could you describe (in words) what a circular system might look like?

I hope we are, I have some questions though.
1) Should we be concentrating on getting Ver 3 fixed as it seems to be a better place for effort, rather than develop for Ver 2 and then have to rebuild to suit 3
2) Does anyone know how many companies are actually using StratML in earnest?

Gentlemen,
Good afternoon and good evening,
Looks like we are gaining some critical mass on a number of fronts.
Russ

Thanks, Ranjeeth, for fostering awareness and understanding of the potentials of AIIM's StratML standard.
Hopefully, the AIIM community will come together not only to demonstrate the utility and value of the standard but also the AIIM community itself.

Looking forward to this report, which helps to connect the dots to Part One of Toolkit & Cloud. The goal of these two reports is to help promote the wide-spread of StratML in both the private and public sectors. However, one must be able to better understand how to create a StratML agreement, and is where Part Two of this report provides value. The ability to "see" how the process works.
This piece will no doubt help to better explain how documents are created.

Looking forward to this report, which helps to connect the dots to Part One of Toolkit & Cloud. The goal of these two reports is to help promote the wide-spread of StratML in both the private and public sectors. However, one must be able to better understand how to create a StratML agreement, and is where Part Two of this report provides value. The ability to "see" how the process works.
This piece will no doubt help to better explain how documents are created.