Talking to customers of Enterprise Architecture services

Today, the wonderfully clever Kevin Smith of PEAF fame began a discussion in the Australasian Architecture Network LinkedIn Group.

If I understood Kevin correctly, the general ideas of the discussion were that EA practitioners should be looking at “taking the architecture [conversation] up the food chain (out of project land and IT and into management).” I broadly agree with the view that EA should be part of the organisational management conversation but I would say it slightly differently. I would say that we should “push the conversation up to management AS WELL AS into project land and IT” and indeed onto all relevant parts of your business.

Kevin makes an insightful comparison between Deming & TQM, against Zachman and EA. Kevin “advocate[s] that anyone involved in EA should adopt this approach for explaining EA in order to get organisations to adopt it.” It is an adept comparison of methodology but I do not agree that it is a good way to explain EA to management.

I simply think that it is an unnecessarily complicated approach to the task. Indeed, this over-complication is something that we EA practitioners can often been guilty of. It is understandable that we tend toward highly evolved language because we need precise semantic meanings to communicate with each other and with technical experts. So we tend to use specific and highbrow language but (and I have no doubt that Kevin would agree with this) we should really be striving to use language that best communicates our meaning to the person we are speaking to. I also believe that EA can be described to most people in very simple terms.

Is it not enough to explain EA to executives by saying, “EA (verb) is a decision support tool. The enterprise architecture (noun) provides an evidence-basis to support decision-making. EA can help executives make decisions about strategy and it can help implementers make decisions about how to implement.”?

When EA practitioners say “domain modelling”, can we not explain it to most stakeholders as “a way to put things into categories so that we can sort them and identify where there is either too much or too little of each type of thing. This can also help us understand the costs and risks for each category.”?

When EA practitioners say “reference architecture”, can we not explain it to most stakeholders as “a system for sorting things, like the Dewey Decimal System used in a library to help you sort types of books.”?

When EA practitioners say “alignment mapping”, can we not explain it to most stakeholders as “a way of showing how things connect, like the parts list and assembly instructions in an IKEA product.”?

In these days, where optimizing customer experience is essential for success, EA practitioners really need to think, “how can we optimise the experience of the customers of the EA services that we provide.”
Famed architect Vitruvius’ wrote in his book “De Architectura” way back in 15 BC that all architecture must be 3 things: “useful, solid, beautiful.” Simple forms of communication lead to each of these 3 fundamental goals.



I just discovered that Brad Meyers posted something similar in 2008 (4 years ago). Proof that every good idea has already been had by someone else. :-)

He also added some good pragmatic advice for practitioners

Brad Said … Alex Adds …
Use analogies wherever possible. Storytelling makes the concepts accessible and memorable
Use terminology your organization if familiar with. The point of this post.
Don’t assume a shaking head equals comprehension and understanding. They could be trying not to fall asleep.



Share this page:
  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • email
  • LinkedIn
  • PDF
  • Tumblr

About admin

Enterprise Architect