Module 2 — Business Architecture

Business architecture is "a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands." It is the bridge between the enterprise business model and strategy on one side, and the business functionality of the enterprise on the other.

The module's teaching device is worth copying: analyse Lumen's business before leaning on the terminology, then revisit the same case at the end so the difference in quality is felt rather than told.

Drivers, goals, objectives

Business driver — a resource, process or condition vital for the continued success and growth of a business. A company must identify its drivers and try to maximise those under its control; there are always outside drivers it cannot influence, such as economic conditions or trade relations between nations. Name a driver with a noun.

Four categories — everything in a business case must relate directly to proving one or more:

1. Increase or protect revenue
2. Reduce cost or increase efficiency
3. Reduce risk
4. Compliance

Examples of drivers: accelerate revenue recognition; reduce COGS/cost; improve business productivity (more goods from the same inputs); improve business effectiveness (product-to-market penetration); improve market competitiveness (share); enable new business; mitigate risk; improve planning and forecasting.

How to find drivers — root-cause analysis over the financial statements. Start from the statements and ask "what drives this line item?" repeatedly:

What drives revenue? → volume of products sold × average price. What drives volume? → the number of products and the number of salespeople. What drives salespeople? → the number and sizes of stores. What drives the number of stores? → this is a core business driver — an operational and capital decision, with nothing preceding it.

Repeat for each line item on each of the three financial statements, then determine which drivers are most important to focus on: those that impact the most areas of the business and have the largest effect on results.

Goals vs objectives: goals are general statements of desired achievement; objectives are the specific steps or actions taken to reach a goal. Both should be specific, measurable and SMART. Goals can involve profitability, growth, customer service. Express them with qualitative words — "increase", "improve", "easier".

Terminology varies: some companies use goals for the company as a whole, objectives for departments, and targets for individual employees.

Do not start out with what you have and then figure out what it can be used for. A far more successful approach is to start with what you want to accomplish, then determine what you have — and what you need — in order to accomplish it.

As an architect you must do the background research necessary to understand the goals; they are not always clearly explained in the case.

Worked example — Lumen Diagnostics. The six "aspects" in the case are the customer's words for drivers. Named as nouns, they map like this:

Goal 2 exists because goal 1 has a consequence: automation that nobody can see is still a desk full of phone calls. Goals are strategic, set over months or years — attach possible metrics so achievement can be proven (desk hours per referral, unused partner slots, time-to-offer). The final picture should let you trace Drivers → Goals → Objectives, with each objective covered by some part of the solution.

Business value, capabilities, value streams

• Business value — the benefits a firm generates for its stakeholders, including long-term ability to create revenue, products, services, employment, quality of life and investment returns.
• Business capability — encapsulates what a business is doing right now and what it needs to be doing to meet current and future challenges. Capabilities define what a business does rather than how (which processes describe). "Recruit talented employees" is a capability necessary to a goal of having a competitive workforce; it says what is needed but leaves open whether there is an HR process from recruiting website to interviews to hiring administration, or whether everything is outsourced. Every capability decomposes into three overlapping components — People (human resources), Processes (business processes) and Technology (IT applications and technical resources) — so assessing or redesigning any one capability means examining all three layers, not just the process layer. Capabilities are the basic building blocks of a business, and the capability map in its entirety delivers a concise, non-redundant, business-centric view at its most basic level.

• Value stream — an artifact allowing a business to specify the value proposition derived by an external (customer) or internal stakeholder. It depicts the stakeholders initiating and involved, the stages creating specific value items, and the value proposition derived — an end-to-end collection of value-adding activities creating an overall result for a customer, stakeholder or end-user, using capabilities as steps. The value map shows how the organisation creates the value exchanged between itself and its stakeholders.

A value stream chains capabilities end-to-end toward one customer-visible result — the specific capabilities vary by business, the chaining pattern doesn't.

• Value proposition — an innovation, service or feature intended to make a company, product or service attractive. In a nutshell it explains how your product solves customers' problems or improves their situation, delivers specific quantified benefits, and tells why the customer should buy from you and not the competition.
• Strategy — the pattern or plan integrating an organisation's major goals, policies and action sequences into a cohesive whole. The balanced scorecard is a strategy performance management tool — a semi-standard structured report supported by design methods and automation tools.
• Information — the typical approach: extract information concepts from capabilities; identify capability-based relationships for information concepts; extract relationships from matching capabilities; define information concepts; identify their types; identify their use; validate the information map.
• Organisation — the organisation map provides visibility on the business, describing business units and communication approach. An organisation typically has one or more leaders making strategic decisions. One way to describe it is via capabilities and their virtual relationships; another is an organisational chart describing structure, departments, groups and teams hierarchically.

The value of a capability map lies mostly in analysing current vs desired levels of capability, and in uncovering capabilities the organisation already possesses but does not recognise or manage explicitly. Capabilities and capability levels in a target business architecture give high-level direction for change — this is the core of capability-based planning.

Stakeholders

Formally (per the PMBOK Guide), a stakeholder is any individual, group or organisation that may affect, be affected by, or perceive itself to be affected by a decision, activity or outcome of the project — a deliberately wide net that goes beyond just the people paying for or using the solution.

There are always several stakeholders and all are important, as they define official and often personal requirements and interests that must be taken into consideration. Understanding the organisation and business context helps identify vendors, partners, HR, clients and everyone else who needs to be on the architect's radar.

Identification techniques:

Definitions:

• Stakeholder groups — depending on classification, a stakeholder may belong to different groups: organisation/organisation unit, or power/influence/interest.
• Concerns — the issues, risks and constraints stakeholders have with the solution. This may include the use of the solution, perceptions of its value, and the impact it has on a stakeholder's ability to perform necessary functions.
• Stakeholder requirements — describe the needs of stakeholders that must be met to achieve the business requirements; they may serve as a bridge between business and solution requirements.

The ISO 42010 distinction between a view and a viewpoint is worth carrying over from Module 1 here: a view is what you actually see, a viewpoint is the vantage point that determines what you see. An architecture viewpoint is a set of conventions — model kinds, notations and analytic techniques — for constructing and interpreting one type of view so that it addresses a specific set of stakeholder concerns (examples: operational, systems, technical, logical, deployment, process, information), while an architecture view expresses the system from the perspective of one or more stakeholders using those conventions.

Stakeholder registry (worked example)

Lumen names some roles in the RFP (Scheduling Manager, referral desk, partner practices, patients). Most of the rest are hidden — integration SMEs, the sponsor who pays, security, the supplier team.

The three groups to work through: Users of the system (concerned with usability and the job they do at the desk, in a partner practice, or as a patient); Customers — the sponsor who pays and is concerned with timeline and cost, plus integration SMEs for the referral system, identity and SSO, and very often CIO, enterprise architect and security; and the Project Team who design, implement and support the solution.

Some stakeholders can be found in the case description, but most of them are hidden, and it is a real art to find all project stakeholders.

Concrete tactics for surfacing the hidden ones: have an informal coffee with people around the project, build both formal and informal relationships, do background research on the company, and mine artefacts such as email threads, commit history, the author metadata on shared documents, and the client's own market and sales materials.

Power / interest prioritisation

Beyond the power/interest matrix, two further techniques map stakeholder relationships from a different angle: the personal interest diagram and the social diagram. Both help avoid a common trap when identifying the powerful stakeholders — the most vocal person in the room is not necessarily the most powerful one, and real influence often has little to do with someone's official title, so both formal and informal relationships need to be observed.

RACI

• Responsible — the person assigned to do the work
• Accountable — the person who makes the final decision and has ultimate ownership
• Consulted — must be consulted before a decision is made
• Informed — must be informed that a decision or action has been taken

The most complicated part is understanding the difference between Accountable and Responsible. The accountable person signs off the work, has the authority to make a decision, and is whose head rolls if it goes wrong. The responsible person is responsible for the execution of the activity. Accountability comes before responsibility, and one activity must be associated with a single accountable person only.

Example for a construction phase on Lumen:

In this case the PM is accountable for most delivery stages — but that does not mean the PM is always accountable for everything. UAT sign-off sits with the Scheduling Manager; integration of the referral system has a customer accountable. A template can exist, but the project has its own RACI matrix tuned to the current project context.

Worked example — capabilities (Lumen)

At this stage do not pick a stack, and do not produce a WBS. Name the functional parts the platform must have:

• Identity and access — corporate SSO for staff; patient portal sign-in
• Availability search and prioritisation — partner slots plus uploaded slots, ranked by clinical match and Scheduling Manager rules
• Offer and confirmation workflow — the Requested → … → Billed stages, including manual booking by the desk
• Change management / referral sync — inbound updates, merge policy, alerts, manual reassignment
• Partner slot management — manual upload of availability, pricing and capability
• Partner scheduling adapter — one automated partner group; the rest stay on the manual path
• Patient portal — view, confirm or decline, print, feedback
• Administration portal — configuration, status, reporting
• Notifications — email and SMS on stage change
• Reporting — appointment detail, partner performance, financial
• Appointment consolidation — combine studies into one visit where clinically permitted

Each of those traces to an objective in the worked driver table. If a capability does not, it is scope you invented.

Requirements (BABOK classification)

Functional requirements — product features or functions developers must implement to enable users to accomplish their tasks, so they must be clear to both the development team and the stakeholders. They generally describe system behaviour under specific conditions:

• The system sends an approval request after the user enters personal information.
• A search feature allows a user to hunt among various invoices if they want to credit an issued invoice.
• The system sends a confirmation email when a new user account is created.

Non-functional requirements — not related to system functionality but defining how the system should perform:

• The website pages should load in 3 seconds with fewer than 5,000 simultaneous users.
• The system should be able to handle 20 million users without performance deterioration.

The other two requirement types pair with worked examples just as concrete: a business requirement such as "reduce incorrectly processed orders by 50% by the end of next quarter", a stakeholder requirement such as "view order history" or "check order status", and a transition requirement such as "users must pass an online certification before being allowed to use the system" — illustrating how the same classification scales from strategic intent down to a temporary go-live condition.

Note the terminology debate the course flags: some people dislike "non-functional" and use QA requirement or constraint instead, because some such requirements — performance, for instance — might be a very important "function".

Risks, assumptions, issues, dependencies

Conway's Law

The organisation's communication structure must be reflected in the solution architecture design, and an optimised architecture might have an impact on the business by showing how work can be done more efficiently, or even just by exposing a gap. Therefore, if we understand the organisation's communication structure it helps us design the modules and components and assign the right responsibilities to them.

Beyond formal, well-defined communication channels there are informal ones — a daily coffee chat. Identifying both is crucial to understanding the real need of the solution.

Note also that multiple solutions may be identified, not just one — and the solution is not necessarily limited by the boundaries of the customer organisation, and can cover or support multiple capabilities at the same time.

As a solution architect, put more focus on stakeholders, business processes and all the relevant requirements. Identifying the right stakeholders and maintaining a good relationship with them is crucial. Understanding the solution-related business processes helps identify more stakeholders and clarifies what the solution must support. Requirements define everything, including the constraints that impact the solution.

Analysis techniques (BABOK)

Benefits Dependency Network (BDN). Useful because it keeps focus on benefits realisation during programme execution, and allows variations of the project or programme to be assessed for their impact on benefits realisation. A well-constructed BDN tells the story of the project visually: in one diagram it shows why the programme is needed, what objectives it aims to achieve, how the organisation needs to change, and what projects must be undertaken. It can be read left-to-right or right-to-left, helps identify critical paths, can serve as the basis for the programme plan, and enables discussion of the relative contributions of the different projects — which in turn enables the right resource-allocation decisions.

Business processes are a huge topic not covered directly by this training, but there are indirect references — value streams, capability mapping — which are a great baseline for further discussion.

Exercises — Module 2

Task. Produce a business-architecture pack for Lumen Diagnostics. Output: drivers/goals/objectives, stakeholder registry, power/interest matrix, RACI, capability list (not a WBS).

• Read the Lumen Diagnostics case
• Document business drivers, goals and objectives
• Document stakeholders

  • Fields: Name, Role, Group, Concerns, Views
• Prioritise stakeholders and draw a power/interest matrix
• Create a RACI for stakeholder responsibilities
• List the main system capabilities (functional decomposition)

  • Do not produce a detailed WBS; that is out of scope here