Faster to Market is not always the best policy -not what you think

Received a humorous, but truthful, comment on yesterday’s post.  A colleague of mine pointed out my poor grammar: “Brian I love this! Can I be your blog final editor though before you post these – the grammar errors are killing me 🙂.”  The comical excuse is that “I’m an architect or engineer, not a lit. major….”  or the neurological excuse: Asperger’s Syndrome.  –No, I haven’t been officially diagnosed, but those crazy online quizzes suggest I should.  Other’s chalk it up to calling me, whatever reason, a typical scatterbrain genius. Yes I’ve got a high IQ, but that nor any of the other explanations are valid excuses for not trying to improve.     

However, the plain fact of the matter is I’m always 100 miles ahead in my mind to what I’m writing down. Two of my mentors at Microsoft once commented separately: “Brian, you’re going to have a difficult time here in that you can go from A to Z in seconds in your head while others are having trouble just getting to B on paper”.  This causes me to skip words, sentences, and even whole paragraphs.  This post is an example I’ve had to go back several time to ensure I haven’t skipped something, etc.  Those that follow my word may already notice the long, well extremely long sentences….well punctuation are just friendly suggestions like road signs right 😉  The results of which is a reliance on proofing software which doesn’t always catch everything or an editor. 

As such I’m often in too much of a hurry to get my ideas down before these vanish from my current thoughts then push it out there. [Faster is not always better]  

What I’ve been doing about such 

A few years back I rejoined Microsoft’s MCS organization in an interesting role “IP Development Architect”.  The mission for such was basically empty my head of experience on various EA topics, develop approaches for the field to use to help our clients**. Basically as one of my mentor’s called it “being a brain on a stick for sale, lease, or rent”  

I took that role as a challenge to improve my writing and presentation skills; similar to the reason I took a role at IBM to learn marketing, sales, and become more outgoing (I’m an extreme introvert though you’d never know it).  During the years that followed I’ve been fortunate enough to have friends and colleagues point me to resources to help, as well as technical and grammatical editors to patch up my mistakes.

During that time I started investing in books (e.g., Peter Ingle’s Organized Writing Course, Nancy Duarte’s and Martin Sykes/Nick Malik’s books on presentations, etc.) that have taught me to put together great structure to my writings and presentations.  I actually get people asking me to do such for them or critique their work(specifically not grammar); which I’ve gladly done for many.  So I guess I’ve overcome some portion of my communication gap. 

This next twelve months with the help of my colleague, yes I’ll gladly take you up on your offer, I’ll work on the grammar portion of my writing.   

             

 ** I say clients rather than customers because I’ve always believed the company should establish long term relationships rather than transactional sales. Given the company’s strategy pivot to cloud services, I hope they are successful adopting such a philosophy.  The consequences of not doing so will be a loss of renewals in a future that depends upon good service and strong relationships.      

Philip K. Dick was right but may be wrong also

For those who are not Science Fiction fans, Philip K. Dick was a writer of notable insight to cultural trends.  His books have later been turned into blockbuster movies: BladeRunner, Minority  Report, Total Recall,  and Next to name a few.  His books had a dystopian perspective to these, where governments and social agents become tyrannical.   I will not dwell on that forecast of the future of society is this post.  One interest concept I thought interesting was his focus on media.  More specifically how the media would change.  Though the movie adaptations only hinted at it media, print for example, changed from a primarily word based format to more of a graphical based one.  Well the saying goes “One Picture…”

When moveable type was created it did two things. First it made production of information cheaper.  Thus distribution of information increased and was made available to lower income people. Second, it changed the cost ratio between text and graphics.  When books were hand drawn, the cost of graphics was on a par with text.  This ratio changed only slightly over the years until the application of computer technology.

What is interesting about this was that prior to the movable type revolution much communication was through pictures and other symbols.  Dick’s prediction of the future was a return to graphical communication and a reduction in text.  This inferred a lowering of grammatical literacy within society as a whole.  Having just complete several Government RFP response marathons where reply instructions were specific about writing to an 8th Grade level that would seem to prove Dick’s point.  However, I took a few steps back in considering such.

What came to mind were presentations and proposals I’ve seen and participated in over the years.  Many times I was privy to executive decision-maker sessions.  What struck me over the years was how these sessions have changed.  Initially presentations and proposals were fully of textual information.  A slide or page was filled with paragraphs of descriptions and opinions.  A little later after spreadsheets had become the go-to business tool, these became filled with tables of data and charts.

Then as graphic software became more capable presentations in many companies became more simple and focused.  A term which was not originally meant to be complimentary became popular code for these presentations to executives: “Big Animal Charts”  I suppose this was because someone thought reducing issues down to the simplest concept was similar to old children’s books; “See Spot Run, See Tiger run…”   A sort of arrogance was hidden in this comment lay just below the surface.  That is “I’m the expert and you’re not.  I have fancy jargon”  While jargon is useful to shortcut the communications process, its also an inhibitor for those that are not dedicated to a particular discipline or domain.  What many proposers and presenters forget, myself included, is that the presentations and proposals are not about me but about the audience.  So any means to make understanding easier for the audience is good.

Now I get back to my most recent RFP and presentation efforts.  After writing my technical responses I ran a reading level analyzer.  The results didn’t shock me.  The text was rated at Ph.D or beyond.  A far cry from the 8th grade level requested.  After significant effort I managed to reduce it down to 12th grade reading level. There I was stuck and required assistance from team mates, who thankfully jumped in.  What I found interesting beyond the reading level issue was that when I presented similar or more complex material I used very little text, choosing to use pictures, diagrams, and charts.  When I asked several audience members if the material was too complex and I should simplify it, thinking the words needed to be “dumbed down” I got a surprise.  They hadn’t even read the words, instead they got all they needed from the charts and spoken words, even though I used very technical jargon.

Which brings me back to Mr. Dick’s forecast of the future of media.  That graphics would dominate communications in the future.  Interesting points to consider: Look at Steve Jobs presentations, Nancy Duarte’s books Slid:eology & Resonate or books on Storyboarding –Hollywood’s go-to method to organize and present complex information.  All of which rely on graphics.  May be Philip was right in his forecast of the rise of graphics but others were wrong in thinking that graphics is dumbing down the communications.

Structure in Threes: Concerning Architecture

There is a broad debate within the various enterprise architecture communities 1) What is Enterprise Architecture 2) What is the value of Enterprise Architecture, and 3) Who is an Enterprise Architect and how does s/he accomplish work.  This text will present my own opinion on this topic, the three questions above, and more.  This is based upon my own experiences practicing this arcane discipline.  I do not propose this is the definitive answer to such questions –but rather an effort to document an ontology of the architectural concerns with methods and tools I’ve collated over the years to manipulate these variables– though a publisher may later add hyperbole in an effort to sell the book.

This work is being design to be used in a digital format as there will be many cross connections to the multidimensional space I believe Enterprise Architecture exists in.  If you are reading this in book form be prepared to flip forward and backward to get the full context of what is being discussed.

Structure in Threes -the Preface

Decided to start a little early actually writing the book.  I know by the start of next year I’ll have restructured the original outline to better address the objectives I have, but I though several chucks of material could be written as these are unlikely to change much in the later editing process or will just move to new locations in the book.

PREFACE

It has been close to thirty years since John Zachman coined the term Enterprise Architecture and introduced business to the Zachman Framework. Over the years the metaphor has been used and abused, technical religions have grown around methodologies and still the term Enterprise Architecture is derisive.

  • Is it an activity that produces a plan for building various systems?
  • Is it the actual plan for an Enterprise?
  • Is it a methodology to produce standard compliant designs?
  • Is it a collection of diagrams that represent different types of information about the information systems used in an enterprise (Zachman Framework)
  • Or maybe a specific set of standard components organized in a specific structured way

When I started the initial concept for this book years ago I had considered creating a text that would provide methods for designing an enterprise; this being the goal of Enterprise Architecture or at least my belief is the goal. However, over the years experience has taught me five things:

  1. Nothing is simple when explaining yourself [Lesson taught by John Zachman]
  2. Words have different meanings depending upon the context and experience of others [Lesson taught by Michael Kutcher, John Sowa, Gil Laware, and Frank Kowalkowski]
  3. The difference between a methodologist and a terrorist is that you can negotiate with the terrorist [Lesson taught by IBM CIM Architecture Department and TC184/SC4 & SC5 working groups]
  4. Thinking in the abstract and in multiple dimensions while technically possible by most, is often avoided in most enterprises in the name of speed and comprehension [Lesson taught by most managers and mid-level executives I’ve had to deal with]
  5. Nothing is foolproof as fools are so dam cleaver and Nature always sides with the hidden flaw [Murphy you were an optimist]

Those insights came to light over the years of associating and working with those I consider giants and mentors in the field. Included in this book are vignettes of how those insights were developed; if for no other reasons than to pay tribute to my mentors and colleagues and to establish part of the context for the content in the book.

That being the sand I started building this work upon, I realized I needed to answer several questions first before I introduced my approach to Enterprise Architecture. The book itself is meant to be a practical guide on “practicing” Enterprise Architecture, a theoretical text explaining my perspective on what Architecture or more specifically Enterprise Architecture is, and how these fundamentals are expressed in practice.

 

Parallel tracks: Skills transfer at work for colleagues and Structure in Threes book

Started a skills transfer series at work yesterday “Methods in Minutes” with the idea of creating short presentations on Enterprise/Business Architecture and Management Consulting techniques I’ve collected or created over the years.  Originally, I was going to collate about a dozen or so into a single methodology presentation.  However, after coming to the insight that people’s attention span today has gotten much shorter in direct correlation to the time horizon on which they work –that is many colleagues are focusing on getting just today’s stuff done or at best what’s on deck for the week– decided to just create a catalog of methods at their finger tips.  I’ll assemble them later into a IT Management Methodology later as the goal is to help colleagues and team-mate be productive NOW.

Sent out first method draft along with question “would this be useful” to the WW Architecture Community at Microsoft.  Got a resounding “yes” as well as an excellent suggestion to post these in a share or Office365 site rather than distribute via DLs or Yammer.  Looks to be a busy next year as I create and fill the catalog.

 

Joy at work

Spent most of yesterday focused on creating a draft of a slide deck.  Previously I would hurry through creating a deck.  However, now I’m having to slow down…because I will not be the one presenting to the executive committees.  So I will not be there to answer questions or bridge the gap in logic.

Over the decades I’ve loved to give presentations on the fly (Chalk Talks) as they seemed more dynamic, interactive and honest.  You’d get to address the areas of topics your audience had rather than a predefined path and conclusion.  It was more exploring the area together.  At SharePoint Saturdays –though I had a slide deck that covered the topic, I won’t follow a script– I’d typically have more “Actor’s Studio” dialogs with the audience as one reviewer put it.  I prefer dialog to speeches I guess.  However, in my role now, I have to ensure my team gets the message across accurately to Executive Management.  So spending time crafting the story and message is more important as the windows of time is so short.  It goes back to a comment I made on Facebook to a friend.  The joy in a job or role derives from developing the precision in executing it more so than the financial remuneration.

Book Title(s) and messaging insights

Started to rethink the title of current book project this morning during drive into work.  Structure in Threes maybe too esoteric for some.  Considering “Discussions” as that is what all the tools and techniques in the book are designed to provoke.  I had a few colleagues weigh in on all the methods I’ve been documenting.  One comment was that he didn’t think a prescriptive approach to Enterprise Architecture was viable.  I was rather surprised at the comment given all our discussions that these are visualization tools that help decision makers see what they are talking about and/or see the results of decisions before these are put into place.  Just goes to show you that old maxim about remembering only a small portion of what is said is true.  I’ll have to add a chapter up front on the importance of discussion verse prescription to ensure my audience gets the point of the book.