I recently described the method I use to pick topics for posts as “some posts I plan and some just grab me”. The topic for this post seems to be in a class all its own – it stalks me. In previous posts I’ve mentioned how customers are looking for answers to problems, not technology, not artistry. Recently, however, the principle keeps popping up, prompting me to re-visit it.
Just a couple of weeks back, I was chatting with someone on the information systems faculty for a local university. One of the things she mentioned was the importance of understanding that the technology was secondary. Success comes from determining what the customer wants/needs to do, and then providing the how. It’s about finding a place in the customer’s narrative, not finding a way to use a particular technology. After that conversation, I dutifully added a note to my future posts list that it was time for a post on technology as a means, not an end. There it sat for two weeks, when Tom Graves posted his “My ‘EA Masterclass’ coming to Australia”, complete with a slide deck that included this (slide #4):
Okay, I get it – time to write the post.
In this line of work, you need to have a deep appreciation of and interest in technology. If you lack that, I sincerely doubt that you will have the drive necessary to remain current, particularly in today’s environment. Bearing that in mind, however, all the technological brilliance in the world does no good if the product in question fails to meet someone’s needs. How we do so is far less important than whether we do so. Empathy is critically important, because as Jeff Sussna observed in his “Failure == Failure to Empathize”:
When you see things from another’s perspective, you instinctively want to do something useful based on what you see. Empathy naturally drives action in response to listening.
A large part of what makes empathy so important is the architecture of the problems we commonly deal with. Rather than a single context (set of stakeholders sharing similar goals and concerns), most of what we deal with involves multiple, often competing and conflicting contexts. These conflicts are a source of challenges (obstacles to delivering desired value). As Charlie Alfred observed in “Contexts and Challenges: Toward the Architecture of the Problem”: “Tradeoffs between challenges in a context are often subordinate to tradeoffs between similar challenges across contexts”.
Technology belongs to the architecture of the solution, which, to be effective, must follow from the architecture of the problem. When an aspect of the solution does not trace back to some aspect of the problem, this disconnect should be considered a red flag. Choosing a technology for the wrong reason (“this looks cool!”) is a disservice to our customers. Design decisions not only give structure to, but also limit a system. Form follows function initially, but then function is constrained by the existing form.
As always, the most important question when making design decisions, is “why”?
[Photograph by Humanrobo via Wikimedia Commons.]
I think you have said it before, why is a critical questions but more importantly the answer that follows the question is where the information resides.
LikeLike
Exactly. The answer to the question “why” should drive your response. “Um, ’cause it’s cool” should be considered a red flag.
LikeLike
Pingback: Design Follies – ‘Can I’ vs ‘Should I’ | Form Follows Function
Pingback: Design Follies – Architect Knows Best | Form Follows Function
Pingback: Fears for Tiers – Do You Need a Service Layer? | Form Follows Function
Pingback: Fixing IT – Credible or Cassandra? | Form Follows Function
Pingback: Problem Space, Solution Space, and Tunnel Vision | Form Follows Function
Pingback: Are Microservices the Next Big Thing? | Form Follows Function
Pingback: Institutional Amnesia, Cargo Cults and Software Development | Form Follows Function
Pingback: Maybe It’s Time for Customer Driven Development | Form Follows Function