In this installment of StraightTalk, we are taking on a big, scary and loaded concept: business architecture governance. This topic is both filled with confusion and lack of information. (As noted by the sparse number of resources listed within More Good Stuff.) This is due in part to the relative newness of the business architecture discipline and the current maturity level of most organizations, as well as some of the history inherited from enterprise architecture governance.

So, it’s time for some straight talk and we are going to cover this big topic in two bites. This post will give us a simple and practical explanation of what we should govern. Then, in our companion post, No. 39, we will look at how to implement it. Here goes.

What is business architecture governance?

There are many brainy definitions out there for architecture governance, and you can Google them to your heart’s content, but we will not provide any official ones here because they are not guaranteed to create clarity within this context.

There are almost no formal definitions for business architecture governance and the ones that do exist tend to be narrowly focused on just one aspect. For example, some references to business architecture governance focus on the Center of Excellence (CoE) and team structure, while others focus on a process for managing changes to business architecture.

So, let’s focus on some simple truths:

1. There are multiple aspects of business architecture governance.
2. Business architecture governance essentially compares action-to-intent.
3. Business architecture governance is achieved with structures and processes to establish intent, monitor, and ensure accountability and outcomes.
4. Business architecture governance exists to provide business value and outcomes — not bureaucracy.

What are all of the aspects of business architecture governance?

We can think about business architecture governance in two categories. First, we have Business Architecture Content, which focuses on the creation and evolution of business architecture content.*

*P.S. Remember that we create an enterprise-level business architecture baseline in our repository and then we leverage that when we want to make changes to the business, and those changes are reflected in target business architectures. If this is not ringing any bells, check out our Frequently Asked Business Architecture Questions, specifically FABAQ #5: “Shouldn’t we skip documenting current state and go right to a future state?” and its associated Additional Resources.

Second, we have Business Architecture Activities (a.k.a. the practice) which focuses on the outcomes and services provided by the business architecture team.

Within each of the two categories, we also have different types of governance, because we compare action-to-intent from a variety of perspectives. Here’s a quick overview:

• Business Architecture Content Governance
  • Knowledgebase governance is performed by both cross-functional business representatives and business architecture experts to help us make sure the baseline business architecture content is correct, complete and high quality.
  • Target business architecture governance is performed by both cross-functional business representatives and leaders as well as business architecture experts to help us make sure that target business architectures are designed with integrity and align with business direction and other target architectures. (This is especially important for large initiatives such as transformations which evolve the design of the organization.)
• Business Architecture Activities
  • Practice direction governance is performed by architecture and/or business leaders to help us make sure that the business architecture team outcomes and results are delivering on the purpose, value proposition and measures of success defined in the charter.
  • Business architecture service delivery governance is performed by business architecture experts to help us make sure that business architecture services (think business impact assessment service or a target state design service) are delivered with consistency and according to the outcomes, procedures, principles, standards and best practices defined within the team’s business architecture methodology.
  • Business architecture tools governance is performed by business architecture experts to make sure that the business architecture content contained within the repository is high quality and consistent.

Make sure to check out the handy diagram below to help you put all of the pieces together.

BTW, the “Who Does It” on the diagram is intentionally generic since the who can vary by organization. Stay tuned, as we will explore more on steering committees, various types of owners and architecture review boards in our upcoming companion StraightTalk Post No. 39.

Can we have other types of business architecture governance other than those listed here?

Absolutely. Just make sure that a clear action-to-intent is being compared — and that the governance activities deliver business value.

Why do we need business architecture governance?

Historically, enterprise architecture governance has sometimes been perceived as an unnecessary layer of bureaucracy because the benefits to the business have been poorly communicated. This is an important lesson to take to heart when designing your own business architecture governance.

Considering that business architecture is becoming (or should be) a critical function of many organizations, governance is highly important to ensure the integrity of an organization’s business architecture — both the baseline and any evolution to it — as well as ensure that the business architecture practice is delivering on its intended outcomes and can scale to meet the needs of the organization.

What about other governance processes?

As with anything, we always need to remember that business architects work within an ecosystem of teams across the strategy execution life cycle. So for example, while there will be unique aspects of business architecture governance as described above, the overall enterprise architecture governance structures and processes should be considered and integrated with as well.

In addition, business architecture is an enabler for other governance processes, such as those which oversee the development of strategies and goals, the plans to achieve them, and the solutions which are delivered in support of them. (You can picture business architecture helping to compare action-to-intent at each stage of the strategy execution life cycle that we discussed in Post No. 3.)

Put it all together for me.

Okay, so if we were to create our own brainy-sounding definition of business architecture governance based upon all of this, a starting point might sound something like:

“The structures and processes to manage and control the integrity and effectiveness of all business architecture activities, and the creation and evolution of business architecture content.”

Business architecture governance is not an isolated, theoretical activity. It is about something much bigger: the organization itself. An organization’s business architecture represents the very design of the organization and target business architectures also reflect how the organization will change as a result of the strategic business direction. So, business architecture governance is actually a means of ensuring a solid design for an organization as well as its future evolution.

More Good Stuff…

Business Architecture Governance Content (BIZBOK^® Guide): Check out Section 3.2 in the BIZBOK^® Guide (Business Architecture Guild^® membership required) for some information on business architecture governance. Note: This section actually focuses more on the business architecture team structure and roles, which is equivalent to what we’ve covered more extensively as business architecture practice-related topics in the following StraightTalk posts: No. 4, No. 5, No. 6, No. 7, No. 8, No. 33, No. 35, and No. 36.

The 7 Styles of Enterprise Architecture Governance (Simplicable by Anna Mar): An interesting take on seven common models of EA governance centered around who has decision making authority.

As Work Gets More Complex – 6 Rules to Simplify (TED Talk): An engaging TED Talk by Yves Morieux on how to manage the new complexity of business without getting complicated. His six rules not only guide us towards simplicity but also towards better ways to govern and manage quality.

 

In this installment of StraightTalk, we will explore another important topic to making a business architecture practice successful: business politecture. Yep, that is business architecture + politics = business politecture. This post is the bookend to No. 34 on business marketecture, both of which remind us that there is more to introducing business architecture to an organization beyond the models.

What is business politecture?

Business politecture is the careful handling of the challenges that arise with the introduction of business architecture to an organization.

There are a couple specific areas from which pushback and various behaviors originate, in reaction to change:

• Introduction of the business architecture team – This results from the existence of a new business architecture team, and includes adoption challenges related to getting people to use the business architecture, other teams to partner with the business architecture team and leaders to invest in the practice—primarily because they do not yet understand. Believe it or not, this can be the easier of the two to manage.
• Application of the business architecture discipline – This results from the usage of business architecture over time and the mindset shift that goes along with it, which requires new thinking and behaviors to do what is best for the enterprise, like collaborating across business units and making different decisions about where to invest based on the objective big picture. This includes adoption challenges related to getting people to use the business architecture for increasingly larger and more important scenarios—primarily because it requires them to act differently. This one may not show up right away but is the more serious of the two to manage since it is related to a much deeper level of change.

What are some examples of situations where business politecture is needed?

Here are a few common situations requiring business politecture:

• “I don’t want to engage in this business architecture stuff.” – Comes from individuals with a whole range of resistance types (e.g. reluctance to participate as a subject matter expert to develop the business architecture or reluctance to use business architecture as part of their role) and for a whole range of reasons.
• “I don’t want to partner.” ^† – Comes from individuals within related teams who do not yet understand business architecture, do not want to change or see it taking some of their power away (e.g. strategy team members who are used to defining initiatives without the business architecture translation in the middle or business analysts who are used to doing all of the upfront work with the business versus consuming business architecture as input).
• “I have a better way.” ^† – Comes from individuals within related teams or otherwise who believe they have a better framework or approach, again because they do not yet understand business architecture, do not want to change or see it taking some of their power away (e.g. an individual who created an alternate capability map-like structure that gained traction or a business process analyst who feels business architecture is replacing some of their role).

^{† When defined correctly, business architecture never overlaps or competes with other teams or disciplines. These concerns are usually a function of misunderstanding. Post No. 5 has you covered for the details on how the business architecture team integrates with others.}

Why do we have to deal with business politecture?

Because we are introducing change. This is all about the human stuff. People react for all sorts of reasons: because they don’t understand, because doing things differently requires more work or requires them to do things they don’t want to do (e.g. be transparent, be accountable, make decisions or pool funding with other business units, etc.), because they perceive a loss of power, because they feel they have higher priorities, because they wish it had been their idea, and on and on.

If you thought the business architect role was just about the models, remember that the change business architecture makes is much deeper than that (and thank goodness). At the end of the day, our impact is about much more than the business architecture itself—it’s about a new vision for strategy execution and working together as an enterprise.

The existence of business politecture is a good indication that you’re doing your job well to lead the organization to a more effective and agile state.

In addition to politecture, here are a few other important things business architects do—outside the job description.

How do we recognize business politecture?

Sometimes the resistance is overt, like when someone tells you that they or their team will not be participating in your upcoming business architecture development sessions because they don’t see the value.

In other cases, it may be much less obvious, like when someone does not want to sign up for new levels of transparency or accountability in what they do, but the resistance comes cloaked in something friendly like, “we think business architecture is a really great idea and we support it but we just don’t have time for it now.”

How can we succeed at business politecture?

Here are a few tips:

1. Have the right mindset – This will go a long way. Take a step back and remember the context: you’re introducing something brand new to most people which not only requires change but is contrary to typical thought patterns, requiring a shift from siloed and short-term thinking to big picture and longer-term thinking. You’re climbing a metaphorical mountain here to change the organization and culture, and it happens one step at a time. (And sometimes you have to go backward or stay in place for a while before you can keep going.)
2. Be proactive – Do the work upfront to socialize the practice, build partnerships with other teams and integrate business architecture into the fabric of the organization. Good communication and outreach can head off many challenges and conflicts before they happen.
3. Enlist help – When things get really challenging, escalate the issue to your leaders and enlist your business architecture advocates to help you work through a challenge head-on.

Who is responsible for dealing with business politecture?

The leader of the business architecture team (and their leaders) will likely handle the majority of the really tough conversations and the politecturing so that the rest of the team can focus on the architecture and delivering value. However, at a minimum, every team member should be comfortable describing the business architecture discipline, its value and its intent—and some may indeed have to deal with politecture as part of the initiatives they are working on.

Closing Thoughts: Shout out to all the business architecture teams who tirelessly work through challenges and business politecture to start, grow and sustain the business architecture practices within their organizations. Here’s to you. You make the discipline real and make your organizations better every day, one step at a time.

More Good Stuff

Why Organizations Don’t Learn (Harvard Business Review): A few deeply ingrained human tendencies to be mindful of that interfere with learning (and changing), along with how they can be countered.

Carol Dweck: A Summary of The Two Mindsets And The Power of Believing That You Can Improve (Farnam Street): Great stuff here on human motivation and mindsets, and important considerations when introducing change.

All Management is Change Management (Harvard Business Review): “View change not as an occasional disruption but as the very essence of the management job.”

Where’s the King of the Ants? (Seth Godin): This blog post reminds us that culture is a powerful force available to us—and we create it.

15 Things Highly Confident People Don’t Do (Lifehack): A good list to inspire you to just do it when it comes time for the hard conversations and actions.

Lead and Be the Change (TED Talk): Mark Mueller-Eberstein speaks on the Theory of Transition by revealing that emotions such as denial, anxiety, fear, and confusion can eventually lead us to discover new opportunities in the transition, by where we can become excited and strive for change, not only for ourselves but everyone around us.