Armchair Architects: Architecture and Ambiguity

[Guest EricCharran]

Welcome back to another episode of Armchair Architects as part of the Azure Enablement show. So today we're going to talk about something a little theoretical. We're going to talk about the relationship between architecture and ambiguity. What do you do when the specs aren't entirely clear, or the plans aren't entirely clear? What people need isn't entirely clear? We're going to discuss that with our architects.

 

 

 

It's not uncommon for people to come to architects with very vague statements or questions that aren't really precise. Or a problem needs to be solved, but it's not really clear what that problem is.

 

 

 

 

 

What can architects do to help with ambiguity?

 

 

 

Depending on the depth of your experience, you have to get more comfortable with ambiguity. I think as “answer people” our goal is to excise ambiguity. It makes us uncomfortable and the best thing that we can do to excise ambiguity is to make an assumption and answer that assumption, sometimes all within the same breath. And that's where I think the term “false precision” really arises.

 

 

 

You give a very precise answer to a question that you think will excise the ambiguity based on the software system that you're trying to build. And I think we've all been part of a software project in which you build this amazing technically engineered marvel and then you take the covers off but the customer says it’s not what they expected. You did something completely different and you said, well here were all our assumptions. Why did you make those assumptions? So false precision is a way of incorrectly and sometimes harmfully excising ambiguity. But the best advice I can give is just be comfortable with it, but seek to understand it and to excise it over time.

 

 

 

But one might say, isn't that what Agile is all about? Isn't that what Agile is supposed to solve? Where you formulate a vision North Star problem and then you iterate your way into this using code artifacts and ideally getting users involved early in those kind of things? Isn't that a solved problem?

 

 

 

That's exactly where we need to head in this conversation. Don't be in an attack sub. Don't collect a little bit of information and then go under the water and then sail around the world and surface and say, “Ta-da. Hope it's great.” Continually set expectations, excise ambiguity through dev sprints, and excise ambiguity through spikes. Continue to focus on what the outcomes are and the reason you're building the software platform. Those are the things I think are going to help you along this journey. And then continually dropping in an Agile cycle.

 

 

 

 

 

Why is this not a solved problem?

 

 

 

I think there are two pieces to this. One is a person or people thing. Meaning, if you are a person that loves certainty then going into an ambiguous situation can be stressful. You really don't know how to deal with it, and I think that's something that you need to think about when you are an architect. You have to be comfortable with ambiguity and if you can't be, then you have to figure out how to learn how to do this and not try to answer the questions with too little information. And I've seen people that are very good technical folks that are just really nervous when they don't understand all of the aspects and they can't answer all the questions that might be there. They feel very unhappy. So there's a people aspect to this and there's training for you to deal with ambiguity. You need to live with the idea that you have to learn what it’s all about. You have to figure things out step by step. That's one dimension.

 

 

 

The second dimension is that Agile is obviously a very solid way of dealing with this problem. The thing that the Agile people have realized is that without a clear North Star you can't really go anywhere because it's just not feasible to direct a team without roughly knowing what you want to achieve or where you want to go. The Agile guys called this “enterprise Agile”. I jokingly call it “water scrum”. Once you’ve identified the point, you may need to move it because the vision that you excised wasn't quite the right one. Or the vision was the right one, but the implementation turns out to be completely wrong.

 

 

 

There's a great example with Visual Studio from Team Foundation Services, or Server at the time. They had built a centralized software management system and decided they needed to become a distributed development organization in terms of source code management. At the time Git was not available when they made that decision. So they went down this path, did the planning, did all the work, and started coding. Then Git showed up.

 

 

 

So after a sprint, they could see they needed a distributed source code management system, but a proprietary implementation was not best. So they switched direction and flipped over to use Git. That's when they built the Git file system into Visual Studio Team Services. And I think that's another piece that Agile recognizes that, yes, the North Star might still be right, but you need to effectively go and adjust. These are ambiguous scenarios that both individuals and teams have to be comfortable with.

 

 

 

There are training courses available for you to learn to step back, suppress your instinct to want to know everything right away, and learn how to let the situation develop before you go into full solution mode.

 

 

 

A lot of this comes from the User Experience discipline and it's associated with making sure that you continually arrest your own assumptions. Architects need to consume the specificity and when there isn't one, it's almost like a back pressure that builds and we just fill our own false precision out into the world. And when you're doing that, it makes your customer feel good, it makes you feel good, but in the end you're going to kind of build this monster that nobody wants. I call it building the wrong thing in the right way. One of the big ways to do this is to be aware of your biases. Be aware of the information you don't have and then try to drive out the right individuals to unearth the right information.

 

 

 

Confirmation bias, for example, is one in which you have the answer in mind and you're looking for people to back up your points of view. And if anyone doesn't back up your point of view, then you don’t want to talk to them. You find others that do support your view. That might be inadvertently influencing customers to tell you what they want, but really you're kind of reverse telling them to tell you what you want. All of those dangers kind of abound if you don't focus on some of these things that are found in the User Experience discipline. What are your met and unmet needs? What are your unarticulated needs? What are some of the ways in which you wish you could solve this problem if you had unlimited time, money and effort? And then following it, drilling down into specificity with the Moneyball exercise and things like that.

 

 

 

 

 

How can you tell when you're in a false precision situation?

 

 

 

You can’t always tell right off the bat. You might think you found the right answer and you're going ahead. Ultimately you want validation, you need to run water through it. So you're making this architecture assumption. You drive the design. Now you go back to your requirements to check if you forgot something. You bring it to others for validation and get feedback before it goes too far. It's an iterative model where you think through something, propose something, get feedback, and keep iterating. And that's the key to deal with this over ambitious model. Validation, both external and internal, is the right way of doing it. And then listening.

 

 

 

Confirmation bias is also happening in product companies where people go to their friendly customer for validation. It’s better to go where they don’t like your products because they’ll be more honest and brutal than your friend will. You want perspective from people who don’t necessarily agree with you and aren’t convinced your products are good.

 

 

 

Don’t just be an order taker. Don't just listen to what people say and give them what they asked for. It's also having an opinion and challenging them enough to say, well, in the end I don't want to give you faster horses. I want to give you an automobile. So this is the way we're going to approach it.

 

 

 

Also, sometimes if you're in a false precision fueled software exercise, you might not know it until you go Ta-da, right? Make sure that as a maturing organization you focus on traceability so that every feature that you prioritize tracks back to an articulated requirement, which tracks back and collaborates with the product definition, which focuses on the North Star, and you have this library of user experience stuff associated with it. The second thing is, I often ask how do you know that? How do you know? Who did you talk to? Where is the data associated with that conclusion? Have you thought about that or is that what you believe and you want to be true? So being able to ask the questions is certainly a disarming way of challenging an assertion that could be a tenant of false precision.

 

 

 

 

 

To hear the whole conversation, you can watch the video at the link below.

 

Continue reading...