A 'Simple as Possible' Enterprise Diagnostic Method

Comments: 2
Rate this:
Total votes: 0

I suspect we all agree that it’s very important for business architecture to demonstrate valuable results in a reasonable timeframe.  There is nothing more discouraging for business architects and their sponsors than effort spent on modeling for its own sake, or continuous planning to plan the plan.  Here, in this article, we have a method that quickly leads to tangible results, while building the foundation for a continuous flow of valuable results from business architecture.

When we talk about the architecture of a business or enterprise we are talking about the way it is structured for performance, within its unique and evolving context.  The discipline of business architecture calls for explicit architectural descriptions of how our organizations relate to external parties, and how they are internally structured to do so.  The focus is on interfaces among organization elements, rather than fully detailed design of the various elements themselves.  

A useful (but not exhaustive) list of types of organization elements would include roles and role players, information structures, agreements, resources, procedures, rules, standards, regulations, information management technology. A short list of interface types would include relationships among role players via services, data flows between data stores and applications, communications channels among organizations, including process steps and procedures. 

Rigorous and timely description of such a set of elements and interfaces is daunting, to say the least. The burden on a business architect or architecture team can really feel overwhelming.  When we add to this the recognition that all these elements and interfaces are in a constant state of flux, further complicated by a variety of work cultures and languages, it’s easy to see how business architecture efforts get bogged down, become ineffective, and are often simply abandoned. 

The method proposed here enlists individuals across a business to participate in the capture of a simple but powerful subset of its architecture as it exists in its current state. Participation in this effort is motivated by a serious, work-related game, or competition.  This method supports key business architecture artifacts, such as Value Stream , Value Network , and Value Chain  models.  This “simple as possible” diagnostic captures interfaces, compatibilities, and the flow of value within the business and with its various stakeholders.

Steps

1. Determine applicability
The first step for this method is to identify opportunities to apply it effectively.  This method can be used whenever we suspect or see evidence of organizational disconnects that need to be addressed. 

2. Select scope
This method can equally address the entire business or enterprise, a business unit, a department, an agency, or a leadership team.  It is always necessary to get management support to involve members of an organization in enacting this method.

3. Tailor Information Capture
At the chosen level and scope of the organization, people (managers, leaders, workers) are asked to respond to two basic “what” questions:

  • What do you do, and for whom?
  • What do you need (in order to be able do what you do) and who needs to provide what you need?

These two basic questions can lead to specifically tailored follow-on and supplementary questions, involving the nature of the work, the results expected, and various interactions with role-players inside and outside the business.  But the two basic questions focus on the key interfaces in any business – who does what, and for whom.  

These basic and extended questions probe for quality and satisfaction issues among those who provide services and those who receive those services. In other words, what are the sources of value?  These should be very open-ended questions, which can generate rich insights into the architecture of structure for behavior.  

4. Administer capture
There are many ways to actually capture the distributed responses to “who owes what to whom.”  There are many free or inexpensive ways to set up and administer a survey, or forms to ask questions and capture the answers.  The tool is not as important as the preparation of the participants, who ideally are enthusiastic about the potential to improve their working lives.

Each provider/receiver pair can be seen as a team.  These naturally-occurring pairwise teams provide the basis for a serious game, or competition.  This can work whether or not the participants know they’re in a game.  The best-matching narratives can be publicized, highlighted, or rewarded in more tangible ways.  The whole point is to encourage cooperation, so if the pairs know they’re competing against other pairs, and collaborate in their answers, this actually improves business health.


5. Analyze the Results
This key step of analyzing the responses from participants consists of comparing the answers provided by the different players.  For every participating party we should see at least one counterparty, looking upstream and downstream in the flow of value production.  In other words for every provider there should be at least one receiver, and for each receiver there should be at least one provider.  If such counterparties are missing, this indicates an obvious disconnect in the business. More commonly we want to determine the level of match.  Does the receiver’s answer match the provider’s answer?  What gaps exist? What contradictions exist?

A perfect match between provider and receiver perceptions generally signals a healthy condition.  This is the case where both receiver and provider describe a recognizably identical situation.  To the extent there is a mismatch, there may be an enterprise health issue. 

6. Targeting improvements 
This method provides immediate opportunities to improve the health of the business.  We may see a missing or ineffective interface between the brand image as projected by the messaging of the business, vs. the actual delivery of experiences to the marketplace of clients or customers.  We may find a maladapted interface for delivery of data from an engineering function to the billing and accounting functions.  Or maybe we see a cumbersome interface between regulatory requirements and adaptive compliance.

Even with a clear common understanding of need and provision, there can be unhealthy issues of poor quality results or unwelcome manner of delivery.  This is where it’s useful to build on detailed questions that drill into the details of “What do you do?” and “What do you need?” 

7. Tailor survey
Based on what the business learns through this method, and the changes we have made as a result, there is always the opportunity is to upgrade and extend this simple method. This step can revisit the questions that probe organization interfaces. The game can be expanded to a wider set of participants.  It can b re-administered to gather additional information about matching and mismatching narratives, thereby providing material for ongoing diagnostic and improvement approaches.

Conclusion
Here we have a method that accomplishes two things:

  • It elicits rich, highly credible input into various business architecture artifacts (value nets, chains, webs)
  • At the same time, the method addresses health issues and health improvement for the enterprise

This is architecture work that changes things and that does things. This is not modeling for its own sake, but for knowledge navigation, and for business improvement.

 

[1] Ulrich, W & Jim Rhyne, J, “Business Architecture: The Real Tie that Binds” 

[1] Allee, V, Value Networks and the True Nature of Collaboration, Meghan-Kiffer Press, 2015

[1] Grigoriu, A, “Business Model as a Value Chain”

Comments

Ankit Tara
,
posted 7 years 33 weeks ago

I am surprised at how

I am surprised at how perfectly this method aligns with something I have been doing in the process of building business area strategic roadmaps. These are plans for making IT investments over a 3-5 year period, one for each of a number of very large operational units, eventually rolled up to an enterprise plan. I do capability-based planning in my role as enterprise architect. Operational units, even in health care, my industry, are not independent. So we involve a number of stakeholder organizations in different ways. One of the techniques we use is the focus group. We limit them to one hour, the number of participants to 5, and the number of questions to 8. That includes a couple of warm-up questions, and the "anything else you would like to say?" close. We ask what you list in this post, record all responses, anonymize them, and use them to inform the planning process, actually driving different investment choices. We have other ways of eliciting information from stakeholder groups -- journey mapping workshops, including external stakeholders in the working groups, requesting & accepting written suggestions, and others. What I like about these questions in the focus group format is that we can and do accomplish this on the phone in an hour, and elicit astonishingly rich content.
Ankit Tara
,
posted 7 years 38 weeks ago

Hi Doug, I've also used this

Hi Doug,
I've also used this approach with great success - generally to study a particular business process rather than the overall operating model - to identify improvement opportunities. I found that visually mapping the lines of communication and data flows, between providers to users, was a particularly valuable. It frequently takes a LARGE piece of paper; at times we've resorted to a flatbed printer to create the final, report version, but using hand drawn and annotated data flow models, created with users on-the-fly is by far the best way to understand what's really going on - rather than what everyone thinks is going on.
Comparing what a recipient of data wants from a provider, and what the provider thinks the recipient wants (and hence what gets sent) is very valuable. Once the whole data flow map has been constructed it becomes a great artifact to share across with process owners and players. Enabling everyone to see the end to end process and how data and information flows is very useful, and sometimes the first time some people have seen where their activities fit. I've been involved in pieces of analysis in which several different groups thought they were the (single) source of data for a particular consumer; and cases in which groups had exactly the data a consumer needed, but the consumer wasn't aware it was available, or who had it. Complex, fast flowing processes with lots of functional inputs - like engineering change management - can create the pressures and opportunities to introduce "short cuts" that may circumvent the configuration management rules the business assumes are in play. I've experienced cases where "short cuts" have become embedded, and become the business-as-usual process, operating in parallel with the "controlled" process the business thought it was running. I think the secret of using the sort of approach Doug has outlined successfully is to make the exercises "short and sharp". Undertake a series of very quick studies, engage with the people doing the work and get their ideas about what's working, what's not working and why. Feedback the findings quickly and keep iterating. There's a good fit with Agile Development, but extra challenges and risks introduced by trying to keep the analysis / process improvement activity tightly engaged and probably better separated, into a conceptual design phase.
Jeremy

Join the Discussion

Remind me later

If you wish to make a purchase today and experience an error with the shopping cart, you can place your order over the phone. Please contact us at (508) 475 0475 x15 or toll-free within the U.S. at (855) 300-2686 x15.