The Business Architect Imperative: Showing Up With Wow

Business architecture and the business architect role continue to expand and mature across the globe. There has also been a shift in the way we practice the discipline. Collectively, we are increasingly business-focused, value-oriented and strategically-minded. That means putting the business in business architecture first and remembering that things — like building the architecture knowledgebase and performing governance — are enablers. In other words, business architecture is a means to the end, not an end in itself. But we still have work to do.

As a newer role on the scene, working in a business world ubiquitous with design, digital, agile and other emerging concepts, the way we show up as business architects matters a lot. Because everything we do and say demonstrates to others what business architecture really is, and we need to be relevant and distinguish ourselves. The success of a business architect then is not just in what we know or what we do — but in our Ways of Working (WOWs).

So, let’s explore some key ideas.

In addition to learning the discipline, building a practice and showing value, I also must consider how I work?

Yes. Sometimes it can feel like we’re building an aircraft while in flight. However, showing up in a relevant way that engages others can make all the difference and helps to support and make successful all the effort you are investing. And, it just starts with being deliberate about your mindset, which you can work into over time, and investing where you and your team have growth opportunities.

P.S. More on how to establish a practice (a.k.a building while in flight) in StraightTalk Post No. 4.

Why does this matter?

Simply said, because when we are engaging, relevant and effective in the way that we work, we can get to the right people and at the right tables where we can deliver the value proposition for which business architecture is intended. And we can be invited to participate.

Here are some reasons why this is so important:

  • Architecture is already an abstract concept that can seem academic to some people. As a result, we have to overcompensate a bit to gain attention, make friends, and draw people in to try something new when they are already busy with lots of work and other new concepts.
  • Architecture teams need to adapt to how the world has evolved and the new expectations that come with it. Smart phones, design-thinking, agile approaches, the digital revolution, and more. People are changing the way they work, and other disciplines and their approaches are gaining traction. As a result, architecture approaches need to adapt too, such as to work in more collaborative and visual ways, and to work at different speeds.
  • Effective ways of working are needed to achieve our goals anyway. Ways of working that are engaging to others are the very same ones that help us to effectively do our jobs anyway, such as bringing people together towards a common vision and understanding. Not to mention, they make the job more fun and bring out the best in ourselves!

What has proven to not work very well for enterprise or business architecture teams — especially not for business architecture teams — is the ivory tower (as some call it), if-we-build-the-architecture-repository-they-will-come, waterfall mindset, governance heavy approach. What does work well is serving the business, being a great partner to other teams, and continually delivering value. And yes, the business architecture knowledgebase is critical to delivering on our value proposition, but we always need to remember that it’s an enabler, not the end game. (More on this idea: Speedy Business Architecture, Part 1 — Accelerating Business Architecture Development With Reference Models.)

What are some effective Ways of Working to consider?

Here are a few WOWs as food for thought.

Successful business architects are…

  • Value-Driven. What drives us is business value, outcomes and results for the customer (or constituent, patient or your equivalent) and for the business. The architecture, models, deliverables, governance and other aspects of the practice are a means to the end. (More on value: StraightTalk Posts No. 2 and No. 3, and No. 55).
  • Business Minded. We’re about the business in business architecture. We bring conversations, opportunities, challenges and solutions back to the bigger picture business context. We solve problems and are trusted advisors.
  • Enterprise Advocates. We are champions for the enterprise. We are relentless in our quest for effective strategy execution and cross-business unit collaboration. We care about enterprise direction, decision-making, resources and common language. (Here’s an example: StraightTalk Post No. 64).
  • Bridge Builders. We know that we work in an ecosystem of teams to translate strategy into action and run the organization successfully. While we have our own unique role, we know that our success depends on close partnerships and by making others successful, we all succeed. (More on how we work with other teams in Post No. 5 and within a strategy execution context, Post No. 50)
  • Visualizers and Storytellers. It is our talent and passion to simplify and visualize complex concepts and show connections. We understand and leverage the power of visual techniques to bring people together and incite action. We are storytellers and change agents for new ideas. (Check out the whole three-part series on visualization, graphic recording and facilitation, and storytelling.)
  • Interactive Co-Creators. We are hands-on and interactive. We facilitate and co-create outcomes together with our business stakeholders and with our partners. We are fun!
  • Iterative and Adaptive. Once the business architecture baseline is in place, we build just enough business architecture, just in time to support the business scenario we are solving. We deliver results quickly and iteratively and adapt our approaches and outputs to the situation at hand.

Here is a diagram that summarizes all of this:

Using Business Architecture To Build Cognitive Enterprise

Got it. So, where do we go from here?

If you work in a newer business architecture team, you have an opportunity to be deliberate from the very beginning. If you work in an established business architecture team, you may have some shifts to make. Gather your business architecture team and introspect on how you show up now and how you want to show up. Create your own set of business architecture principles or imperatives or WOWs that describe how you act and want to be perceived. Write them down and articulate them such as with a description and some examples that will help you know when you’re meeting them.

But don’t stop there. Stick them up on the wall and look at them every day. Talk about them. Recognize each other when they exemplify them. Hold each other accountable when they don’t. You can even work the ideas into your business architect competency model and training plans. And of course, teach them to new members during onboarding.

This is imperative.

So, there’s your homework, but it’s fun homework. And if we all showed up like this, think about how others would perceive business architecture and the business architect role. A trusted advisor. A valued partner. A career path to aspire to. And most importantly, with effective and relevant ways of working that get us to the right tables, think about how much more impact we could make towards our ultimate goals of creating more successful and competitive organizations with better strategy execution. 

More Good Stuff…

Farnam Street Principles (Farnam Street): While we’re on the topic of principles, check out the Farnam Street Five. Great food for thought.

The Ten Golden Rules of Leadership: Classical Wisdom for Modern Leaders (Farnam Street): More wisdom from Farnam Street to take to heart.

Everyday Leadership (TED Talk): A powerful and humorous TED Talk by Drew Dudley that calls on us to celebrate leadership as the everyday act of improving each other’s lives. Because that’s what this is really all about.

The Enterprise Advocate: How Business Architecture Brings Clarity to Customers and Products

Business architects are advocates. For who? For the enterprise. In the daily busyness of strategizing, transforming, implementing new technologies, adapting to new methods, continuously improving, making sure to stay compliant — and of course delivering for customers — it is easy to get very focused on our initiatives, our products, our business units, our pressures, our corner of the world. So, like a swimmer in open water sighting to ensure that they stay on course and can see the big picture, organizations need to perform the same function. And business architects (actually all enterprise architects) can help us all to see, speak and act enterprise. Business architects are advocates for the enterprise. Business architects are biased for the enterprise. Business architects fight for the enterprise.

Advocate \ˈad-və-kət, -kāt\

Noun — Someone who fights for something or someone, especially someone who fights for the rights of others.

Verb — To speak, write or stand up for something or someone.

YourDictionary. Retrieved from www.yourdictionary.com/Advocate

Having an advocate for the enterprise has never been more important than it is today. Despite all of the wisdom we read in articles and books, and what important disciplines like experience design tell us about focusing outside-in, we still think and behave in a pretty siloed way. Interestingly enough, our digital transforming and agile methods have in some ways focused our energies even more and caused us to lose sight of the bigger picture of the enterprise. One recurring example of this is a new set of confusion and new blurred lines related to something that used to be quite obvious in organizations: Who is a customer? What is a product? 

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, which is what we will now explore throughout this installment of StraightTalk.

So, how can business architecture help bring clarity to customers and products?

By its very nature, a business architecture provides a holistic, simple and shared representation of an organization and its ecosystem. Within this context then, everyone must share the same big picture view that is aligned with the organization’s business model. 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. Keeping the overall business model in mind makes identifying customers and products a bit easier.

There are a few places in particular where customers and products become evident in a business architecture. This includes:

  • An organization’s business model(s) (e.g., think about the building blocks for Value Proposition, Customer Segments and Key Partners)
  • An organization’s capability map and information map upon which it is based (e.g., think Customer, Partner, Human Resource and Product information concepts and capabilities)
  • An organization’s stakeholder map (e.g., think detailed stakeholders related to Customers, Partners and Human Resources)
  • An organization’s product map (e.g., think products and services as well as their relationships to value streams and capabilities)

Why is this important?

While we may not change how we speak with our team members on a daily basis, there are times when we need to speak and think enterprise. For example, consider a scenario where we are evaluating investment across the enterprise. If one department refers to the people in other departments as their “customers” (as in the Customer Management capability) how will we identify that we are really investing in something related to employees here actually the Human Resource Management capability)? And how will we make sure we create shared solutions for the right things? Or, if we refer to a portal as a “product” how do we make sure that we keep our eye on the ball related to the ultimate product we offer to customers and all of its enabling capabilities across people, processes and solutions?

How does an organization know who a customer is in the business architecture?

The BIZBOK® Guide defines a customer as “a legal entity that has, plans to have, or has had an agreement with the organization, or is a recipient or beneficiary of the organization’s products or services.” This definition is quite elegant and it works. It means that a customer can be an individual or organization, a recipient or beneficiary of products or services (even if they were not the direct purchaser), and can be in various states (e.g., potential, current or former). Of course, depending on your industry, you may not call it a customer, but rather a constituent, patient or otherwise, though the concept is still the same.

The most common challenge that organizations have when identifying customers within their business architecture is usually related to differentiating real customers from partners, and sometimes human resources (i.e., employees and contractors). BTW, the same individual or organization can be a customer, partner and even a human resource – you simply reflect that within the different customer, partner and human resource types. So, here are just a few hints to help you define the real customers:

  • Intention: They are included as a customer segment within your business model
  • They are managed like your other customers (e.g., agreement types, information captured)
  • They purchase or benefit from your products (real ones)

Information mapping and stakeholder mapping are highly beneficial techniques that will help you to define, delineate and communicate about customers, partners and human resources.

Give me some examples of customers.

Here are just a few common FAQs related to customers. Customer or not a customer?

  • An individual or organization that purchases and receives a product – Yes, this is a customer within the business architecture.
  • An individual that has not purchased a product and has no agreement with the organization, but otherwise benefits (e.g., a recipient of a shipment or a beneficiary) – Yes, this is a customer within the business architecture. Keep in mind that someone who benefits from a product can still be a customer even if they did not purchase it.
  • An individual or organization that is a degree removed (e.g., employees of employers for insurance or end consumers of distributors for retail) – Whether or not this is a customer or not within the business architecture really depends on your business model.
  • An individual or organization that is critical to your business model (e.g., agents for insurance or teachers for education) – Nope. Commonly confused, but this is NOT a customer within the business architecture. Sometimes the criticality and emphasis that these individuals or organizations receive make them seem like a customer. However, this is a partner and they work as part of your ecosystem to deliver to the ultimate customer.

How does an organization know what a product is in the business architecture?

The BIZBOK® Guide defines a product as “the overall experience provided by the combination of goods and services to satisfy the customer’s needs.” Remember that products and services are the ones which you offer in the market and must always target a customer. BTW, the BIZBOK® Guide considers both products and services within the domain of product. Product goods are tangible (e.g., apparel, vehicles, electronics), while services are intangibles. (As a quick aside, services are delivered via product entitlements which is a concept worth checking out in the BIZBOK® Guide.)

The most common challenge that organizations have when identifying products within their business architecture is usually related to confusion with technology assets and how a product is defined within an agile context. So, here are just a few hints to help you define the real products:

  • Intention: It is included as part of your organization’s business model
  • It is in your organization’s product catalog
  • Your customers pay for it (or benefit from it)

Product mapping is a highly beneficial technique that will help you to define and communicate about products. In addition, cross-mapping products to value streams, capabilities and applications or software services can help to differentiate products in situations where they are often confused.

Give me some examples of products.

A few common FAQs related to products comin’ up. Product or not a product?

  • A good or service purchased by customers – Yes, this is a product within the business architecture.
  • Information you sell to customers – Yes, this is a product within the business architecture – provided that it meets the criteria above (e.g., this is reflected as a value proposition in your business model consumed by a customer segment, this is considered a product within your catalog, etc.).
  • A portal provided to customers – Nope, this is NOT a product within the business architecture. A portal is typically a technology asset that delivers capabilities that enable a product — and but for the existence of the ultimate product — it would not exist. In the business architecture knowledgebase, you would capture the ultimate product offered in the market as your product, cross-map enabling capabilities to it, and cross-map the portal as an application to the capabilities.
  • A technology asset or API made available to partners – Nope, this is NOT a product within the business architecture. Even if a partner pays for access to this asset, they are still considered an entity within an ecosystem using the asset to ultimately deliver value to the customer.

The handy diagram below summarizes these hints and examples for you.


Using Business Architecture To Build Cognitive Enterprise

When people within an organization have a true, shared understanding of customers and products, they will be united and oriented in a way that leads to different decisions and more effective service to the people for which the organization exists. It is the role of a business architect to care for and advocate for the enterprise – and the special mindset and talents that business architects embody make this possible. Even if no one has succinctly articulated such a need, even if no one has picked you, pick yourself. Your organization needs your enterprise perspective now more than ever.

More Good Stuff…

Business Architecture In Action For Product Management — How Business Architecture Enables Better Product Investment, Planning and Solutions (StraightTalk): More StraightTalk on products in the business architecture and how to leverage them.

Business Architecture Stakeholder Mapping and Product Mapping Content (BIZBOK® Guide): Check out Sections 2.7 and 2.8 respectively in the BIZBOK® Guide for great content on these two important topics. (Business Architecture Guild® membership required.)

Stakeholder Mapping (Business Architecture Guild® webinars): A webinar that summarizes stakeholder mapping and its usage. (Business Architecture Guild® membership required.)

Product Mapping (Business Architecture Guild® webinars): A webinar that summarizes product mapping and its usage. (Business Architecture Guild® membership required.)

How to Turn Advocacy Into Action (TED Talk): A TED Talk by Heidi Harmon about being an influential advocate for building community and causes that affect all of our lives. The best way to create a movement for change is to “show up, step up, and stand up.”

Copyright © 2024 S2E Transformation Inc. All rights reserved.