My last few gigs have each seen stuff added to systems that weren’t actually needed. In Lean terms this is waste, and what’s interesting is that the waste came from an unexpected direction: enterprise architecture.
I’ve had run-ins with architects before, but it’s only really now that I’ve been around Lean practitioners that I think I understand why. It’s often pretty simple: they’re having the wrong conversations.
In a note to my future self, here’s some thoughts about what the wrong conversations look like.
Way back when in 2001 (!) Joel Spolsky, later of StackOverflow and Trello, coined the term ‘architecture astronaut’. The essay is still online and although he mutters dark things about ‘peer-to-peer’ systems and references Napster, what he says holds true.
But it seems we don’t learn.
Here’s a list of things to watch for:
Is there a proof-of-concept for the solution proposed? Did the architect write it or at least get involved in the debrief? If not, it’s a good sign that the solution may not work in practice and isn’t grounded in reality.
Who from the deployment or operations groups has been involved in the design? If they’ve been overlooked, anticipate rework to fix security holes, performance issues, capacity problems or if you’re really lucky some ugly combination.
What business problem does the design solve? Unless the design reflects real customer desires (or, at a pinch, desires of the company) then sooner or later funding will likely dry up and the efforts wither on the vine. (Sooner rather than later, usually.)
All of these can be mitigated by sensible conversations, with customers, business analysts, developers and operations colleagues. If those conversations aren’t conducted by the architects, then they risk designing something that’s in outer space: intellectually interesting but not relevant to immediate needs.
And yes, Joel-in-2001 would laugh if he knew that SOAP, WSDL and XML are now the old way, JSON is sniffed at, and YAML is the new hotness… but in truth all these are implementation details. Good conversations with the ultimate consumer of the software are what matter.