How (not) to convince an architect

I’ve been watching, with a mixture of dismay and mirth, a LinkedIn discussion between Adrian Grigoriu and a group of Enterprise Architects as he attempts to promote his new business architecture approach.  Now, to be fair, Adrian has already written and published his book, so it is a little late to take constructive criticism from his peers.  Poorly timed discussions are a dangerous thing.

One thing that is clear: the architects on LinkedIn are not convinced that his diagram is actually an architectural model.  To be fair, Adrian has dug a hole for himself by (a) insisting that his diagram is actually an architectural model, and (b) stating that it compliant with emerging standards.  The folks on the forum have rather convincingly demonstrated that both these statements are untrue.  The odd thing is: those statements don’t need to be true.  The diagram doesn’t have to be an architectural model to be a useful diagram.

Not everything that an architect produces must be an architectural model.  I think it is good when we use models because we can defend the view with data, but the imperative of an EA is to be useful first and foremost.  It is entirely possible that, in some situations, Adrian’s diagram would be “useful” without being a model.  Unfortunately, he never describes those cases, so we are left to marvel at his diagram and say “good job” without being sure that we can use it.  Personally, I don’t find it useful.  Alas.

So, what does it take to get other architects to see value in the work you do?  What mistakes did Adrian make when he started the conversation?

• First and foremost, we all have a certain amount of self confidence in the “goodness of our stuff.”  That can lead to a little bit of self delusion, and every author is susceptible to it.  The key, in a semi-scientific community like EA, is to counterbalance that natural tendency with opinions from peers in a private and trusted conversation, before you go live to the marketplace with your final product.  Scientists discovered a long time ago: peer review matters.  Get your peers to review your work before you publish it, so that you can make statements that are credible, accurate, and compelling without getting involved in pedantic discussions.
   
• Secondly, Use some of that business savvy that makes a business architect successful and consider your “idea” to be a product.  How would you market that product?  What name would you call it that would be appealing to the people who need to “buy” it?  What would they find credible, surprising, useful, compelling, and easy to share?  Perhaps if Adrian had taken a “marketing” approach to his ideas, he would not have named his framework “GODS,” presented it only from the business process perspective, or ignored the fact that he has represented two (out of dozens) of high level business models as though it were an archetype for all commercial businesses.
   
• Third, when you want others to believe you, tell a compelling story about how the product came to be, what inputs you used, what experts you relied on, how it has already proven useful in three or more places, how others can use it, and why it is important for your readers to adopt it NOW.  If you cannot weave together all of the elements of a good story, your customers won’t care and you will spend all your time talking to critics who really have no motivation to support you, but plenty of reasons to oppose you.  Not a good place to be.
   
• Lastly, know when you are selling and when you are collaborating.  His question to LinkedIn was phrased to invite collaboration, but that is not what he wanted to occur.  As a result, his purpose (advertising the book) is defeated, but more importantly, he is unable to collaborate with people who would love to help him, but cannot because he did not ask for help at the time when it would have been useful: before the book was out the door.

I wish Adrian good luck with his efforts, but more importantly, I hope to learn from his mistakes.