The business architecture (BA) encompasses the business vision, strategy, governance, organization and key business process information, as well as the interaction between these concepts. A knowledge of business is a prerequisite for business architecture work like in any other domain (data, application, integration, infrastructure and security), and therefore is the first architecture activity that needs to be undertaken, if not accounted for already in other organizational processes such as enterprise planning, strategic business planning, business process re-engineering, and others.
In practical terms, business architecture is also often necessary as a means of demonstrating to key stakeholders the business value of subsequent architecture work, as well as the return on investment realized from supporting and participating in the subsequent work.
Business modeling is mainly aligned to the approach that works with the Enterprise. Some organizations may find it comfortable to address value driven analysis or capability driven analysis to model the current or future state of architecture. The business modeling approach can be defined by use of industry standards like Business Process Modeling Notation (BPMN) or use of American Productivity and Quality Center (APQC)’s process mapping conventions.
Most people believed Business modeling is for justifying IT expenses 1, but it is much more than just justification. Bridgeland found there are 8 specific reasons mentioned, as below
- Communication between people
- Training and learning
- Persuasion and selling
- Analysis of a business situation
- Compliance management
- Development of software requirements
- Direct execution in software engines
- Knowledge management and reuse
In such Business Models can be several times including but not limited to following, but can be used in all above mentioned benefits.
Value maps reflect the activities that an organization performs to create the value being exchanged between itself and its stakeholders. Value maps focus on an outside-in view of the business which provides executives with a solid understanding of how value gets created. The Value Stream is one of several value mapping approaches within value analysis which identifies “how” value is exchanged between an organization and its stakeholders. The streams can be decomposed further into more detailed “value stages” where each activity adds value to the customer. These value streams and stages can then be heat mapped similarly to capabilities. Heat mapping identifies a given area of the business architecture and determines how well that value stream is performing by applying a rating to it. 2
Value streams have been defined as an “end to end” collection of activities that create value for the customer, who may be the ultimate customer or an internal end-user of the value stream. Value Streams also provide visual clarity to how value is exchanged between organization and stakeholder and helps to identify areas where capabilities could be weak and focus should be placed. Both value streams and value stages are discussed in depth in BIZBOK and listed as one of the most common approaches for value analysis and understanding where/how value is created.
Value Streams get triggered by a stakeholder and value stream name should match the triggering stakeholder’s objective. The value stream should have a process-like feel of value. The value stream can be interrupted and end prior to achieving the stakeholder’s goal, but it should be easily identified from where the stakeholder triggered the value stream. When decomposed further into value stages, the stages represent the series of interchanges with stakeholders that can be followed sequentially as the value stream moves from left to right.
As value streams are mapped to capabilities, they link together “how” a business achieves value and “what” a business does to support how that value is achieved. Planning teams can then utilize these value maps to improve the methods by which a business delivers value while determining which capabilities must be improved to support these methods. This knowledge helps guide project prioritization, approach, and roadmap development. This approach is considered core to business architecture. Value streams and stages can then be mapped to capabilities and processes to help aid value analysis.
Capability Based Modeling Approach
The standard and accepted definition in the architecture community of a capability is “a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome”. Capabilities define WHAT a business does, not how, where or why they do it. 3. Capabilities should be viewed as the basic building blocks of a business.
Having a solid understanding of what a business does allows for an in depth analysis of how well it performs this ability. The guiding principles behind Capabilities are:
- They offer a business-centric view of the organization
- Are defined without respect to department
- Are defined in business terms
- Are nouns, not verbs,
- Define what a business does
- Are stable and do not generally require changes
- Are defined only once for an enterprise
- Can be decomposed into more capabilities
- There is one capability map for a business
- They can be mapped to other views of the business
- Even though a business capability has been automated, it’s not an IT capability
- If the mapping team has difficulty defining a capability, then it’s probably not a capability
- Are named and defined by the individuals and business units who have a direct impact over and exercise those capabilities. (Business Architecture Guild, 2014)
Capabilities are used by Executives, planning teams and business teams throughout all aspects of business architecture and should be referred to regularly. Ideally, the Capability Model and Mapping team should be comprised of a Business Sponsor, Business Lead, Business Co-lead, Core Subject Matter Experts and a Mentor. There is no single correct way to approach capability mapping. It can be done from an enterprise top-down or bottom-up business unit approach.
Capabilities are generally decomposed to at least 3 levels where Level 1 is the Foundation Level, level 2 is the Capability Group Level and Level 3 is the Business Capability Level. They can be decomposed further, but generally not beyond level 6, all of which continue to define what a business does.
Developing Level 1 capabilities and decomposing them into lower levels involves discussing, validating, socializing, packaging and publishing the capability map. As the list of candidate Level 1 capabilities are established, define each with a single sentence that defines what, not how, why, when or where. As this work is refined, it is should also be validated against the organization chart and industry perspectives. Level 1 then gets classified as either Strategic, Core or Supporting. Ideally, socializing and validating should be performed throughout this process by those involved in the given capabilities. A Level 1 “draft” map is produced. Level 1 capabilities are then further decomposed to Level 2 capabilities and so on to at least Level 3 following the same process. Capabilities are continually refined through iteration. Packaging is the creation of a formal document to showcase the capability map.
Once the capability model is complete, it should not require frequent revision, however over time as a company’s business model or company expands/contracts markets or acquires/divests key segments of operations it may require thought into adding and/or removing capabilities. Gaps and overlaps can be identified by validating enterprise Capabilities against Value Streams, Value Stages, and Processes.
Business Canvas & Business Scenarios
A Business Model describes the rationale of how an organization creates, delivers and captures value. The Business Model Canvas articulates a company’s core business and describes how revenue is made and the expenses incurred to generate that revenue.
Business Scenarios will help identify and understand the as-Is processes as they are used in specific business conditions, they will show the desired outcome of proper execution, is a representative of a significant business need or problem, and thereby help to derive the business requirements and improvements for the future state. The business architects responsible for capturing these scenarios, and are done alongside the creation of the as-is Business Process Mapping List (BPML) and Application Interaction Diagram (AID) using Business and Technical Subject Matter Experts.
- Rise Business Modeling, Bridgeland, 2008, Morgan Kaufmann Publishers, ISBN: 978-0-12-374151-6
- Business Architecture Guild, BizBok Guide
- Capability Driven Development: An Approach to Designing Digital Enterprises, Brzisa, Solvita; Bravos, George; Gonzalez, Tania Cardona; Czubayko, Ulrich; España, SergioAuthor InformationView Profile; et al. Business & Information Systems Engineering57.1 (Feb 2015): 15-25