What, again, is MetaAutomation all about?
Here
is a metaphorical view of the potential of MetaAutomation.
This post is about a technical view.
The least dependent pattern of MetaAutomation is called
Atomic Check. There are three main aspects that Atomic Check specifies and they’re
somewhat bound together:
First, the check must be atomic i.e. as short and as simple
as possible while still measuring the targeted business requirement for the
software product. The result of a check run is a Boolean of course, pass or
fail.
Second, no check has a dependency on any other check. They
can be run in any order and on any number of clients, to scale with available
resources.
Third, every check run creates a detailed result, which I
call an artifact. Whether it’s pass or fail, the artifact has all of the
following characteristics:
1.
It’s pure data. (I use valid XML with an XSD
schema.)
2.
All the individual steps of the check are
self-documented in the artifact.
3.
Check steps are hierarchical, for better
clarity, stability, and robustness in analysis.
4.
Check steps, and the check as a whole, can have
additional data in name/value pairs.
5.
Each check step element in the XML has perf
data: the number of milliseconds that step took to complete (including child
steps, if there are any).
The third aspect is the most radical. What happened to your
flight-recorder log? It can be there if you want the help at development time,
but that’s the only setting where it’s useful. Afterward, it’s discarded,
because the pure-data artifact is more compact, more precise and more accurate,
and much better for subsequent analysis and other cool stuff.
Why would I ask you to do something radically different?
Because it helps you do very cool and powerful things, like communicate to all
roles in the team in as much or as little detail as they want! It enables
analysis of product behavior over the entire SDLC, greatly simplifies and
normalizes perf information, makes for better information on software asset value
for Sarbanes-Oxley (SOX) …
The third aspect I describe above, in combination with the
first two, enable the dependent patterns of MetaAutomation to work and deliver
quality value to the whole team that’s an order of magnitude better than
conventional practice. For software that matters to people, MetaAutomation or
the equivalent practice is inevitable.
Very nice description for MetaAutomation. It is simple to understand and well job by you!
ReplyDeleteBuilding automation