Blog

enterprise-architecture

The Architect as a Polyglot

world globe infront of lots of sticky notes

There's an incident from my past that still sticks in my mind as a classic technical person – business person disconnect. I forget the precise context, but one of the sales representatives had come back from a meeting with a prospect of hers, and wanted a rebuttal from our chief architect to an objection that the prospect had been fed by a competitor. Specifically, they claimed that we were limited because “we didn't do real TCP/IP, we only do network TCP/IP”. The chief technical architect's reaction was to simply say that he couldn't see how he could rebut a line like that. But the sales rep was insistent that she needed a rebuttal, and it was a technical statement. The conversation went in circles for a couple of minutes until I pointed out that the whole statement made no sense whatsoever. I never did find out what real TCP/IP was, by the way, or how it was supposed to differ from network TCP/IP.

The interesting point about this exchange, from my point of view, was that the problem came down to both parties having a different definition of rebuttal. The technical architect's problem was that for him, a rebuttal was an explanation of why the statement was wrong – and he couldn't argue against a statement that was inherently gibberish. Whereas for the sales rep, a rebuttal was just an explanation of why the statement didn't matter. All too often, I have found that misalignments of opinion or even action come down to different parties talking at cross purposes, and this is because people in different roles speak different languages.

Different languages? Surely they're all speaking the same language in a given office? Unfortunately, as the example I gave above shows, it's possible for just one word to interfere with understanding between two parties. Yet, it is possible to resolve these disconnects, just as I did above – by stepping back and considering what each parties position means from their own perspective. And to do that you need to consider where they're coming from – what are their concerns? We've talked about how different words have significance for different roles – well, concern is a word that has significance for an architect. We find ourselves in the familiar realm of stakeholders and concerns, viewpoints and views.

I've heard it said that a good salesperson speaks many languages – all the languages of the different professions that they usually sell to. In the same way, a good architect needs to be able to speak the languages of a wide range of job roles. They need to be able to speak CFO and COO. They need to be able to speak application architect and they need to be able to speak business analyst.

You can accomplish of lot this by falling back on the approach of stakeholders, concerns, viewpoints and views as mentioned above. Understanding the area of focus for someone goes a long way to looking behind the words. A second technique is to notice when certain words are used multiple times, or when they seem to take pride of place in sentences. For example, if 'risk' appears five times in eight sentences, then that's a good indicator that risk is a key concept. A third, follow-on technique is to ask your interlocutor what they understand by a given term. “What does risk mean to you?”

It's surprising how much you can accomplish by taking the time to identify where different parties are using the same words but speaking different languages. But then, if everyone in the organization was already aligned with one another, they probably wouldn't need their architects...