Business Architecture: Part I — Why It Matters to Business Executives
Business architecture is gaining recognition as a game-changing discipline that enables businesses to address major challenges in new and unique ways. Simply put, business architecture allows a business to establish a common vocabulary, shared vision, and a degree of transparency that facilitates initiatives ranging from M&As to the reversal of customer attrition. But even as business architecture success stories emerge, the message has been slow to penetrate the executive suite. This Executive Update, the first in a series, discusses why business leaders should embrace business architecture as a means of addressing complex business challenges in ways that senior leadership can no longer ignore.
Consider some real-world cases: A pharmaceutical firm uses business architecture to expedite a large-scale merger. An international airline follows suit. A finance and insurance company uses business architecture to investigate and reverse customer loss. A government agency uses business architecture to establish a vision to enable customer self-service. An international finance company uses business architecture to align the enterprise to a new business model. And finally, a large financial institution leverages business architecture to streamline its complex, postmerger portfolio.
THE BENEFITS OF BUSINESS ARCHITECTURE
In each of these scenarios, business architecture is sponsored by business leaders. This is essential because business architecture is owned by -- and most benefits -- the business. The most effective and impactful business architecture teams are comprised of business professionals representing a cross-section of business units, and this requires senior business sponsorship. Unfortunately, the business architecture message is just beginning to reach business leaders who are accountable for the success of these types of initiatives. To build executive support for business architecture, the benefits must be communicated in business terms. Common benefits include:
Delivers transparency and clarity to enable stakeholder collaboration, issue analysis, and problem resolution
Provides transparency across business units, product lines, and outsourced teams to enable cross-functional planning and ensure that funded initiatives are not working at cross-purposes
Aligns business processes across business units and product lines, delivering stakeholder-focused benefits far beyond traditional "lean" or similar process-streamlining exercises
Offers management teams a holistic view of the business that extends to outsourced, customer, and other stakeholder domains
Establishes a framework of concepts that allows the business to clearly communicate current-state business challenges and articulate a business-centric vision for the future
Allows the business to take ownership and drive transformation strategies through business-centric roadmaps and funding models
Offers IT a way to recast project-funding discussions in terms of business capabilities and stakeholder value, streamlining often difficult IT budget discussions
A COMMON VOCABULARY
Business architecture's main benefit is that it delivers a common vocabulary for communicating and reconciling critical business issues across a wide variety of stakeholders. Miscommunication is rampant across business. Terms as seemingly straightforward as "customer," "representative," "product," "margin," "vendor," "broker," and "partner" are generally assumed but often misconstrued. Miscommunication is particularly common when discussions cross product lines and business units, which can lead to major problems, including a misstatement of expenses or angry customers. Poor communication stymies a wide variety of initiatives, such as improving basic business capabilities, creating common customer views, aligning processes across business units, and delivering accurate financial and regulatory reporting. Consequently, businesses have created modern-day versions of the Tower of Babel, which was never finished because the speech of the builders was confounded.
Consider two cases highlighting how lack of a common vocabulary can stymie progress, while a common business vocabulary can overcome these roadblocks. In the first case, teams responsible for creating coherent views of business information struggled for years to create a common view of enterprise data. The teams lacked an agreed-upon set of business definitions, and numerous initiatives stalled. The business wasn't engaged and couldn't see why this mattered. In the second case, a business architecture team created a capability map that identified what the business does in complete, concise ways. Capability definitions provided to the data architecture team allowed the team to craft a common data model that fully aligned to the business vocabulary. While teams in our first case continued to struggle with creating priority management initiatives, teams in our second case created a common information model that expedited projects across business units, customer initiatives, product lines, and complex processes and technologies.
The lesson learned here is that the lack of a common vocabulary has far-reaching effects and is the basis for many failed projects. Misperception and miscommunication stem from and further compound widespread redundancy and inconsistency, which in turn can lead to customer losses, missed opportunities, lost revenues, and millions of dollars in failed initiatives. The same issues are rehashed meeting after meeting due to a lack of transparency across business units and product lines. This process repeats itself year after year, stalling major initiatives, leaving business opportunities on the table, and running up spending on failed projects.
Business architecture addresses these issues by establishing a common language that planning and deployment teams can use to establish a routine understanding of issues as the basis for crafting robust, long-term solutions with demonstrable business benefits. Figure 1 provides an overview of the four main aspects that create the foundation for your business architecture: business capability, information assets, organizational view, and value streams. While business architecture includes other categories, these four comprise the baseline that business uses for issue analysis, planning, strategy planning, budgeting, and solution deployment.
Each category represents a unique view of the business but all are connected through a common vocabulary. The following summarizes this foundational view:
- Business capability. Capabilities provide a complete view of "what" a business does. Customer Management, for example, is a capability. Capabilities are organized into the business capability map, a hierarchical topology of what the business does. This map serves as a foundational view of the business that eliminates the inherent complexity involved in discussing "how" something is being done or "who" is doing it. Capabilities provide the basis for crafting business-driven transformation strategies, which often include improved or new, automated solutions.
- Information assets. Business information assets clearly define the information required to ensure that each capability is robust, viable, and acceptable to the business from a strategic perspective. For example, the definition of the "Account Management" capability must correspond to the definition of the information asset "Account." Information assets, along with capabilities, form the foundation for the business vocabulary and data architecture.
- Organizational view. Organizational view creates a structural overview of the business. This includes traditional business units and subunits but can be extended to include collaborative teams, outsourcers, and other external stakeholders. Organizational views can be enhanced by mapping business units to strategies, capabilities, and initiatives.
- Value streams. Value streams depict the activities involved in how a business delivers end-to-end stakeholder value. While the capability map is said to show the business "at rest," value streams show the business "in motion." Common value stream examples include Manage Customer Portfolio, Update Account, and Build Product. Value streams are always triggered by a stakeholder, shown as end-to-end views, and represent an aggregated view of cross-functional business processes. Value streams are the main aspect of business architecture used to align and consolidate business processes and deliver automated solutions with a high degree of stakeholder visibility.
BUSINESS ARCHITECTURE PLANNING, ROADMAP CREATION, AND BUDGETING
Business architecture provides a basis for transforming how business communicates and collaborates to achieve its goals across business units and product lines. One of the most fundamental benefits, however, is that business architecture enables a more business-focused investment strategy in major initiatives. Most noninfrastructure-focused IT spending is typically aligned to a given set of software applications. This approach limits the business vision to a siloed, technology-centric point of view and leaves critical capabilities not part of an IT solution today off the table, virtually ignoring horizontal views of how to deliver stakeholder value. Positioning investments in terms of business capabilities and value streams allows the business to focus on business value and not on IT centricities.
Using business-focused roadmaps and related budgetary models does not imply a "big bang" or "boil the ocean" approach. Having visibility across more than a single business unit does not mean that all issues or technologies will or should be addressed in a single project. Delivering a business-driven vision, strategy, roadmap, and related funding model through the use of the capabilities and value streams provided by the business vocabulary means that all aspects of a given capability and/or value stream are considered when making major initiative investments. However, this is rarely the case today because such visibility is sorely lacking.
For example, consider a bank that implemented a replacement system for a small portion of its risk-rating environment with no understanding of how it would replace the two systems already enabling this capability. Millions of dollars were spent, leaving the bank with three redundant, yet fragmented, applications enabling this capability. Little business value was achieved, and now the bank has three systems implementing the same capability in different ways, using three different views of business information. Consequently, the business has destabilized a portion of its business model. This could have been avoided had the business provided a capability-focused mandate to streamline and consolidate risk rating, along with a common strategy, vocabulary, and vision for the risk-rating capability and related information assets.
Thus, business architecture represents a philosophical shift in how we discuss business challenges, communicate across business lines, establish deployment plans, and allocate funding to improve business capabilities and stakeholder value. This shift will take time for many organizations and involves the transition from silo-based infrastructures, where every business unit has its own language, to a business ecosystem, where interdependencies -- particularly where it impacts stakeholder value, risk management, and bottom-line results -- are addressed in cohesive ways through streamlined approaches.
With business architecture, ineffectiveness and inefficiencies that drive up costs and contribute to failed projects will fade as a common business vocabulary takes hold. There is no need to wait for results. Many of the organizations introduced at the beginning of this Update began benefitting from business architecture in a very short period of time. As the business architecture matures, the use of it will mature as well. It only took a short time after rolling out the first capability map from one business team to begin using it to align strategies, transformation planning, roadmaps, and budgetary funding. Senior business leadership and sponsorship is essential to this effort.
In Part II, we will continue our discussion of the business architecture and examine business-driven transformation strategies, roadmaps, and budget models
More: Articles Like This
- Business Architecture: Part II — Business-Driven Transformation Strategies, Roadmaps, and Funding Models
- Business Architecture: Part II — Business-Driven Transformation Strategies, Roadmaps, and Funding Models
- The Next Big Thing for Enterprise Architecture: Business/Technology Roadmapping
- Cloud Architecture: Leveraging Strategies, Blueprints, and Roadmaps-- What's Different Today?
- Business Capability Architecture: Creating a Roadmap of Priorities