Business systems planning

Business systems planning is an enterprise information-planning method that derives an information architecture by relating organizational strategy, business processes, data classes, and application responsibilities.

Version

v1 · 2026-09-28 · History

Domain-specific #

8302

Domain group

Applied Sciences & Engineering

Origin domain

Computer Science & Software Engineering

Subdomains

Enterprise Information Architecture, Information Systems Planning → Computer Science & Software Engineering

Core Idea

Business systems planning (BSP) is a structured enterprise-planning method for deriving an information architecture and systems roadmap from an organization's strategy, processes, data, and existing applications. Developed by IBM, it begins with executive sponsorship and a defined study scope, then identifies business objectives, decomposes the enterprise into enduring processes and data classes, maps which processes create and use which data, assesses current information support, and groups future systems around business needs rather than around the current departmental application inventory. Its intended result is a prioritized blueprint aligning information-system investment with enterprise direction.

How would you explain it like I'm…

Plan the Computers Around the Work

Before building a big new playground, you'd first ask what games kids really play and what toys they share. Business systems planning is like that for a company's computers: first figure out the company's main jobs and the information those jobs need, then plan which computer systems to build, in what order.

Jobs-and-Data Systems Plan

Business systems planning is a careful method, created by IBM, for deciding which computer systems a big organization should build. First, leaders agree to support the study and decide what it covers. Then the team lists the company's goals, the main activities it always does, and the kinds of information it uses, such as customers, orders, and products. They make charts showing which activity creates or uses which information. From those charts they plan future systems in an order that makes sense, built around the work instead of around departments.

Top-Down Information Systems Planning

Business systems planning (BSP) is a structured method, developed by IBM, for working out an organization's information architecture and its roadmap of computer systems from the top down. It starts with executive sponsorship and a defined scope, identifies business goals, and breaks the organization into lasting processes and data classes (kinds of information such as customer, order, or invoice). Matrices showing which processes create and use which data reveal duplicated data, gaps, fragile connections, and systems that follow department lines instead of whole workflows. Processes and data are used because they stay stable longer than org charts or particular applications. Interviews add goals, pain points, and priorities that charts can't show, and the result is a prioritized, step-by-step plan rather than a replace-everything project. It is not detailed software design or general strategic planning, and it can become a stale, expensive document if treated as a one-time exercise.

 

Business systems planning (BSP) is IBM's structured enterprise-planning method for deriving an information architecture and systems roadmap from an organization's strategy, processes, data, and existing applications. The procedure begins with executive sponsorship and a scoped study, identifies business objectives, decomposes the enterprise into enduring processes and data classes, maps which processes create and use which data, assesses current information support, and groups future systems around business needs rather than the existing departmental application inventory. The process–data relationship is central because core activities and business entities such as customer, order, product, employee, or invoice are more stable planning anchors than org charts or particular applications. Process/data matrices expose duplicated data ownership, missing support, brittle interfaces, and systems whose boundaries follow departments rather than end-to-end work. Interviews and management review provide goals, pain points, constraints, and priorities that the matrices cannot infer. The output is a prioritized blueprint that sequences projects, transition dependencies, and governance, aligning IS investment with enterprise direction. BSP is distinct from detailed software design, a single architecture diagram, or generic strategic planning; it is resource-intensive and can go static if run once, and later enterprise-architecture practice changed its notation and cadence while reusing its alignment logic.

Scope of Application

• Executive alignment. Objectives and sponsorship connect systems investment to enterprise direction.

• Process inventory. Durable business activities provide an organizing frame less volatile than one organizational chart.

• Data-class architecture. Shared entities and records are identified independently of duplicated applications.

• Process–data matrices. Create and use relationships reveal ownership gaps, redundancy, and integration needs.

• Current-portfolio assessment. Existing systems are mapped to business support, technical condition, cost, and overlap.

Clarity

Business systems planning names a structured method for deriving an enterprise information architecture and systems roadmap from strategy, enduring business processes, data classes, and current support. It is not simply an application inventory or an IT project list. The process–data matrix separates who currently owns software from which activities create and use information.

Manages Complexity

Business systems planning reduces an enterprise's shifting departments and application inventory to durable business processes, data classes, create–use relations, strategic objectives, and current support gaps. The process–data matrix exposes which information is shared, duplicated, missing, or trapped by organizational boundaries. The analyst groups future systems around stable needs and ranks projects by strategic contribution and dependency. Top-down objectives and bottom-up operational evidence become two views of one blueprint.

Abstract Reasoning

Architecture move. From strategy and enduring business processes, infer the data classes and information capabilities future systems must support. Matrix move. Use process–data create/use relations to locate ownership gaps, duplication, and cross-functional dependencies. Prioritization move. Rank systems by strategic value, dependency, risk, and implementation sequence rather than departmental demand alone. Transition move. Compare current applications with the target architecture to infer consolidation, replacement, integration, or new development. Boundary move.

Knowledge Transfer

Within the home domain. Business systems planning transfers across enterprise information-systems programs where processes and data classes are mapped to identify stable application groupings and an implementation sequence. Business strategy, process inventory, data ownership, information architecture, and migration priorities retain planning roles. Beyond the home domain (C — planning method). The method can be applied literally to organizations with comparable information dependencies, though modern architecture practices may replace or adapt its artifacts.

Relationships to Other Abstractions

Current abstraction Business systems planning Domain-specific

Parents (1) — more general patterns this builds on

• Business systems planning is a kind of Planning Prime

  Business systems planning is a domain-specific kind of Planning: Business systems planning is an enterprise information-planning method that derives an information architecture by relating organizational strategy, business processes, data classes, and application responsibilities.

Hierarchy path (1) — routes to 1 parentless root

• Business systems planning → Planning → Foresight

Neighborhood in Abstraction Space

Business systems planning sits in a sparse region of the domain-specific corpus (68^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2551 abstractions)

Nearest neighbors

• Enterprise Architecture — 0.88
• Data ethnography — 0.85
• Ecosystem Mismatch — 0.84
• Database application — 0.83
• Lehman's law of conservation of organizational stability — 0.83

Computed from structural-signature embeddings · 2026-10-08