Why is Empathy so Important for Enterprise Architects?
Justin Hendry published a great story in IT News today (Monday 26 March 2018), which I’m going to use to illustrate a point.
My point is about learning from failure, which is at the heart of all agile methods. It’s also about another concept, which is at the heart of design thinking:
Empathy
That’s a great headline. But not for DHS.
In my recent TOGAF class in Sydney, we got involved — as we always do — in a discussion about how architecture teams can create a “common language”.
We also learn words from non-English languages. Like German.
The Germans have a really useful word:
Schadenfreude
Which means (I’m paraphrasing here):
“The sense of relief you get when you see something terrible has happened to someone else.”
(I think the dictionary definition of schadenfreude is “the sense of joy you get when something terrible happens to someone else” — but that’s a bit creepy, even for the Germans.)
I’m not feeling any joy at all about the DHS story. DHS does great work for our country, and the people at DHS are highly professional and very competent.
Rather, I feel a great deal of:
Empathy — the ability to understand and share the feelings of another.
Why is empathy important for enterprise architects?
Because — as enterprise architects — our hands are often stained with the dried blood of failed business transformation programs in which we often play contributing roles.
None of us like to talk publicly about our failures. But if we don’t understand why we failed, we’re not going to learn how to prevent future failure. (And for many major business transformation programs — which are highly complex, high-risk, and politically sensitive — success often ends up meaning “not failing”. Or at least not waking up and seeing your program in the headlines of IT News.)
I feel empathy for the good folks at DHS because they woke up today to see their organisation portrayed unfavourably in the headlines of IT News.
What value can we all get from this? Heaps.
I don’t know about you, but I get more value from understanding why major business transformation programs failed, than reading vendor “success stories”.
Like Tolstoy said at the beginning of Anna Karenina — a book all enterprise architects should read:
“Happy families are all alike; every unhappy family is unhappy in its own way.”
By this, Tolstoy clearly was saying that “post mortems” for failed business transformation programs are way more useful than understanding why a program was successful. Besides, there just aren’t that many successful major business transformation programs out there. So we’ve got our work cut out for us here. Dig in.
What can we learn from the DHS experience? Well, for sure, this DHS program was big and complex, had a lot of moving parts, and we’re on the outside looking in through fogged-up windows. So we’ll never really know the full truth, will we?
But. Here’s an interesting clue:
Hello. This statement begs at least two questions, doesn’t it?
“Once we looked at it”?
So you burn through $102 million and — then — and only then — do you suddenly form the understanding that the system you are trying to “rip and replace” is “a lot more complex” than you thought — at the beginning?
Why didn’t we spend some of that $102 million up front, gaining the necessary understanding of all that “complexity”? Then we may have discovered metric knowledge about our current state business and information architecture that would have helped avoid this sad train wreck.
But — alas — I’m sure that when the big money business case for this transformation program investment was approved, people were anxiously saying:
“We don’t have time to understand where we are — we need to focus on our visionary strategic future goals for the future tomorrow! You can’t drive a car by looking in the rear view mirror! Just do it! Onward!”
Yeah. Right.
The other part of the above quote that strikes me as being a bit fishy is this:
“from a technology perspective”
“Technology”? Meaning computer hardware and operating systems and networks? Yeah nah. I don’t think we’re talking about “technology” complexity here.
I’m willing to bet a small amount of money that the “complexity” we’re talking about here is business and information complexity, and the application and data complexity that evolved over many years to realise the business and information complexity. The “technology” is probably the least complex aspect of the overall architecture.
I think the person quoted is doing what we often see: failing to differentiate business capabilities and processes from “technology”. So if they say “technology” they are really saying “all that business stuff is mixed up in what I’m going to call ‘technology’.”
But they say “technology”? Maybe our language itself is relevant to our post mortem?
We can try to blame Accenture for this mess (“it was more complex than the contractors had envisaged”?) but there’s no point, is there? Vendors will always behave like vendors. Vendors have private sector DNA: maximise profit, reduce cost. The customer always gets what they deserve. At some point — probably when they realised this program was going full stinko — DHS brought it back in-house. Unsurprisingly, this does not appear to have improved the outcome, and probably made things worse.
Accountability for enterprise architecture cannot be outsourced to a vendor.
Anyway. Back to my original points:
Agile? This appears to have been just another waterfall exercise. Even though the customer used the words “agile and responsive”. The customer probably thought “We’ll give it to Accenture, and they can be agile for us.” Hmm. No.
You know what the secret of being successful at agile is? You have to work at it. It can take years to become effective and efficient at “being agile”. Especially for the work that enterprise architects should be doing.
Empathy? I love the whole design thinking shtick. To create excellent business technology solutions, you have to have empathy — genuine understanding for the full life experience of the customer — their needs and expectations. So I empathise with DHS on this story. Been there. Done that.
But probably the most relevant part of the design thinking approach is what happens immediately after empathise:
Define the core problem.
And the trick here is that the core problem is probably not what you think it is at first.
If DHS had taken the time up front to undertake meaningful discovery of the true nature and extent of their complex current state business and information architecture, they may have saved themselves a lot of downstream pain and suffering.
I’m sure DHS would say today: “Oh, we knew it was complex from the very beginning. That’s why we threw it over the fence to Accenture!”
But they do not seem to have undertaken their own prior architectural investigation and modelling of the true detail and nature of that complexity. Based on what was said in the IT News article today: DHS appears to have had zero reliable, facts-and-evidence-based metrics that would have revealed to them how much complexity they had.
It is possible to do these things. If you don’t, you’re jumping off a cliff in the dark. Yes, it does take a bit of time up front, but not too much. And the return on investment is always worth it. How much time have we wasted on this program now that it’s in the headlines of IT News? How much time has been wasted sitting in senate estimates hearings trying to explain why we failed?
Complexity is the key driver of cost and effort. If you have no idea how complex your business and information architecture is — and you go to market and hire a systems integrator and you ask them to give you any kind of a “fixed price” contract—and they don’t know how complex your current state business and information architecture is — you’re gonna get what you deserve. The vendor will take your money, that’s for sure. And the vendor will try to do their very best to make up for their customer’s naivety. But the customer often sets the vendor up for failure.
I feel the need to throw in a metaphor. It’s like painting, isn’t it? The hard work that takes the most time when you have to paint something is all the prep work. Sanding, filling, undercoating, taping off, putting a drop sheet down to protect all the stuff you don’t want to get paint on. You do all that prep work, and the actual painting is easy, goes quickly, and the final product looks great. Crap painters are crap painters because they short change the prep work.
Programs often seem reluctant to invest a reasonable, fit-for-purpose, amount of time up front to do the prep work that increases their chance of success.
And I’m sure someone is now going to tell me:
“But doing all that discovery and investigation you say we should do — why, that would just take too long! It would take forever! And before you’re done— everything would have changed anyway! So there’s no point! You’re crazy!”
The future is already here. It’s just unevenly distributed.
But I do love a good post mortem. Here’s a picture of Vincent Price, getting ready to do a post mortem on the DHS program:
