Language


James Tarbell has this great post, responding to one of the people we’ve interviewed in our research, James McGovern. James T calls out some very insightful similarities between architects and gardeners.

My favourite: “You can get hung up on understanding the big latin words/technical terms or focus on requirements to achieve a result”.

I was talking earlier on to one of the people we interviewed for the book, outlining the main findings and getting some feedback. One of the main topics we focused on was the nature of Enterprise Architecture, and what characterises EA work “done right”.

The person I was talking to relayed a conversation they had with a client recently that was interested in becoming “Zachman compliant”. The client was under the impression that if they could do this, it would be a stamp of approval that they were “doing EA well”.

I’ve seen things like this myself from time to time, and it’s worrying. Organisations set up EA teams that are naturally inclined to focus on modelling technology landscapes and so on, and that focus more on the outputs (models) than on how they arrive at those outputs.

The problem here is that the process of EA is at least as important as the outputs. “EA done right” is as much about how you conduct EA work, as it is about what you produce. EA done right involves architects engaging in truly two-way discussions with stakeholders in IT and business – sharing ideas, learning and also communicating what’s been learned so far, so everyone understands more. EA done wrong involves architects sucking ideas from the brains of “users” and not giving anything back. The architects learn more but very quickly you end up with a fundamental disconnection between business and IT and you’re no closer to developing a common language.

And this brings us back to Zachman – because although ZIFA goes further than just promoting the Zachman framework (it’s starting to promote the importance of developing a good process) there are an awful lot of people out there who just focus on the framework. And although the framework isĀ  a great way of categorizing models and knowledge, it says nothing about how that knowledge is arrived at.

If you just focus on getting good at filling in the cells in the Zachman framework, that’s no guarantee at all you will be doing EA in a way that helps IT or the business.

Interesting post here from that arch (in both senses of the word) commentator on IT and business issues, Nick Carr, on the subject of jargon – pointing to a post by another really interesting commentator, Kathy Sierra.

Carr’s main point, I think, is that buzzwords aren’t the same as jargon: jargon is of value to specialists as it helps them have specialist conversations using handy shorthand, whereas buzzwords – which often infuriate specialists – are good because (when they work) they encapsulate complicated ideas and present them in terms that non-specialists can get their heads around. In doing this, though, they can end up with rather imprecise and fuzzy definitions, which is why they infuriate the specialists.

I think the more interesting part of Nick’s post, though, is his comparison of two recent attempts to define / explain Web 2.0. Tim O’Reilly has had a stab at condensing his ideas down to a short sentence:

“Web 2.0 is the move to the internet as platform, and an understanding of the rules for success on that new platform. First among those rules is building applications that harness network effects to get better the more that people use them.”

Nick contrasts this with a definition from Wade Roush:

“a combination of a) improved communication between people via social-networking technologies, b) improved communication between separate software applications – read “mashups” – via open Web standards for describing and accessing data, and c) improved Web interfaces that mimic the real-time responsiveness of desktop applications within a browser window.”

Why is the second text is more appealing to non-specialists? Because it attempts to explain the idea in terms of the results/outcomes of the idea, not the technical details of how it comes to be.

We so often get this wrong in the world of IT – trying to explain things by focusing on *how *we built them, rather than *what* a consumer will experience as a result. If IT organisations are going to be service providers, after all, the consumers of those services are going to be shielded from the “how” anyway – all they’ll see, hopefully, is the “what”. So why try and explain what we’re doing in terms of what we’re hiding? It makes no sense at all. (As another great example, think about why “composite applications” is a crappy term).

This is something we talk about a fair bit in the book. If you want to get IT people communicating better in a business context, get everyone focusing on “what”, not “how”. It’s what makes sense from the technology consumer’s perspective.