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.
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.”