The Pragmatic Business Architect: Lessons from the Field

Something I have noticed that seems to be lacking in the field of business architecture is pragmatism.  Many BA's I speak with are frustrated at the difficulty they are having in expanding their business architecture practices and in building relationships with business leadership.  I believe this is often rooted in unrealistic expectations built from reading BA literature, listening to exaggerated success stories at conferences, and the assumption that what worked somewhere else will work for their company.  To all aspiring business architects out there, let me give you a tip: be realistic.  Business architecture is definitely more art than science.  The following are five examples of how to pragmatically approach working with the business. 

Lesson #1: Don't ask business people to fill out giant spreadsheets.
One of the earliest attempts at capability mapping at my company involved the creation of a spreadsheet with literally over a thousand rows representing capabilities down to level four, and seven columns with questions.  This was sent out to business and IT people to complete.  And people were surprised when few people completed it, and even when they did, the data wasn't very accurate.  As soon as this pragmatic business architect got involved, this process was quickly dismissed and replaced.  The new process was facilitated with the business face-to-face by an architect, only went to capability level two on a one-page visual, and in mere hours was able to identify opportunities to present to the business.  Keep it simple. 

Lesson #2: Sometimes it is about finding the right nail for your hammer.
You probably have heard Abraham Maslow's famous saying: "If you only have a hammer, you tend to see every problem as a nail."  With business architecture, you have access to an effective toolset (i.e. the hammer) for solving many, many different types of problems (i.e. nails).  I am surprised as to how often I will hear about a business problem and realize that  a business architecture practice is a great way to tackle it.  Learn all you can about different business architecture tools, processes, and techniques, and then be ready, as you never know when you might stumble into the right nail.  Helping solve real business problems is the fastest way to gain credibility and gain support to grow your business architecture practice. 

Lesson #3: Don't spend too little or too much time on visuals. 
This one is tricky.  I have heard many BA's talk about the importance of creating powerful capability roadmap visuals.  They hired graphic designers, established standardized color palletes, and delivered some seriously impressive graphics.  When I think how much time, money, and effort went into creating these, however,  I question if it was a wise investment.  The cynic  in me also imagines the impossible task of keeping these visuals up to date, and how quickly they get outdated and useless.   

On the flip side, using my spreadsheet example from above, there is clearly value in providing simple, consumable visuals that resonate with a business audience.  So what is the right answer?  The keys are to know your audience and determine the intended lifespan of your output.  Clarify what they are expecting, try to learn what will be the right format and investment for your audience, and mock up examples to show them early on.  Match the investment you make to the longevity of the deliverable, keeping maintenance in mind. Speaking from experience, it is no fun to be scolded by a senior executive for hiring a graphic designer and not being fiscally responsible. 

Lesson #4: Shiny object syndrome
Sometimes when people come to business architects asking for help, we get so excited that we run right after whatever they throw our way.  Next thing you know, we are working on every project out there, few of them have anything to do with business architecture, and the rest probably shouldn't even be projects.   

A powerful question to use to avoid this: "What problem are you trying to solve?"  Sometimes you have to ask this repeatedly.  Example: someone comes to you to find a replacement for the CRM system.  You ask what problem they're trying to solve and they say the sales people aren't using the tool.  Then you ask the question again, and they say that when they don't use the tool, they can't deliver a specific report to the CFO.  Then you ask it yet again and they say that the CFO is frustrated that she can't get an accurate view of specific financial data each month to prepare for an executive meeting.  And then you let them know that the data the CFO is looking for can easily be extracted directly from the ERP system and automatically sent to her on a monthly basis.   

Make sure you are solving the right problems.  Listen more, talk less.  And don’t run after shiny objects. 

Lesson #5: Assuming anyone in the business cares about business architecture
I rarely tell anyone any more that I am a business architect, or even tell them that what we are doing on a project is business architecture.  Why?  No one knows what it is, and I grew weary of trying to explain it.  What do I tell them?  That I'm helping to build an execution plan for their business strategy.  That I'm aligning our IT investments to what is most important to them.  That I'm aligning strategic objectives and tactical demands.  This is language that business people care about.  It is great that we have such a cool term like business architecture to describe what we do, but recognize that these words don't resonate outside of our field. 

So in summary, be pragmatic.  The goal shouldn't be about deploying or expanding a business architecture practice, it should be about solving business problems and helping the business execute its strategy.  Do this, and do it well, and I guarantee your practice will grow on its own, and you will build better relationships with your business executives.  Let the value of what you do speak for itself. 

This article was prepared by Dean Heltemes in his personal capacity. The views expressed in this article are the author's own and do not represent the view of his employer.