S2E Consulting Delivers Keynotes and Panels During MozTech

Whynde Kuehn, S2E Founder, delivered two keynote addresses and participated in panel discussions at the fourth edition of MozTech in Maputo, Mozambique. Held 24-26 May 2017, the two-day summit centered on digital business and society. MozTech is Mozambique’s largest information technology fair; its purpose is to inform and foster the country’s development and transformation by putting technology at the service of its people. Over the past two years, MozTech has attracted 20K+ visitors and featured over 100 speakers and exhibitors.

“I am honored to contribute among esteemed colleagues from Mozambique, South Africa, Portugal, Brazil and Sweden by helping to broaden the national technology dialogue that will help pave Mozambique’s growth and development.” — Whynde Kuehn.

Based on her extensive experience as an architect of large-scale digital business transformations, Kuehn set the overall context for what digital technology means to organizations, society, and to the development in Mozambique and other emerging nations. On the topic of digital trends, Kuehn spoke on key digital trends including those related to business growth and digitalization, the future of work and the evolution of human consciousness. These trends affect everything from how business models are designed, to the jobs of the future, to the evolution of business to combine profit and purpose. Together these trends are shaping the world we live in both today and in the future. Other topics included digital marketing, to which Kuehn delivered ideas on key shifts in digital marketing, including those related to the role of the customer, the importance of seamless and meaningful customer experiences, and the power of data.

Additional information and local press coverage on the MozTech event:

Moztech official website
O País (newspaper) — “Who Understands the Customer Has Success in Digital Marketing”
O País (newspaper) —“The Customer is the Main Digital Marketing Agent”
Notícias (newspaper) —“The Customer is the Main Digital Marketing Agent”
O País | Digital Trends —“Digital Business and Societies: Creating a World In Which We Want To Live” (PDF 2.1 MB)

Let’s Get This Party Started

Knowing what business architecture is: Check.
Knowing why we do it: Check.
Knowing where it fits within the strategy execution life cycle: Double Check. Knowing where to start: Not so much.

So where do we start then?

Starting business architecture within an organization can be a fairly organic process, but there are a proven set of steps to follow. The first one is to build a really solid understanding of what business architecture actually is, including its scope, how it integrates with other things, and the value it can provide. (Thank goodness for StraightTalk.) This is important. Do not pass Go. Do not collect $200 without it or you can get a bit off track and have to course correct later.

The second step is to define business architecture’s value for your organization and establish a team (which could be a team of one to start). Start formalizing it. Approach this as if you were working in a start-up, even if you are not. You’re essentially establishing a new thing here, so Step 2 is a pretty official commitment. As a result, people often have to do some work to demonstrate business architecture in action first before they can get the buy-in from leadership to actually establish a team. It takes some organizations awhile to even get to Step 2. If this is your situation, not to worry. It’s normal.

Got that part. What next after we have the team established?

After Step 2, your business architecture journey begins in earnest. Since most business architecture teams start with just a few people and have a need to continually demonstrate their value, they can’t just hang out for a year or two documenting their business architecture knowledgebase. With that reality in mind, here is a pragmatic approach to make this work in the real world. Secrets from a business architecture Sherpa who has been up this mountain many times.

First, keep in mind that there are always three components necessary to establish business architecture within an organization and they are:

Building your business architecture knowledgebase
Applying business architecture to various scenarios
Creating your business architecture practice infrastructure

Second, never lose sight of the fact that the most important activity a business architecture team performs is to apply business architecture for value. This is our guiding light. Honestly, building the knowledgebase and creating the supporting practice infrastructure are performed in support of this and both should be approached in a “just enough” and “just in time” manner to support the relevant business architecture application scenarios currently in focus.

So can we apply business architecture without having a knowledgebase in place?

Nope. There’s a critical and minimum baseline of business architecture that you need in your knowledgebase before you can actually be taking an enterprise business architecture approach. You might be doing fantastic work, but it just may not be architecturally based.

Hmmm. What is the minimum business architecture baseline then?

For most organizations, the minimum baseline includes an enterprise capability map, a set of enterprise value streams and a cross-mapping between the capabilities and value streams. Emphasis on the word enterprise. If these things are defined from a business unit, product or other siloed perspective, then we lose the power and intention of business architecture. There are lots of shortcuts, but this is not one of them.

To clarify further, some organizations will document the full scope of their capability map at the highest level of detail (called “level 1”) and only break down some of those capabilities into more detail (like down to “level 2” and “level 3”) to start. Also, some organizations will only document a few of their known value streams upfront instead of doing all of them. In most cases, they will focus on the capabilities and value streams that are customer-facing, but that’s up to you.

Talk more about what you mean by business architecture “practice.”

The concept of a “practice” is simply a way to refer to the intentional collection of activities performed to achieve the defined mission for business architecture within an organization. This is what that Track 2 is all about in the picture above.

Your business architecture “practice” includes all of the things you do to mature, measure and sustain the business architecture, the business architecture practitioners and the practice itself. Want a checklist? Here you go.

Business Architecture Stuff — Business architecture maps in your knowledgebase; architecture processes, methods and practices; governance; tools
Business Architecture Practitioner Stuff— Structure and roles; education and mentoring; resources and staffing; community and support
Business Architecture Practice Stuff— Practice planning; measurement; change management and adoption; organizational alignment and integration

The key is to be intentional about formalizing all of these things.

Do we have to?

Yep. As soon as you hit Step 2 on that roadmap, you need to start formalizing. There is even a “maturity model” that helps you to measure how well you’re doing these things. Many organizations do not invest in their practice and many don’t know that they need to. But as soon as business architecture’s footprint starts to expand, there will inevitably be an increasing need to tell the story of what you do and have some structure in place. Bottom line: a solid practice will help you scale to meet the demand for business architecture across your organization and the act of formalizing makes it real and gives it credibility. And business architecture requires lots of evangelizing and relationship building, just like a start-up does.

The only exception here is that if you work in an actual start-up organization, then you’ll likely keep your business architecture rigor light weight in the beginning and increase it as the organization grows.

Got it. But now I’m a little overwhelmed.

Remember that this is a journey, and journeys are taken one step at a time. Whether you are just about to embark on your business architecture journey or if you are already on your way up the mountain, know that it will be worth your effort, both personally and to your organization. You have an important destination. You’re in great company. And as mountaineer Alison Levine reminds us, sometimes you have to go backward to go forward. You do not need to have total clarity to put one foot in front of the other. And from a personal standpoint, the summit isn’t as important as the journey, and the lessons you learn along the way will make you better and stronger on the next mountain.

More good stuff.

The Business Architecture Practice (S2E Whitepaper): A longer version of this story to help guide you through your journey of establishing and maturing a business architecture practice.
Roadmap to Establish a Business Architecture Practice (S2E Tool): Nifty graphic #1. Here’s a downloadable version of that cool roadmap graphic contained here in post No. 4.
Business Architecture Practice Components (S2E Tool): Nifty graphic #2. Here’s a downloadable graphic showing you all of those key components you need to consider for your business architecture practice. It’s basically that checklist in a prettier picture.
Lessons From The Ledge (TED Talk): TED Talk by Alison Levine, team captain of the first American Women’s Everest Expedition. This is big time inspiration and wisdom, even if the mountain you’re climbing is called “starting a business architecture practice” or just that great one we call “life.”

The Strategy Execution Metanoia

“Houston, we have a problem.”

“Uh, this is Houston. Uh, say again please.”

We have a strategy execution problem.

Remember that whole deal in Post No. 2 about how constant change is the new normal as customer expectations increase and the external environment evolves at an escalating pace? That means the ability for organizations to get their ideas—things like strategies, transformations, innovations and regulatory changes—into action has never been more important than it is right now. And this includes non-profit and government organizations too which care deeply about carrying out things like missions and policies.

Except one thing. Many organizations, especially large ones, are not so good at it when you look at the overall results. Here are 4 statistics out of a list of 94 that will scare you.

95% of employees in most organizations do not understand their organization’s strategy.

66% of HR and IT organizations develop strategic plans that are not linked to the enterprise strategy.

2% of leaders are confident that they will achieve 80-100% of their strategy’s objectives.

61% of respondents acknowledge that their firms often struggle to bridge the gap between strategy formulation and its day-to-day implementation.

Source: Five of 94 statistics from “94 Mind Blowing Strategy Execution Stats,” Hasse Jansen, October 5, 2016, boardview.io/blog/strategy-execution-stats.

How can this be?

Well, there are many factors that contribute, but the big picture issues are the true source of the challenges.

It’s hard to bridge strategy and execution. There is often a giant leap between high level business direction and translating what it means to changes necessary in the business and IT environment.
We define and execute strategy in silos. Direction is translated and planned in silos by business unit, product or other organizational constructs. This leads to redundant, conflicting and non-integrated business and IT solutions—which leads to poor customer experiences and inefficient, expensive operations.
We approach strategy execution in a fragmented way. Multiple instances of the strategy execution life cycle may occur in different silos. Teams across the strategy execution life cycle are not always integrated well. Rarely is there end-to-end visibility or ownership.

What does that word “metanoia” have to do with anything?

As Peter Senge describes in his book, The Fifth Discipline, a metanoia is “a fundamental movement or shift in mind,” which requires “deep shifts in our orientation.” He underscores the importance of systems thinking and seeing in wholes instead of parts.

Perhaps an organizational “metanoia” is just what we need right now to transition from valuing, thinking and acting in silos to doing so from an enterprise perspective.

Okay, tell me more about this vision?

In a Six-Word Memoir: Business-driven, top-down, enterprise-focused.

The potential for strategy execution is not only to produce better results, but to provide competitive advantage because it seriously improves an organization’s ability to adapt and realize business direction.

What if strategy execution were approached from an enterprise perspective instead of in silos? What if business direction was collectively architected, prioritized and planned from a business-driven and top-down approach instead of bottom-up? What if strategy execution itself was made a priority, with deliberate design, transparency and ownership from end-to-end?

I thought this blog was about business architecture. How does it relate?

Turns out that strategy execution and business architecture are long lost best friends. Business architecture (along with IT architecture) is the bridge between strategy and execution that has been missing for so long.

Here’s strategy execution + business architecture explained in pictures. (Very important: note that business architecture is positioned before planning and execution.)

With business architecture (and business architects) we can:

Inform, assess and rationalize business direction
Methodically and comprehensively assess the changes needed to the business and IT environment
Collectively architect those changes across silos and give the organization a common vision of the future to work towards
Collectively scope initiatives in the most effective way across silos and help to compare investment within and across portfolios
Provide traceability across the strategy execution life cycle and determine if the initiative results met the original objectives

So are you saying that business architecture is really about a mindset change?

Business architecture is still just a “blueprint” of an organization. But because of its enterprise nature, peoples’ mindsets do start shifting as you build it and use it. It encourages thinking and acting in wholes, not parts. Not every organization will fully leverage business architecture as described here, but most do or aspire to.

Doesn’t it take a lot to achieve this vision?

Yes, facilitating the organizational “metanoia” required to make this vision real requires organizational commitment from top to bottom and potentially a lot of changes to be made over time. And business architecture isn’t the only star in this strategy execution show (but it would be a nominee for best actor/actress). Making this shift may also require changes to values, culture, structure, roles, responsibilities, motivation mechanisms, decision-making, governance, processes and tools.

Achieving an enterprise-driven approach to strategy execution is a journey for most organizations, and not necessarily an easy one, but as with any journey it is taken one step at a time. And it’s possible. It’s been done. It’s what is needed. What we’re doing now is no longer working, so if we want to achieve new results, we need a new mindset.

Can any organization afford not to make the shift?

“No organization can win if its parts are not all aligned to execute the same strategy and achieve the same goals. Even the ‘perfect’ strategy within a competitively advantaged business model will ultimately fail if the organization is not fully aligned internally and does not understand how to execute the strategy, or if it works at cross-purposes.” — Rick Kash and David Calhoun in How Companies Win (2010)

For further reading —

The Strategy Execution Metanoia (S2E White Paper): The LongTalk version of this story on a new vision for strategy execution and how business architecture helps.