6.5 Define Design Options

Key Takeaways

  • Task 24 (Define Design Options) formulates and articulates alternative solution approaches to operationalize validated requirements.
  • Solution approaches encompass Create/Build (custom development), Purchase/COTS (commercial off-the-shelf software and SaaS), and Partner/Outsource (third-party APIs and managed services).
  • Defining design options requires specifying changes across three solution layers: Business Process Improvements, Enterprise & Technology Architecture, and Organizational Structure Adjustments.
  • Design options represent distinct trade-offs across capital expenditure (CapEx), operational expenditure (OpEx), IP control, customization flexibility, SLA guarantees, security, and integration complexity.
  • The golden rule of COTS adoption mandates adapting operational business processes to standard vendor software workflows rather than customizing core baseline code.
Last updated: August 2026

6.5 Define Design Options

Purpose of Task 24

The primary objective of Task 24: Define Design Options is to formulate, structure, and articulate alternative solution approaches that fulfill validated requirements and satisfy enterprise constraints. Once requirements specify what business capability, functional behavior, or value is needed, the business analyst collaborates with solution architects, technical leads, domain experts, and external software vendors to investigate how those requirements can be operationalized.

In business analysis practice, there is rarely only a single way to solve an enterprise problem. Defining multiple, distinct design options provides executive decision-makers with meaningful strategic choices. Each candidate design option represents a unique balance between capital expenditure, implementation speed, ongoing operational maintenance, technical risk, intellectual property control, and organizational change friction. Senior BAs structure design options so that trade-offs are explicit and transparent prior to committing capital.


Solution Approaches Taxonomy: Create/Build, Purchase/COTS, Partner/Outsource

BABOK® Guide v3 categorizes solution approaches into three baseline strategies. Each strategy establishes a distinct operational, financial, and technical risk profile:

Solution StrategyCore Definition & Architectural ProfilePrimary Strategic AdvantagesPrimary Operational Risks & Trade-Offs
Create / Custom BuildSoftware components and business processes engineered entirely in-house or by contract software developers tailored strictly to proprietary specifications.Maximum flexibility, full intellectual property (IP) control, perfect alignment with unique business processes.Highest initial capital cost (CapEx), longest delivery timeline, ongoing software maintenance burden.
Purchase / COTS (Buy)Commercial Off-The-Shelf (COTS) software applications or Software-as-a-Service (SaaS) platforms licensed from third-party software vendors.Rapid speed-to-market, built-in industry best practices, vendor-managed updates and bug fixes.Requires business process modification, vendor lock-in risk, recurring licensing fees (OpEx), integration complexity.
Partner / OutsourceEngaging external managed service providers, strategic allies, or Business Process Outsourcing (BPO) vendors executing capabilities via APIs or contracts.Minimal upfront infrastructure investment, shared operational risk, immediate access to specialized expertise.Loss of direct operational control, dependence on third-party SLA compliance, data security/privacy exposure.
                              SOLUTION APPROACH COMPARATIVE MATRIX
 ┌─────────────────────────┬─────────────────────────┬─────────────────────────┐
 │   CUSTOM BUILD (CREATE) │     PURCHASE (COTS)     │    OUTSOURCE (PARTNER)  │
 ├─────────────────────────┼─────────────────────────┼─────────────────────────┤
 │ • Delivery Speed: Slow  │ • Delivery Speed: Fast  │ • Delivery Speed: Medium│
 │ • Upfront Cost: High    │ • Upfront Cost: Medium  │ • Upfront Cost: Low     │
 │ • Customization: 100%   │ • Customization: 20-40% │ • Customization: Low    │
 │ • IP Control: Full      │ • IP Control: Shared/None│ • IP Control: Partner   │
 │ • Maintenance: Internal │ • Maintenance: Vendor   │ • Maintenance: Partner  │
 └─────────────────────────┴─────────────────────────┴─────────────────────────┘

Solution Architectural Layers

When defining design options, a senior business analyst must ensure that every option addresses required changes across three mandatory solution layers:

1. Business Process Improvements

Design options detail how operational workflows and daily business activities will change. This includes identifying automated workflow triggers versus manual handoffs, eliminating redundant verification steps, defining operational exception handling, and establishing process performance baselines.

2. Enterprise & Technology Architecture

Design options specify the technical building blocks and IT infrastructure needed to support the capability. This encompasses evaluating cloud hosting (AWS/Azure/GCP) versus on-premises servers, microservices architectures versus monolithic platforms, REST/GraphQL API integration layers, database engines, data privacy encryption, and cybersecurity frameworks.

3. Organizational Structure Adjustments

Design options outline necessary changes to human capital and corporate structure. This includes identifying modified job descriptions, revised reporting lines, shift staffing allocations, employee retraining programs, change management initiatives, and governance oversight bodies.


Trade-off Analysis Dimensions

To construct a comprehensive design option evaluation, the BA structures analysis across six critical trade-off dimensions:

  1. Capital Expenditure (CapEx) vs. Operational Expenditure (OpEx): Upfront custom engineering and software license purchases (CapEx) versus recurring monthly cloud subscriptions and managed service retainers (OpEx).
  2. Intellectual Property (IP) Control & Competitive Advantage: Retaining 100% ownership of proprietary algorithms to maintain competitive differentiation versus adopting shared vendor software accessible to market competitors.
  3. Customization Flexibility vs. Vendor SLA Guarantees: Total internal control to modify system features at will versus relying on rigid vendor release roadmaps and contractual Service Level Agreements.
  4. Security, Compliance & Data Sovereignty: On-premises data control compliant with strict sovereign regulatory mandates versus multi-tenant cloud storage carrying external cybersecurity exposure.
  5. Integration Complexity & Technical Debt: Custom API integration glue code connecting legacy databases versus native out-of-the-box platform connectors.
  6. Time-to-Market vs. Operational Maturity: Rapidly launching a basic COTS MVP to capture market share versus spending 18 months engineering a fully mature custom platform.

COTS Adaptation Rules and Customization Anti-Patterns

Adopting Commercial Off-The-Shelf (COTS) software introduces a fundamental business analysis principle known as the Golden Rule of COTS Implementation:

An enterprise adopting COTS software must adapt its internal business processes to match standard vendor software workflows, rather than customizing vendor software code to match legacy business processes.

The Customization Anti-Pattern

Attempting to heavily modify standard COTS software code creates severe operational liabilities:

  • Broken Vendor Upgrade Paths: Heavy custom code modifications prevent the enterprise from applying vendor security patches and feature updates.
  • Extreme Lifecycle Costs: Upgrading customized COTS software requires re-engineering custom patches, inflating long-term total cost of ownership (TCO).
  • Loss of Vendor Support: Vendors frequently void software support warranties if internal IT teams alter baseline source code.

Expanded Worked Example: Retail Supply Chain Fulfillment

A national retail enterprise needs to replace its legacy warehouse dispatching system to support omnichannel 1-hour fulfillment. The senior BA formulates three distinct design options for executive review:

                               RETAIL SUPPLY CHAIN DESIGN OPTIONS
 ┌──────────────────────────────────────────────────────────────────────────────────┐
 │ OPTION A: Custom Cloud Microservices Build                                      │
 │ • Process: Proprietary robotic picking workflows.                               │
 │ • Tech: AWS Serverless microservices, custom ML routing algorithms.              │
 │ • Financials: $4.2M CapEx | $300k/yr OpEx | 18-Month Launch | Risk: High         │
 └──────────────────────────────────────────────────────────────────────────────────┘
 ┌──────────────────────────────────────────────────────────────────────────────────┐
 │ OPTION B: COTS Enterprise Supply Chain SaaS (Tier-1 Package)                      │
 │ • Process: Adapt warehouse steps to standard SAP / Manhattan SaaS workflows.    │
 │ • Tech: SaaS Cloud, native ERP connectors, configuration-only rules.             │
 │ • Financials: $1.8M CapEx | $650k/yr OpEx | 7-Month Launch | Risk: Low          │
 └──────────────────────────────────────────────────────────────────────────────────┘
 ┌──────────────────────────────────────────────────────────────────────────────────┐
 │ OPTION C: Hybrid 3PL Logistics Partner Integration                               │
 │ • Process: Outsource 60% regional fulfillment to 3PL partner; internal management.│
 │ • Tech: REST API integration layer, lightweight tracking portal.                 │
 │ • Financials: $800k CapEx | Variable 3PL fees | 4-Month Launch | Risk: Medium     │
 └──────────────────────────────────────────────────────────────────────────────────┘

Analysis: The BA presents Option A (High IP control, high CapEx, slow), Option B (Standard SaaS, fast launch, process adaptation), and Option C (Outsourced, lowest CapEx, SLA dependent), allowing executive leaders to evaluate strategic priorities transparently.


CBAP Exam Strategy & Distractor Analysis

  • Differentiate Task 24 from Task 25: Remember that Task 24 (Define Design Options) focuses exclusively on formulating candidate solution options and identifying trade-offs. Evaluating financial returns and selecting the winning option is performed in Task 25 (Analyze Potential Value and Recommend Solution).
  • Process Adaptation in COTS Scenarios: When an exam question describes purchasing COTS software, the correct BA action is almost always to guide business stakeholders toward adapting operational processes to fit standard COTS functionality.
  • Mandatory Three Solution Layers: Ensure design options address Business Process, Technology Architecture, and Organizational Structure adjustments.
Loading diagram...
Task 24 Design Options Formulation Framework
Distribution of Solution Strategies Evaluated in Enterprise Analysis
Test Your Knowledge

A business analyst is working on a core logistics project. The business requirement states that driver delivery routes must update dynamically in real time based on traffic congestion. The BA documents two alternatives: Alternative 1 involves building a proprietary routing engine using custom AI algorithms; Alternative 2 involves licensing Google Maps Enterprise API. What activity is the BA executing?

A
B
C
D
Test Your Knowledge

An enterprise financial institution decides to adopt a Commercial Off-The-Shelf (COTS) SaaS platform for managing customer relationships. What is a standard operational trade-off that the BA must plan for when adopting a COTS solution strategy?

A
B
C
D
Test Your Knowledge

A senior BA is structuring candidate design options for an executive decision package. What three solution dimensions must be explicitly addressed within each design option?

A
B
C
D
Test Your Knowledge

A retail bank needs to implement fraud detection within 60 days to comply with a new federal regulation. Custom building an in-house machine learning platform will take 14 months, whereas partnering with an established fraud management API vendor can achieve deployment in 30 days at a higher ongoing transactional cost. How should the BA present this choice?

A
B
C
D