BABOK Perspectives: Agile, BI, IT, Business Architecture, BPM

Key ideas#

What a perspective tells you#

The BABOK Guide presents each perspective in the same structure: the scope of change it usually involves, the scope of the analysis work (sponsor, objectives, the analyst’s position, typical outputs), methods and techniques specific to that context (beyond the 50 core techniques), the underlying competencies that matter most, and how each of the six knowledge areas shifts. The guide does not claim the five are the only possible views; they were the most common ones when it was written.

Agile#

Agile is a mindset with values, principles and practices. Change is expected all the time, and the analyst delivers work products as late as responsibly possible, just before they are needed. Analysis is continuous and relies on interpersonal skills: communication, facilitation, coaching, negotiation. The analysis role may be played by a product owner or manager, a business analyst or another established role. The product is managed as a prioritized backlog, and scope is re-examined each time the backlog is re-prioritized. The guide notes that not every iterative approach is agile, and not every agile approach is iterative (Kanban is an example).

What changes for you: fewer big documents, more just-in-time detail, constant prioritization. See Product Owner vs. Proxy Product Owner.

Business Intelligence#

BI turns data into information that supports decisions at strategic, tactical and operational levels, ideally from a single trusted source. The guide distinguishes three kinds of analytics: descriptive (explaining the past with dashboards and KPIs), predictive (finding patterns to forecast) and prescriptive (recommending specific actions through optimization and simulation). Two contrasts help scope BI work: supply-driven (“what value can we get from the data we already have?”) versus demand-driven (“what information do decisions need, and where will it come from?”), and structured versus unstructured data.

What changes for you: requirements are about information, decisions and data sources rather than screens. See Requirements for Business Intelligence Projects and Data Mining.

Information Technology#

This perspective covers changes to IT systems under traditional, non-agile approaches. The analyst often acts as a translator between business and technical stakeholders, and typically writes solution requirements while architects and developers own technical design. The guide names three factors that shape the work (the solution’s impact on the business, the organization’s maturity, and the size of the change) and distinguishes predictive from adaptive development approaches, with hybrids in between. Systems thinking is singled out as the key competency: seeing which applications, processes and people a change touches indirectly.

What changes for you: more formal documentation and sign-off, strong attention to integration and impact. See Solution Delivery Lifecycles.

Business Architecture#

Business architecture models the whole enterprise to show how it meets stakeholders’ strategic interests and to support transformation. The guide highlights four principles: enterprise-wide scope; separation of concerns (what the business does, what information it uses, who does it, where, when, why and how well are modeled separately and combined as needed); scenario-driven views (different questions need different views and metrics); and knowledge-based reuse through a repository. Typical models include capability maps, value stream maps, customer journey maps, organization maps and roadmaps.

What changes for you: longer time horizons, executive audiences, a high tolerance for ambiguity. See Business Capability Analysis.

Business Process Management#

BPM views the organization through end-to-end, cross-functional processes that deliver value. The guide describes a lifecycle of design (current versus future state), modeling (including simulation), execution and monitoring (real performance data) and optimization, repeated over time. Approaches range from top-down to bottom-up and from people-focused to automation-focused. Typical analyst outputs are process models, business rules, process performance measures and decision definitions. The analyst often acts as a neutral facilitator between groups with different interests.

What changes for you: you work with process owners and measure process performance, not just requirements. See What Is Business Process Management (BPM)?.