The FABAQ Redux, Part 2 – FAQs on Business Architecture Knowledgebase Plus Alignment

Summary
Frequently Asked Business Architecture Questions (FABAQ) are all about providing answers to the burning questions about business architecture. This installment focuses on questions related the business architecture knowledgebase and alignment with other disciplines.

This installment of StraightTalk is Part 2 in our series to explore additional Frequently Asked Business Architecture Questions (FABAQ). We will focus on the burning questions around the business architecture knowledgebase and alignment with other disciplines.

Why FABAQs? First, to help you understand. That is what StraightTalk is all about. But second, to help you help others by arming you with some straightforward answers to these questions – making you an even better leader, practitioner and advocate for the discipline. It’s sort of like having your own personal guide through the world of business architecture.

P.S. Make sure to check out Part 1 of our FABAQ series in Post No. 77 as well as the full set of FABAQs in their complete format. In some cases, the answers have abbreviated a bit here for the StraightTalk format. And, the full set provides valuable business architecture references that offer immersive information along with diagrams you can use.

Here we go again! Note: we’ve picked up the FABAQ numbering where we left off.

31. What is the minimum amount of business architecture needed and how can its creation be accelerated?

An organization’s minimum business architecture baseline requires three things:

  • A capability map (one that encompasses the whole scope of the organization and its ecosystem, and is based on defined business information concepts)
  • Value streams (a core set of value streams, typically those externally-triggered by customers and partners, created at the ecosystem level without business unit or product specificity)
  • Capabilities cross-mapped to value stream stages

Once this baseline is in place, additional detail and content can be added just enough, just in time as it is needed by the organization.

 With value streams and capabilities at the core, business architecture is the framework that represents an organization which is:

  • A high-level enterprise view that crosses all business units and products, allowing us to see the forest for the trees
  • A pure business view, completely independent from technology
  • An agreed upon view, created by a respected group of cross-functional business experts
  • An objective view without any organizational bias or otherwise
  • An accessible view to everyone in the organization (provided it has been published)

Check out the handy diagram below which recaps the key aspects of an organization's baseline business architecture.

Progressive chevrons showing business architecture baseline and expanded activities

Building and Expanding the Business Architecture Baseline

Downloadable Media

The availability of standard, principle-based business architecture reference models from the Business Architecture Guild® have greatly accelerated the time it takes organizations to create their baseline business architecture. Other accelerators include having business architecture mapping knowledge (by the internal team or an external expert advisor) and an automated tool in which to capture the information. With knowledge, sponsorship, and dedication, a baseline business architecture for an entire organization can be created within one to three months. 

More on FABAQ #31.

32. Does business architecture just represent an organization’s internal environment or does it go beyond?

A business architecture provides a holistic, simple and shared representation of an organization and its ecosystem. As a result, it not only represents an organization internally, but also includes external perspectives. For example,   

  • The capability map includes capabilities which may be outsourced to partners
  • Value streams span activities performed by internal and external stakeholders 
  • Business units reflect internal business units as well as partners (through external business units)
  • Stakeholders include both internal and external stakeholders such as customers and partners
  • Products include those offered by the organization as well as any sourced from partners 

This extended representation of an organization supports effective cross-organization collaboration, design and decision-making.

In addition, in order to compete and operate effectively, an organization must have clarity on who their customers are and what products they offer – and this must be consistently understood by every person so they know who they are serving and how they fit within the bigger picture. An organization’s business architecture is front and center to providing this clarity. Customers and products in an organization’s business model and business architecture must always reflect the external perspective – not a concept of “internal” customers or products. 

In the business architecture, a customer is never an internal definition (e.g., sometimes the IT department considers business partners to be “customers”). It doesn’t mean that we can’t think of delivering value to each other internally, but clarity of terms in business architecture is essential and if customer and product include all internal and external definitions of the words, we lose our entire common language and useful rationalized perspective.

More on FABAQ #32.

33. How can a capability map and value streams be made more relatable for others?

The content and structure of capability maps and value streams (and other domains for that matter) as defined by the principles in the BIZBOK® Guide are architecturally sound and powerful for many reasons. For example, business object-based capabilities make a common business vocabulary and mental model possible not only across an organization, but across an entire ecosystem. They also enable unique and fresh views of an organization, such as to highlight opportunities for collaboration and reuse.

However, sometimes these views do not always resonate with people within the organization who are used to more functional or process-oriented views. Here are a few ideas for making capability maps and value streams more relatable for others:

  • Explain the why – Help others understand the purpose and benefits in how capabilities and value streams are structured.
  • Make it visual and provide context – Create engaging visuals and add relevant context. For example, bring the underlying business objects and definitions within capability maps to life with icons and create overlays with examples for specific business units, product areas, etc. For value streams, overlay a relevant scenario through it.    
  • Show it in action – Most importantly, show the capabilities and value streams in use to represent analysis and insights or frame opportunities or challenges. This will truly highlight the value in ways that just looking at the models themselves cannot.  

More on FABAQ #33.

34. How does business architecture relate to other teams?

To be successful, business architecture cannot work as an isolated function. It must contribute within a bigger ecosystem and must always remain cognizant of its role as an enabler of other teams. It takes focused time and effort to build these partnerships.

For example, effective strategy execution requires an ecosystem of teams working together in harmony to move strategies and other business direction into action. Business architecture plays its own important (and often missing) role but is also instrumental as a dot connector and enabler of other teams as well. 

Here are a couple key ways in which other teams interact with business architecture and business architects:

  • Business direction and operations-related teams (e.g., strategy, risk management) – These teams leverage the business architecture framework and expertise of business architects to inform business direction and decisions as well as translate them into concrete changes which need to be made to the business and IT environment.
  • Change delivery-related teams (e.g. experience design, IT architecture, business process) – These teams exchange various inputs and outputs with the business architecture team and work closely together to define, design, plan, execute and measure the success of business direction. 

More on FABAQ #34.

35. How do business architecture and enterprise architecture relate?

Enterprise architecture is an umbrella for a collection of architecture disciplines that work closely together. Enterprise architecture is comprised of business architecture, application architecture, data architecture and technical architecture, where the latter three comprise IT architecture. Solution architecture leverages a subset of all four architecture disciplines within the context of a specific solution, initiative or other defined scope.

*Enterprise Architecture = Business Architecture + IT Architecture (where IT Architecture = Application Architecture + Data Architecture + Technical Architecture)

Business and IT architecture should be closely aligned in terms of:

  • Architecture: An organization's business architecture should be connected to its IT architecture in the architecture knowledgebase. (See FABAQ #36.) 
  • Roles: Business and IT architects should work closely together for translating strategy and other business direction, architecting change, and supporting decision-making. 
  • Practice: The overall value proposition, priorities, methods, tools, and other key aspects of the business and IT architecture practices should be shared or aligned.

More on FABAQ #35.

36. How do business architecture and IT architecture align?

Here are the key relationships (cross-mappings) between an organization's business architecture and IT architecture:

  • Capabilities cross-map to applications (business units may be used to clarify the cross-mapping where different applications are used for the same capability across business units) 

  • Capabilities cross-map to software services

  • Value streams frame service orchestration (e.g., to define when capabilities and related software services are used) and workflow automation 

  • Business information concepts inform data architecture (relationships to entities in the data architecture may or may not be cross-mapped in the knowledgebase)

Business architecture can be leveraged in a variety of IT architecture and technology usage scenarios such as :

  • Business and IT strategy and architecture alignment

  • Application portfolio rationalization, management and modernization

  • Business-based IT metrics

  • Cloud strategy and migration

  • Leveraging emerging technologies

More on FABAQ #36.

37. Does IT have its own business architecture?

No. There is one business architecture for an organization and from a business architecture perspective, the IT department is a business unit just like any other. It triggers and participates in value streams, performs capabilities, and so forth. For example, an IT department performs capabilities related to managing IT strategy, plans, policies, research, agreements, vendors, team members, physical and technology assets, budgets, payments, programs, and others.  All of these capabilities would already be captured within an organization’s capability map. The same is true for value streams, where IT stakeholders could trigger or participate in value streams such as Acquire Asset, Deploy Asset, Deliver Program, Onboard Human Resource, Develop Human Resource Career, Disseminate Information, Conduct Audit, Ensure Compliance, Settle Account, and others.

The IT department has the same purpose as all other business units – to serve the organization's customers and achieve its vision, mission, strategy, goals, objectives. Having a separate "business architecture for IT" entirely fragments the view of the organization and contributes to dynamics of "us versus them," and losing sight of the customer and purpose for which the organization ultimately exists.   

Of course the IT department as a business unit (or sub-business units) could be cross-mapped to specific capabilities within the business architecture knowledgebase to make the relationship explicit – and then IT-specific capability views could be created.

More on FABAQ #37.

38. Is customer experience design part of business architecture?

Customer experience design* and business architecture are separate disciplines, each with different purposes, roles, and outputs. However, they both greatly benefit from close collaboration with each other in order to design, improve and implement the experience that an organization delivers to its customers*. Customer experience designers and business architects receive mutual benefit from working with each other, though some organizations combine these two roles in practice.

A customer experience design team benefits business architects by:

  • Articulating a comprehensive vision of the organization’s target customers and end-to-end customer experience
  • Providing clear direction and priorities related to customer needs
  • Serving as a focal point for decision-making and governance for customer-facing capabilities and value streams
  • Identifying gaps or areas for improvement in the business architecture related to current or future customer needs

On the other hand, a business architecture team benefits customer experience designers by:

  • Informing customer experience design plans based on what is currently in place or planned for, per the business architecture
  • Providing an enterprise-level framework describing what the organization does at a high level, which can be used as foundation for identifying and planning customer automation and digitalization
  • Translating customer needs into logically structured initiatives that will deliver them, harmonized with related changes across the enterprise
  • Facilitating bi-directional analysis to assess impacts of customer experience changes to the business, or changes of the business to customer experience
  • Accelerating and improving customer experience issue analysis and resolution    
  • Establishing a common business vocabulary, applicable across all business units

* Note: Within the fullest extent, experience design can be leveraged for customers, partners and human resources

More on FABAQ #38.

39. How do business architecture and design thinking relate?

Design thinking is a methodology for creative problem solving. It applies human-centered techniques to solve problems in a creative and innovative way. Design thinking is used by businesses, governments, non-profit organizations, and within other contexts. There are five phases of Design Thinking, which include empathizing with users, defining their needs and problems as well as your insights, ideating, prototyping and testing solutions.1

Considering that Design Thinking is essentially an approach for creative problem solving, this means that an organization could leverage the technique at any time, within any context. While Design Thinking and business architecture may have different intents and approaches, they co-exist and interact for mutual benefit. For example, from a strategy execution context, Design Thinking could be particularly valuable in the Architect Changes and Execute Solutions steps to inform target state architecture and solution design. Design Thinking could also be leveraged upfront during the Develop Strategy step.

More on FABAQ #39.

40. How can business architecture help innovation? Won't it inhibit innovation?

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.

For example, business architecture can:

  • Help target focal points that need innovation and are most relevant to the business
  • Identify new usage scenarios for innovation ideas
  • Weave innovation into the fabric of the organization which not only spreads ideas but also gives even more credence to the discipline
  • Assess the viability and potential impact of innovation ideas to the organization
  • Make innovation ideas real by translating them into a coordinated, actionable set of initiatives across business units
  • Clarify how innovation ideas fit with the bigger picture activities and priorities

More on FABAQ #40.

More Good Stuff...

You’ll notice that this section is a little light during our FABAQ series – because you have loads of related resources available to you on Biz Arch Mastery.

Biz Arch MasteryYour place to master the art and science of business architecture for robust organizations, ecosystems, and a better world. Rich content, tools and accelerators to help you learn and successfully practice and leverage business architecture. Check out the full set of FABAQ content.

The Business Architecture Quick Guide (Business Architecture Guild®): Available on Amazon and Barnes and Noble.

The BIZBOK® Guide (Business Architecture Guild®): Of course. (Guild membership required.)

A Visual History of Human Knowledge (TED Talk): Speaking of knowledgebases and knowledge, check out this fascinating TED Talk by infographics expert Manuel Lima on how human knowledge grows. He explores the thousand-year history of mapping data – from languages to dynasties – revealing humanity’s urge to map what we know. So cool!

  • 1. Stanford University d.school: https://dschool.stanford.edu/resources