September 16, 2008
Test-driven Enterprise ArchitectureI have a secret.
And, like all my best secrets, I tell just about everyone I meet. Because the best secrets are the ones everyone knows about.
It's about Enterprise Architecture, you see. Even better than a secret that everyone knows, is a secret that everyone knows about Enterprise Architecture.
I'm coming at it from a reformed modeler's point of view. Time was, I would have recommended aligning your strategic business goals with your IT systems by having lots of meetings and workshops, with fancy coffee and fancy biscuits. Then I would recommend drawing lots and lots of pictures. Pictures of business processes. Pictures of business data. Pictures of business goals. Pictures of business rules. Pictures of ponies. Hey, just as long as it's pictures. Pictures and biscuits. That's how we did things back in the nineties.
And then I would draw lots of dotted lines between the goals, the processes, the data and the rules and - Shazamm! - instant alignment. (Because, as we all know, a dotted line joining two things is the international symbol for alignment.)
Turns out that was bollocks. Utter bollocks, actually.
You don't achieve alignment between business goals and business IT by drawing dotted lines in pictures, no matter how fancy your biscuits are. Why? Becauase there's no actual causal link between what's in those pictures and what happens in reality.
To know what happens in reality, and to know if the reality does what the model says it's supposed to, we need tests.
And look what we learned about tests when we got all Agile: the tests became the specifications. Tests describe what is supposed to happen, using specific examples.
And that's my big dirty secret. I've discovered that the most effective way to align business goals with the software and systems we deliver is through heirachies of tests, not through pretty pictures and dotted lines.
Think about the relationship between code and features. At one level, we write a bunch of unit tests and implement a bunch of logic in our code. But do all those little chunks of internal logic add up to something the user wants? We can use acceptance tests to align our internal design (in the form of unit tests) with our user's goals.
It's very successful at pointing developers towards the code they need to write to satisfy the user's requirements, and steer them away from writing code that doesn't add value.
Scale that up a level: now we have a bunch of system features, expressed in executable acceptance tests. But can business users do their jobs - I mean, complete business workflows - using sequences of these individually tested features? Why not write a higher-level end-to-end test that captures that business scenario using an appropriate example and use that to validate your software's features in that wider context? At the very least, we could use these end-to-end test scripts to inform our choices about which system features to prioritise. If we know what dishes we're trying to cook, it's easier to choose the right ingredients.
And what about mapping strategic goals onto those business processes? Well, if we can make those goals testable - for example, by designing some business metric - than we can effectively test if our processes are moving business performance in the right directions.
So that's my vision. My secret. Enterprise Architecture defined through a heirarchy of executable specifications (or "tests", as we used to call them in the bad old days), that give objective, concrete feedback on whether the layer below is meeting the needs of the layer above.
And now that I've told you, I'm going to have to kill you...
Posted 12 years, 1 month ago on September 16, 2008