Leaving a Legacy: How to Deal With Legacy Business Architecture Challenges

We’re back with another installment in the “how to deal” series. This post focuses on how to deal with legacy business architecture challenges (a.k.a. you realize the business architecture knowledgebase you built is not quite right). This is a common situation for business architecture teams which have been at this for awhile—though there are important lessons to heed here for new teams as well.

What are some common challenges to watch for?

Here are the most common things that happen in organizations:

Your business architecture does not align with the current industry principles and best practices – This happens the most frequently with capability maps* and value streams, but can apply to any domain within the business architecture. For example, many legacy capability maps are closer to functional decompositions or some sort of process groupings versus being business object-based as defined in the BIZBOK^® Guide. Sometimes legacy value streams can turn into something more like high-level processes or end-to-end life cycles, and often have more of an internal focus versus the intended stakeholder value focus.
Your business architecture is not centralized – This is when multiple different business units or product areas create “their own” business architectures. There is a lot of flexibility in practicing business architecture, but one of the most fundamental and immutable principles is that there must be one business architecture for an organization (unless it is a conglomerate or another special situation). Otherwise, we are just recreating and enforcing the silos in place today—when the focus of this discipline is to bring them together. More on this foundation in No. 12.
The scope of your business architecture differs from the industry definition – The scope of what is and is not business architecture has been concretely defined for some length of time by the Business Architecture Guild^® in collaboration with a number of other industry organizations. However, it is not uncommon for organizations to define the scope differently—either by leaving out some key domains (e.g. products and policies) or adding in some extras (e.g. process, which is not “part of” business architecture, but rather is a related discipline which is aligned with it). No. 1 lays out the scope of business architecture.

* P.S. Speaking of industry alignment, the BIZBOK^® Guide has standardized around the term “map” versus “model” (e.g. capability map not capability model).

How do these challenges happen?

It’s all good. It’s usually due to the fact that the business architecture discipline has evolved, matured, formalized and standardized to a great extent over the years, especially with the formation of the Business Architecture Guild ^® in 2010 and everything that has come with it. That includes as the BIZBOK^® Guide (body of knowledge), global business architecture practitioner collaboration, certification, training accreditation, standards establishment and more.

Misalignment can also happen when organizations do not invest properly in their business architecture team or practice in the beginning, leaving the success of the practice to be based on Google searches versus solid training or help.

If you work on a new business architecture team, you have the opportunity to get started off on the right foot and build a solid foundation from the start. (And hopefully, you won’t ever need to read this post again in the future after you’ve built your architecture).

How do we know if our business architecture is industry aligned?

It’s best to go directly to the source. Review the principles, best practices and examples in the BIZBOK^® Guide (and any Guild webinars) to understand the industry direction and then compare your business architecture to it. You can also consult with an expert to help you through this process. (Just make sure they are aligned with the BIZBOK^® Guide, not their own definition of business architecture.)

Our organization’s business architecture is not fully aligned with the industry. But really, so what?

This is not about an academic discussion (and if it was we wouldn’t bring it up because we are focused on practical business value). The benefits of aligning with industry principles and best practices are:

It works – The industry direction has been built by practitioners globally from all sorts of different organizations and geographies, based on years and years of experience. And it works in practice. For example, the idea of building a business object-based capability map was created out of the need for an entirely unique view of an organization that highlights areas of sameness and potential collaboration—not another one which reemphasizes the siloed views we have today.

It greatly increases effectiveness – Not only is the industry direction based on what works in practice, but when practitioners and organizations adopt a common frame of reference (which is what we architects are all about) it makes learning from and collaborating with each other easier, hiring new business architects for our team easier, and getting up to speed easier.

Both of these reasons equal less time building and arguing about business architecture, and more time actually using it, because our jobs are to deliver value to our organizations.

What next then if our business architecture is not fully industry aligned?

If you are asking this question then you’ve already taken the first step. First, take comfort in the fact that this is always a journey and you are certainly not alone. Take the time to fully analyze the situation and determine what steps need to be taken. Start by fixing your capability map and value streams (or creating them if you don’t have them). Refer to No. 22 for some tips on how to quickly and effectively build a business architecture knowledgebase. Enlist an expert here if you need one.

Some organizations phase in changes to their business architecture over time and some make all of them at once and roll them all out together. The best approach depends on your organization dynamics, such as the level of usage and adoption of your business architecture. Socialization and messaging are very important here so that everyone understands why the changes are being made and what the benefits will be.

Okay, details, details. What do we do if our capability map is not industry aligned?

The quick answer (which applies to capability maps as well as any other aspect of business architecture) is that you have one of two options here: fix it or rebuild it.

Keep in mind that fixing can take a lot more time (and headache) than rebuilding it from scratch. The diagram below lays out a thought process to help you decide and move forward.

But what about all the things we have tied to our current capability map?

Organizations frequently have many system applications or other types of content cross-mapped to their capabilities. Here are a couple commonly used options to address this:

Update the cross-mappings from the legacy capability map to the new capability map now.

Create a translation between the legacy capability map and the new one, and allow the legacy capability map to be used for the existing relationships (this is a good solution to allow for the new capability map to prove itself and be phased in later).

In each of these cases, communication and partnership are key to success and adoption.

What do we do if we’ve built our business architecture in a fragmented way across business units (or product areas or projects)?

To fully leverage the business architecture discipline within your organization, you will need to transition to a centralized business architecture knowledgebase. However, make a plan to get there over time.

You can and should start now by creating an enterprise-wide capability map and set of value streams. You can either build them by rationalizing and consolidating all of the individual capability maps and value streams—or you can rebuild from scratch. Often the latter is easier and leverages the hard work and content that went into the individual views, yet facilitates a new level of collaboration and creates a collective team result.

What do we do if we’ve defined the scope of business architecture in our organization differently?

If you’ve put fewer domains in the scope of business architecture, the answer is easy. Identify what is missing and build out that content over time. Once capabilities and value streams are in place, everything else can be created opportunistically as you have a real business need to use it. More on that in post No. 13.

If you’ve put additional domains in the scope of business architecture that should not be there, this can be a bit trickier. But again, determine where you want to go and make a plan to get there over time. This might include finding new owners (and redefining the business architect and other roles) for things you’ve included in scope which are actually separate disciplines.

Closing Comments: Business architecture is a continually evolving discipline and that’s part of what makes it so exciting. Stay on top of future developments—and even better, become a part of the global community that is shaping them.

More Good Stuff…

20 Minute Capability Mapping and 20 Minute Value Stream Mapping (BA Guild webinars): Two of the most listened to webinars on capability and value stream mapping. These are Guild classics and essential if you are building—or rebuilding—your capability map and value streams.

Business Architecture Reference Models (BIZBOK^® Guide): You can view business architecture reference model content in Part 8 of the BIZBOK® Guide (Business Architecture Guild^® membership required). Downloadable content is also available (free to members) in the Store.

Join a Guild Group (BA Guild): Join a Guild collaborative team to help shape capability maps, value streams and other reference models—or contribute thought leadership on a variety of other important topics. (Requires BA Guild membership.)

What is Business Architecture? (S2E white paper): Just in case you missed it, this white paper is a really handy one that breaks down what business architecture really is—and isn’t.

5 Ways to Leave a Great Legacy (Huff Post): Just for inspiration. Because legacies are for more than just business architecture.

5 Ted Talks to Help You Live a Rewarding Life & Create a Legacy (Bonne Vie): A compilation of five incredible TED Talks which teach us the key skills and mindset needed to achieve success and joy in life, and work in a way that inspires others. These are worth your time.

How to Deal With Strategy Challenges: Bad Strategy, Non-Strategy, No Strategy

Our next few posts will focus on some more advanced situations that we business architects often run into. We call this the “how to deal” series. If you are in the throes of a maturing a business architecture practice, these posts might be right on cue to remind you that you’re not crazy and give you a few ideas. If you are working in a new business architecture practice, these can help prepare you to address, and possibly prevent, some of these challenges you may encounter in the future too.

This post will focus on how to deal with strategy challenges. While there are many common challenges in this space, since we are StraighTalkin’ here, we’ll just lay out some of biggies and then get right to the point on how to deal. (Read: The complete answers to these questions are fairly substantial and nuanced, so our goal here will be to point you in the right direction.)

P.S. No. 3 is an essential pre-req for this post to help you understand business architecture’s role in executing strategy and other business direction. No. 12 might be helpful too.

My organization’s strategies and objectives are documented at a very high level. How do I translate them?

This question sometimes also boils down to “you had me at ‘business architecture is the bridge between strategy and execution,’ except when I tried to do it, it didn’t seem quite so easy.”

First, you’re not alone—or crazy. Having strategic direction that is articulated at a high level is a common challenge in many large organizations, and trying to translate it has led to all sorts of other challenges like building redundant solutions, missing the mark on delivering to customer needs, or not being able to execute at all.

Reminder: This challenge is one of the reasons why business architecture is so essential. This is the hard stuff. This is the reason we exist. If it were easy, we wouldn’t have this challenge in the first place. But, the great news is that business architecture helps us to translate all of our strategies (and other types of business direction) into a rationalized, cohesive, coordinated and actionable set of changes across the enterprise. This is one of the most valuable things you can do as a business architect. You will provide your organization with an enhanced ability to effectively execute on direction—so that it can compete and continually adapt to constant change.

Since there is often a big leap between that high-level strategic documentation and what people actually need to do with the business and technology environment to get there, here are a few tips for translating strategy.

What Doesn’t Work: Tell Me All The Answers. Don’t ask your leaders/strategy team to step through every detail about what the strategy means and every single step they think is required to carry it out.

What Does Work: Leadership and Partnership. Ask your leaders/strategy team to walk through the strategy along with any overall courses of action they had in mind, and then going back to them with a draft of business impacts and changes to iterate on (framed by business architecture) along with any smart questions and observations.

Tell me more. What steps do we go through to translate strategy?

Briefly, it goes something like this:

Do Your Homework – Take time to really understand the strategic documentation and ask questions. Ideally, a business architect(s) would be involved upfront while the strategy was being formulated to help inform it, but sometimes we just consume it after the fact until we’ve reached that point of maturity. This step might also give you an opportunity to help clarify and visualize the strategic direction with some strategy mapping techniques.
Ensure Objectives Are Clear – Objectives are the key pieces that will go into the business architecture knowledgebase, which we will cross-map to our value streams, capabilities and initiatives (to give us that great end-to-end traceability). As a result, the corresponding objectives must be clear, measurable and detailed enough to act upon. (Yes, SMART objectives.) This may require some conversations and iterations with your leaders/strategy team, and you may need to do some additional objective mapping and decomposition.
Identify Business and Technology Impacts – For each objective, first identify the value streams impacted, then the capabilities within those value streams that are impacted. (And, if you have done capability and value stream assessments like we discussed in No. 28, then you will understand their current state effectiveness and overall strategic importance.) Now you have the keys to the kingdom. If you’ve built out your business architecture knowledgebase, you can now quickly understand impacts to everything else like business units, products, stakeholders and other initiatives. If you’ve cross-mapped your business architecture to the IT architecture and other disciplines like process, you can also quickly get to the full scope of impact on the operating model (a.k.a. people, process and technology) as well. Boom.

The handy diagram below illustrates all of that.

Hint: If you are struggling to identify which aspects of the business architecture are impacted by an objective, try identifying one or more course of action that is required to carry out an objective first. This often clarifies and breaks it down into simpler terms and something more concrete that you can work with. Being able to identify relevant value streams and capabilities stems from your understanding of the organization and your business architecture, though sometimes you can use “keywords” in the strategy documentation to help you find them too. This is the reason why business architects (at least those with these more advanced responsibilities) should ideally come from within the organization, be highly experienced, and have the ability to think strategically.

Articulate Business and Technology Changes – For each impacted aspect of the business architecture (with a heavy emphasis on value streams and capabilities) and IT architecture, indicate what exactly is changing. For example, does a new capability need to be created? Are changes needed to an operating model aspect to improve the effectiveness of an essential value stream stage or capability before we can leverage it? This inventory of changes is important—especially if you’ve oriented them around value stream stages and capabilities. You can use it to communicate and build consensus, to serve as input to target state architecture design (for really big changes), to scope and define initiatives, and as the common key for reconciling with all of the other strategies and initiatives to make sure that everything is harmonized.
Architect Changes, Plan Initiatives, Execute Solutions and Measure Success – Once you’re passed this tricky part of the “translating,” now you’re into the rest of the strategy execution life cycle. More details on that in No. 3 and The Strategy Execution Metanoia white paper.

The strategies and objectives across my organization don’t exactly seem to fit together. What can I do as a business architect?

Sometimes it is hard to tell how an organization’s strategies fit together or they don’t seem to. For example, business unit strategies and objectives may not be mapped to—or don’t seem to directly fit with—the overall corporate strategy. Our organizations may have a number of other strategies going on as well (e.g. digital strategy, workforce workplace strategy, etc.) that may or may not be aligned.

First, step back and soak in all of your organization’s history, structure, culture and dynamics. There are likely many root causes that created this challenge (e.g. siloed structures and motivation mechanisms) and perpetuated it (e.g. preference for a lack of accountability).

As a business architect, you can start by understanding, communicating and visualizing the full picture (e.g. competing objectives, outlier objectives, unsupported objectives)—objectively using business architecture—and asking the tough questions. You can also paint a picture of what a new vision for coordinated strategy execution might look like. Start here, stay passionate, and help be an agent for change over the long-term.

My organization doesn’t really seem to do strategy. What am I supposed to translate?

No strategy. Okay.

What Doesn’t Work: Telling your leaders that they are not strategic, that there is no strategy (they will likely disagree) and that they need to create a real strategy now.

What Does Work: Helping to bridge gaps, and be a visionary and agent for change.

To move forward in this situation, work with your leaders/strategy team to identify what they think is the strategy and the strategic priorities. Go through the strategy translation approach described earlier in this post, even if you have to make an even bigger leap to identify the impacts and changes needed to the business and iterate with them. This process may help them to better articulate where it is they really want to go. Perhaps the process can even illuminate gaps and opportunities to do some real strategy formulation going forward.

Another creative solution to this challenge is to reverse engineer the organization’s initiatives into the strategy and direction that they are leading to, stated or not. This can then be reviewed with leaders for decision-making and course correction if necessary.

Use business architecture and your role as a consultative business architect to objectively communicate new insights and enable leaders to think differently and achieve their goals.

Our organization does not want to do strategy anymore because we are trying to be agile. What do I do in this case?

This perspective has been emerging for a while now. Many organizations are going through a lot of change, including learning how to be more agile in the future. However, this perspective likely results from swinging the pendulum too far and losing sight of the bigger picture.

The quick answer is: this is not the right answer. Check out More Good Stuff for some articles to help you make the case for how an organization can still be decisive about direction, but allow room for flexibility.

My organization’s strategies don’t really seem like strategies. What do I do in this case?

Honestly, there is some bad strategy and non-strategy out there and the art of good strategy formulation has been lost in some organizations. Strategy is about choices. Strategy is not operational effectiveness, agility, being lean, general statements like: “high quality, low cost, great customer experience,” or making incremental changes during annual planning. There are a number of excellent articles in More Good Stuff on what strategy is and is not.

Here again, though, trying to translate these ideas which may be called “strategies,” can be very difficult because they leave a lot of room for interpretation and do not make choices. Refer back to the answer above on having no strategy and follow a similar approach.

My organization has strategy, but as a business architect, I’m just not getting access to it. What do I do?

Reminder: Business architecture is probably new in your organization and it’s a new discipline to most people, so don’t take it personally. This is about change.

The first step is building a relationship with leaders and the strategy team(s). Educate them on the role of business architecture and how it can make them—and the organization—more successful. Find ways to begin working together until you’ve fully embedded business architecture into its intended role between strategy and execution. This may take patience, persistence and time.

Ideally, business architects (or a subset of them on the team) should be involved upfront with leaders and strategy teams to inform the strategy as it is being formulated. However having a seat at this table is not given, but rather it is earned based on value, ability and respect.

Closing Comments: Stay passionate and persistent as you work towards your vision of business architecture and better strategy execution for your organization. The role of a business architect is to be an architect, a leader and a change agent. This is not always an easy journey, but every day you will make progress, and in the end, it will be worth it to your organization and your career.

More Good Stuff…

What Is Strategy? (Michael Porter in HBR): This one is just classic.

Your Strategic Plans Probably Aren’t Strategic, or Even Plans (HBR): An article on what strategy really is—and is not.

The Perils of Bad Strategy (McKinsey): An article on bad strategy and its root causes—as well as hallmarks of good strategy.

Strategy Talk: Can Strategy Be Decisive and Flexible? (Strategy + Business): An article on how an organization can be deliberate and decisive about essential choices, but not at the cost of flexibility to respond to opportunities.

How Jeff Bezos Makes the Right Decision 30 Years In Advance (Quartz): An article on how having a long horizon actually “stops you from making short-sighted choices, and more importantly, it gives you more control over the unpredictability of randomness.”

If Strategy Is So Important Why Don’t We Make Time For It (HBR): An article with some introspection on an important topic.

Why Strategy Execution Unravels—and What to Do About It (HBR): A video that articulates the five myths of strategy. Business architecture can help with every single one.

94 Mind-Blowing Strategy Execution Stats (Boardview): One of our favorite compilations that illuminate the challenges that organizations have with strategy execution. There’s great information here to help you build a case for business architecture within your organization.

The Strategy Execution Metanoia (S2E): A white paper which explores a new vision for strategy execution and describes business architecture’s role throughout.

Your Strategy Needs a Strategy (TED Talk): A TED Talk by strategy expert Martin Reeves on shifting from “classic strategy” to applying the right approach to the right situation.