Avoiding Business Architecture Paralysis

A close cousin to “analysis paralysis” is BA Paralysis.  This unfortunate situation occurs when a business architect is asked to contribute to an ill-defined project within the scope of the business where the business architect is being asked to provide “insight.”  While a business architect is quite capable of applying proven research-based methods to a problem area, and producing insight into the problems of that area, asking a BA to produce insight is dangerous, for both the BA and the project team.

1. There are literally hundreds of different tools that a business architect can call upon to produce insight.  Without clear definition of the project or workstream goals, the Business Architect is left to his or her own devices to (a) select the insight tools (one or more) that could be useful, (b) decide when to use them, and (c) hope that the business would find the insight produced to be “consumable and practical” for their needs.  In this case, the likelihood that the project will view the output as a “waste of time and money” is high.
    
2. The opportunity to produce “insight” is so vague that it is very likely that the output produced by a BA will be too detailed, or too high level, to meet the expectations of the business customers.  Disappointment, distrust, and a rejection of the value of business architecture, as a practice, are the likely results.  This is very bad for the business architect, and for the effort to increase the perceived value of enterprise and business architecture.
    

When you find yourself in a situation where you are being asked to provide insight, get with the business sponsor and see if you can get the entire project focused on answering the following questions, and get this all written down in a short “charter” that everyone on the project team buys into.

1. What decision needs to be made?
   1. Is this a decision that will need to be made more than once?
   2. How often is this decision made? 
   3. What is the risk of making the wrong decision? 
2. Who is accountable for making that decision?
3. What is the relationship between the business architect and the decision maker? 
   • Direct relationship: (the decision maker has asked for the BA specifically), or
   • Indirect relationship (the BA’s insight will be given to another person to pass up to the decision maker)
   • Aspirational relationship (Is someone hoping that a BA artifact will magically find itself into the lap of the decision-maker) 
4. What information does the decision maker (expect / desire / require) to make an appropriate decision? 
   1. When will the insight be required?
   2. What format should it be delivered in?
5. What activities can the business architect reasonably expect to accomplish?
   1. Will the culture of the business support the BA in their role?
   2. Does the business need to prepare for these activities?
   3. How much stakeholder time will be required for the BA to complete these activities?
   4. Are key stakeholders available for interacting with a BA?  Are other resources required? 
6. Has the decision maker taken a specific dependency on the business architect to produce the insight? 
   1. Will he or she wait until the insight is produced? 
   2. Will the insight be respected as coming from a trusted authoritative source?

 

Of course, this is good advice for any project: know the problem you are trying to solve before you spend a bunch of time solving it.  However, I find that business folks often have trouble seeing the strategic work of a business architect in the context of a “decision support project” and therefore may overlook this basic level of understanding.  If this is the situation you find yourself in, don’t ask for the charter to be created by someone else.  Create one and go to the business sponsor to sign off on it. 

Creating a charter can go a long way towards clarifying the request for insight, and thus keeping the business architect out of hot water.