In this installment of StraightTalk, we will explore an often overlooked bestie of business architecture: innovation. These two disciplines can and should team up to enable an organization to fully benefit from its innovation activities.

Doesn’t business architecture get in the way of innovation and slow it down?

No. The idea that business architecture and its structure limits or slows down innovation in any way is a misconception.

When leveraged correctly, business architecture actually makes innovation more expansive, impactful and effective.

Explain.

For example, business architecture can help to target all of the areas which need innovation and identify new applications for innovation ideas. It allows us to make sure that we’re innovating on the right things that are most relevant to the business. Business architecture can help weave innovation into the fabric of the organization, which not only spreads ideas but also gives even more credence to the discipline.

As with any idea or defined business direction, business architecture also plays an important role to assess viability and impact of innovation ideas, and then makes them real by translating them into a coordinated, actionable set of initiatives across business units.

Business architecture is always looking out for the enterprise though, so it does play a role in helping the business to understand how any innovation ideas fit with the bigger picture activities and priorities. This way an organization can pursue innovation ideas when they truly make sense, regardless of how exciting and cool they are.

How specifically does business architecture help with innovation then?

Business architecture plays a role throughout the entire innovation life cycle. Here’s a brief overview of how:

• Stage 1: Idea Generation and Mobilization – First, as a result of their efforts and perspectives, business architects can generate new innovation ideas. In addition, the business architecture framework (especially value streams and/or capabilities) can be leveraged to facilitate the sharing of innovation ideas across the enterprise. Think about all of the great ideas that are generated through innovation challenges and efforts. If they are tied to the reusable business architecture, they can easily be found and used. Business architecture can also help to identify focus areas where innovation is needed, either resulting from business priorities or known areas of improvement. It even can help to provide specificity and clarity on the problem to be solved or an opportunity to be pursued.
• Stage 2: Advocacy and Screening – Business architecture can be used to assess initial viability and impact of innovation ideas, narrowing the focus on only those which are worthy of our precious resources and mindshare. It can also be used to identify additional applications for innovation ideas. For example, using the business architecture, a business architect can readily identify other business units, products and/or scenarios which might have use for the same innovation idea in other contexts. This could even help to increase the support and funding for an innovation idea.
• Stage 3: Experimentation – Based on an understanding of overall business priorities as well as applicable scenarios (as mentioned above), business architecture can inform priorities, timing, and scenarios for innovation idea experimentation.
• Stage 4: Commercialization – Once an innovation idea is ready for commercialization, then it hits the sweet spot of how business architecture translates ideas into concrete, enterprise actions to make them real. (See Post No. 3 for more on business architecture’s role in strategy translation and execution.) Business architecture can be used to assess the final impacts on the business and technology environment. In addition, it can provide a structure for and inform the cost-benefit analysis.
• Stage 5: Diffusion and Implementation – Here the business and IT architects will architect the business and technology changes needed to create and maintain the innovation idea. From there they will define and scope initiatives required to implement the idea and ensure that the implementation of the innovation idea achieves the defined business objectives.

See the handy diagram below for a recap of all that.

What about design thinking – how does it fit with business architecture?

Design thinking is a mindset and approach that can be applied at various points across the strategy execution life cycle.

According to “Design Thinking, Explained” from MIT (see More Good Stuff), “Design thinking is an innovative problem-solving process rooted in a set of skills.” The design thinking process can be applied when developing new products and services and applied to a whole range of problems. According to the same article, the stages of design thinking include, “Understand the Problem, Develop Possible Solutions, Prototype, Test and Refine, and Implement.”¹

Business architecture can leverage design thinking in various ways, such as for target business architecture design. It can also help the design thinking process in each stage in similar ways as described above for innovation (e.g. defining the problem, assessing viability or impact of solutions, framing initiatives for implementation, etc.).

How do we get started?

No silver bullets, just the same approach we use to build bridges with any other related team or discipline. Start by having a conversation with the innovation team(s) to share how you think business architecture can provide value, and discuss how you will interact and collaborate. Start using the business architecture in some of the ways we’ve discussed here. Refine and expand. Over time, your relationship will progress to a partnership and then ideally integration of business architecture across the innovation life cycle, to the benefit of both disciplines and the organization overall. (More on how to integrate business architecture with other teams in Post No. 5.)

Make a new friend today.

More Good Stuff

The Innovator’s Dilemma (Clayton M. Christensen): An absolute classic book on innovation, and for good reason.

Ten Ways Businesses Can Kill Innovation (Nick Heath, ZDNet): Inverted thinking: what not to do if you want to succeed at innovation.

The Five Stages of Successful Innovation (MIT): The five essential stages of successful innovation.

The Innovator’s DNA (Harvard Business Review): Five “discovery skills” separate true innovators from the rest of us.

Design Thinking, Explained (MIT): Solid straight talk here on what design thinking actually means, beyond the buzzword.

8 Ways To Fuel Innovation (TED Playlist): A compilation of thought-provoking TED Talks to inspire your thinking.

---

¹ Linke, Rebecca. “Design Thinking, Explained,” MIT Sloan School of Management, 14 Sept. 2017, mitsloan.mit.edu/ideas-made-to-matter/design-thinking-explained.

In this installment of StraightTalk, we are further exploring a big, scary and loaded concept of business architecture governance. In Post No. 38, we took a practical look at what we should govern. In this post, we will look at how to implement the governance concepts we discussed previously. Here goes again.

P.S. Post No. 38 is a prerequisite for this post to make sense, so you may want to read or brush up on that one first.

How do we approach business architecture governance?

Keeping in mind that introducing business architecture to an organization is really part of a bigger change (e.g. a new vision for strategy execution and working together as an enterprise) and also the lessons we can learn from other architecture governance implementations, we need to approach business architecture governance practically. Here are some key guidelines:

• Introduce business architecture governance just in time – Step into the various aspects of governance as you reach key business architecture milestones, and it becomes relevant (see diagram later on in this post). What does not work well is establishing governance because it’s a step in a methodology or because it seems that other organizations are doing it.

• Govern what is essential – Focus your precious time on what is most important. For example, focus on governing target architectures and strategic roadmaps versus every detailed deliverable. Or, focus your business architecture service delivery governance on outcomes, not whether each step was exactly followed as prescribed.

• Keep governance processes light and potentially informal until the organization matures – Increase the rigor of your governance with your business architecture maturity. Especially in the beginning, lighter governance will encourage more people to participate as well as allow for learning and evolution.

So, where do we start to implement business architecture governance?

As an organization’s business architecture practice matures, there is a logical progression of when to implement each aspect of business architecture governance, depending on when the actual thing being governed is put into place. Of course, the journey to maturity is not the same for every organization, but there is a commonality of how they progress through business architecture milestones. (P.S. Check out Post No. 4 on the business architecture practice maturity journey.)

As a result, here is an approach to introducing the various aspects of business architecture governance over time, simply stated:

• Introduce knowledgebase governance to manage changes to the business architecture baseline (a.k.a. capabilities, value streams and the cross-mapping between the two, as described in Post No. 22) just as soon as you have published your first version 1.0.

• Introduce practice direction governance after you have formalized your practice and defined your charter (with purpose, value proposition and measures of success) and have begun applying business architecture in enough instances where you can assess the outcomes.

• Introduce business architecture service delivery governance after you have formalized the services you will deliver and your methodology for delivering them and have begun delivering these business architecture services in enough instances where you can assess the outcomes.

• Introduce business architecture tool governance after you have implemented an automated business architecture knowledgebase tool(s) and defined how it should be used within your methodology and enough practitioners have begun using it.

• Introduce target business architecture governance the first time you use business architecture to drive your first large change initiative, such as an enterprise-wide transformation.

• Introduce business architecture as an enabler into other governance processes at various points across the strategy execution life cycle (e.g. to compare initiative results delivered to original business objectives, using business architecture traceability) as the discipline becomes embedded over time.

This is illustrated in the handy diagram below.

Who does all of this business architecture governance?

This varies based on an organization’s situation and dynamics, so simply stated:

• Any architectural reviews related to content are performed by people on the business architecture team (which could be anything ranging from the top architect to an architecture board).

• Any business reviews related to content are performed by the business people, and typically at multiple levels within the organization, though the final approval usually comes from an executive (which could be anything ranging from an individual executive to a committee).

• Any practice reviews are performed by people on the business architecture team, though they may also involve others outside of the team (which could include a steering or advisory committee comprised of others with business or technology perspectives).

What about capability ownership? Aren’t we supposed to have that?

Depending on how you interpret capability ownership, this is typically referring to the business involvement in business architecture knowledgebase governance and/or target business architecture governance. (See diagram below for context. You can download the complete diagram from Post No. 38).

As mentioned earlier, resist the urge to implement this type of governance too soon, especially before the business architecture and its usage are fully understood. Otherwise, you could run the risk of reinforcing your current silos (or creating new ones) and implementing governance for the sake of governance.

Here are a few key considerations when implementing capability ownership:

• Implement capability ownership only after your capability map is reliable – and that means you’ve not only created it but have been using it for a while to test it

• Have a clear purpose for what you want to achieve with capability ownership

• Consider that ownership might be more relevant to a set of capabilities (e.g. all customer-facing capabilities) versus splitting ownership by level 1 capabilities*

• Consider that ownership might involve more than one person (e.g. a committee of business leaders that govern the customer-facing capabilities)*

• Consider the value stream perspective – this does not imply that you must have value stream owners as well, but the perspective should always be considered when making capability-related decisions

* For these reasons, capability ownership is typically best approached as target business architecture governance, introduced when the organization is at a higher level of maturity.

What are the elements to consider for each aspect of business architecture governance?

For each aspect of business architecture governance, consider the following:

1. Structure

• Who makes decisions?

• What organizational structures will be defined (e.g. governance committees, roles)?

2. Process

• What are the processes for review and approval?

• When will the processes occur?

• What is the scope of review?

• What review criteria will be used?

3. Measurement

• How will the results be measured? (Throwback to Post No. 21 where we discussed different measures of business architecture value and maturity. The results of your governance process can become some metrics that you may choose to track over time.)

4. Communication

• To whom will the results be created and for what purpose?

• How will the results be communicated?

Closing Thoughts: Remember that 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

Tying Business Architecture to Business Strategy (State Farm at Business Architecture Guild^® Summit): Learn from your friends. Here is an example of using business architecture through strategy execution to shift to an aspirational state (including the use of target architectures and strategic roadmaps which would be governed).

A Powerful Pledge That Spreads Accountability in the Workplace (TED Talk): A TED Talk by Garry Ridge, CEO of the WD-40 Company, who shares their pledge for personal accountability and the remarkable impact it has had on their bottom-line.