Focus: Business Analyst Booklet

Objective

Business analysts stand between unbounded and moving business landscapes on one hand, distinctive and steady enterprise organization and culture on the other hand.

Assuming that BAs’ primary concern is to keep ahead of the competition, framing business undertakings into universal guidelines could be counterproductive. By contrast, harnessing together versatile business processes and reliable systems architectures will clearly enhance business agility; hence the benefits of lining up enterprise architects’ and business analysts’ conceptual toolboxes:

1. Concepts : eight exclusive and unambiguous definitions provide the conceptual building blocks.
2. Models: how the concepts are used to consolidate business requirements and convey them to enterprise architects and software engineers.
3. Processes: how to harness organization and business objectives and align applications with business value.
4. Architectures: how to contrive along time the continuity and consistency of business concepts and objectives, and their congruence with systems capabilities.
5. Governance: assessment of business value and risks.

On that basis, the objective here is not to detail BAs’ tasks or methods but to focus on core issues to be addressed by business analysts.

Concepts

Whereas systems architecture is not their primary concern, business analysts should nonetheless share the same modeling paradigm:

• Analysis models for business environments and objectives.
• Design models for the architecture of systems and the specification of components.

It is worth to remind that the distinction between descriptive (aka analysis) and prescriptive (aka design) models is not arbitrary but based on logic principles: the former are extensional as they classify actual instances of business objects and activities; in contrast, the latter are intensional as they define the features and behaviors of required system artifacts.

The distinction also brings organizational benefits as it tallies with BAs’ responsibility regarding the consistency and continuity of identities and semantics of actual objects and processes (business extensions) and their symbolic counterparts (system intensions):

• Actual containers represent address spaces or time frames; symbolic ones represent authorities governing symbolic representations. System are actual realizations of symbolic containers managing symbolic artifacts.
• Actual objects (passive or active) have physical identities; symbolic objects have social identities; messages are symbolic objects identified within communications. Power-types (²) are used to partition objects.
• Roles (aka actors) are parts played by active entities (people, devices, or other systems) in activities (BPM), or, if it’s the case, when interacting with systems (UML’s actors). Not to be confounded with agents meant to be identified independently of their behavior.
• Events are changes in the state of business objects, processes, or expectations.
• Activities are symbolic descriptions of operations and flows (data and control) independently of supporting systems; execution states (aka modes) are operational descriptions of activities with regard to processes’ control and execution. Power-types (²) are used to partition execution paths.

While business analysts should only be tasked with the continuous and consistent mapping of business individuals to their system surrogates, and not with their implementations, that cannot be achieved without a full and unambiguous specification of the variants and abstractions for the business objects and processes to be represented.

Languages & Models

Being in charge of requirements, business analysts can be seen as the gate-keepers of the whole engineering process. To begin with, and depending on the nature of domains, BAs can capture requirements using formal (e.g for scientific domains), specific, or natural languages. Then, requirements analysis can be carried out:

• Iteratively in unison with development and in collaboration with software engineers (agile approach). In that case models are not necessary as requirements are expressed in natural language (users’ stories), possibly combined with domain specific languages (DSLs) for development.
• As phased undertakings carried out independently, using a dedicated modeling language (e.g BPMN).
• As phased undertakings carried out jointly with system analysts using a general purpose modeling language (e.g UML).

These schemes are therefore best understood as tools whose employ may overlap or be combined:

• BPMN and UML activity diagrams have much in common.
• Class diagram can complement BPMN for business objects, and State diagrams for processes control.
• Use cases can be seen as describing the part of users’ stories to be supported by systems.

How BAs will employ them is to depend on business processes and projects’ objectives.

Business & Development Processes

The responsibility of BAs is about business processes, the choice of development model being left to project managers; hence the need for business analysts to be familiar with basic options:

• Agile: business analysts collaborate with software engineers in project teams and share responsibilities from requirements to delivery.
• Phased: roles and responsibilities are defined specifically with regard to development tasks.

Agile or phased, the contribution of business analysts can be defined around three core issues, corresponding to three typical modus operandi:

• Concepts associated to business objects and activities that are to be represented. Assuming that conceptual models are meant to be stable and shared across processes, they should be under the responsibility of business analysts independently of applications.
• Actors (users, devices, or systems) and activities. Insofar as the impact on organization and system functional features can be localized (users interfaces) or circumscribed (business rules), business analysts can collaborate and share responsibility with software engineers all along an iterative process. Otherwise (changes in organization or business functions) business analysts will have to consolidate their work with enterprise architects.
• Processes execution. Often labelled as non functional capabilities, they essentially deal with the different aspects of user’s experience and the synchronization of changes in business environments and supporting systems. For that purpose business analysts will have to check requirements against systems capabilities.

While these issues are often interwoven, sorting them out can help to match development models with projects objectives and scope: agile for projects facing business users, phased for the ones dealing with architectures; that will also help to characterize the role of BAs depending on focus: business processes (BPM, use cases, users’ stories), functional architecture (services, conceptual models), or quality of services.

Business Analysis & Systems Architectures

When considering business opportunities, business analysts have to define requirements’ footprint with regard to system capabilities:

• Confined: applications can be developed in collaboration with software engineers from users’ stories to code, without modeling. Assuming agile conditions about shared ownership and continuous delivery are met, that would be the default option.
• Distributed: some modeling is needed for communication and consolidation purposes. But business processes modeling languages like BPMN make no distinction between processes’ details and the shared features of supporting systems. That puts a challenging toll on business analysts (complexity, ambiguity) with limited benefits (no easy mapping to system functions).

A primary concern for business analysts should therefore to frame projects accordingly: self-contained and business driven on one hand, shared and architecture driven on the other hand, with use cases set in between if and when necessary. For that purpose shared concerns will have to be clearly identified; taking BPMN for example:

• Containers for physical (locations) and logical (organizations and domains) objects have no BPMN explicit equivalents.
• Active objects have no BPMN explicit equivalent.
• Swimlanes and pool tally with roles (aka actors)
• Data stores tally with entities (persistent representation of business objects).
• Tasks, transactions, and sub-processes can be translated as activities description and processes execution.

Given backbones shared with enterprise architects, the next step is to flesh them out with specific details. Depending on methods and tools, that can be done using a domain specific language (DSL) with direct implementation, or through a generic subset of BPMN that could be unambiguously mapped to design constructs, for instance:

• Anchors (#): instances (objects or activities) directly and consistently identified across businesses and system.
• Collections (*): set of individuals with shared features.
• Features: attributes or operations without identity of their own.
• Structures (diamond): composition (black) for individual components (objects or activities) whose life-cycle is bound to their owner, i.e they have no identity of their own; aggregation (white) for components identified independently but used in the context of their owner.
• Connectors: associate individuals; their semantics is set by context: communication channel, reference, data or control flow, transition. They can bear identification (#).
• Power-types (2): define subsets of individuals objects or activities. Depending on context and modeling language, power-types correspond to classifications, extension points, gateways, branch and joins, etc.
• Inheritance (triangle): contrary to structure and functional connectors that deal with instances, inheritance connectors are used to describe relationships between descriptors. Strong inheritance (black) is the counterpart of composition (inheritance of structural features), and weak inheritance (white) the counterpart of aggregation (inheritance functional features).

Using the same set of well accepted and unambiguous logical constructs for both objects and behaviors can greatly enhance the consistency of analysis models as well as their traceability to designs.

Business Analysis & Knowledge Management

As noted above, while business analysts may have to consolidate functional requirements or check the feasibility of non functional ones with enterprise architects, they should take responsibility for conceptual models, and more generally for enterprise knowledge architecture. Taking a leaf from Davis, Shrobe, and Szolovits, that will cover:

1. Surrogates: description of symbolic counterparts (aka) of actual objects, events and relationships.
2. Ontological commitments: statements about the categories of things that may exist in the domain under consideration.
3. Fragmentary theory of intelligent reasoning: model of what the things can do or can be done with.
4. Medium for efficient computation: knowledge understandable by computers.
5. Medium for human expression: communication between specific domain experts on one hand, generic knowledge managers on the other hand.

Putting apart users interfaces (point 5), two typical approaches can be considered:

• Domain Driven Design (DDD), which deals with domains representation and computation from a system perspective (point 4).
• Ontologies, which put the focus on knowledge oriented languages independently of computation (points 1-3).

Besides their simplex orientation, both fall short of business analysts needs, the former being too technical, the latter too open-ended. Instead, a conceptual framework should combine bounded domains with a compact and unambiguous knowledge oriented language.

As it happens, mapping the symbolic footprint of business domains and knowledge into systems may be dictated by the generalization of networked environments and digital business flows. Along that reasoning, BAs will have to deal with knowledge from domains as well process perspectives.

With regard to domains, a distinction should be maintained between institutional (external, statutory), business specific (external, agreed), and enterprise specific (internal).

With regard to processes, knowledge must be understood as the dynamic and multi-faceted outcome of data analytics, production systems, and decision-making. Taking a (revised) leaf of Zachman’s framework, business and operational objectives would be reset as to cross architecture layers instead of being aligned. Using a pentagonal representation of enterprise architecture, Zachman’s sixth column (“Why” ) would be rounded as an outer range.

Along that perspective embedding IT systems in business processes is to become a key success factor, which is to bring business intelligence up on the list of business analysts’ concerns.

Business Intelligence

If business intelligence is to take into account the ubiquity of digitized business processes and the integration of enterprises with their environments, a seamless integration of data analytics and decision-making is to be a primary concern for BAs.

Data analytics (sometimes known as data mining) is best understood as a refining activity whose purpose is to process raw data into meaningful information:

• Data understanding gives form and semantics to raw material.
• Business understanding charts business contexts and concerns in terms of objects and processes descriptions.
• Modeling consolidates data and business understanding into descriptive, predictive, or operational models.
• Evaluation assesses and improves accuracy and effectiveness with regard to objectives and decision-making.

Decision-making processes in open and digitized environment are best described with the well established OODA (Observation, Orientation, Decision, Action) loop:

1. Observation: understanding of changes in business environments (aka territories).
2. Orientation: assessment of the reliability and shelf-life of pertaining information (aka maps) with regard to current positions and operations.
3. Decision: weighting of options with regard to enterprise capabilities and broader objectives.
4. Action: carrying out of decisions within the relevant time-frame.

The integration of data analytics and decision-making would be a key benefit of enterprise architecture.

On a broader perspective data analytics and decision-making can be seen as the front-offices of business intelligence, and  knowledge management as its back-office. That organization can be reinforced with ontologies set with regard to governance and stability of contexts:

• Institutional: Regulatory authority, steady, changes subject to established procedures.
• Professional: Agreed upon between parties, steady, changes subject to accords.
• Corporate: Defined by enterprises, changes subject to internal decision-making.
• Social: Defined by usage, volatile, continuous and informal changes.
• Personal: Customary, defined by named individuals (e.g research paper).

Ontologies set along that taxonomy of contexts could also be refined as to be aligned with enterprise architecture layers: enterprise, systems, platforms, e.g:

Crossing business taxonomies with enterprise architecture capabilities could significantly improve the integration of business processes and supporting systems.

Governance: Metrics, Quality, & Risks

As gate-keepers, business analysts have to rank projects with regard to business value, risks, and return on investment. Assuming that business value is set independently of supporting systems, projects’ assessment and ranking should be set according to the nature of problems:

• Intrinsic business size and complexity: requirements can be estimated from individuals (objects and activities), features, relationships, and partitions.
• Supporting systems functionalities: intrinsic business metrics are to be combined with what is expected from supporting systems: processes and transactions, triggering events, users and devices interfaces, etc.
• Business and functional measurements can then be weighted by non-functional (aka Quality of Service) requirements.

If returns on investment (ROI) and risks are to be assessed consistently and decision-making carried out accordingly, value, costs, quality, and hazards have to be set within the same framework, in particular for quality and risks management:

• Business environment: risks are external and quality is to check for timely and relevant analysis models.
• Engineering:  risks are internal and quality is to focus on processes maturity.
• Technologies: risks are external and quality is to address versatility, plasticity, and effectiveness of solutions.

To conclude, whereas business risks remain the primary concern of business analysts, the fusion of business and systems processes means that they can no longer ignore engineering pitfalls and the importance of quality for risks management.

Further Reading

• Focus: Enterprise Architect Booklet
• The Scope of Agile Principles
• Agile & Models
• How to Mind a Tree Story
• From Stories to Models
• Agile Business Analysis: From Wonders to Logic
• Business Stories: Stakeholders’ Plots & Users’ Narratives
• Projects as non-zero sum games
• Use Cases are Agile Tools
• Business Agility & the OODA Loop
• Business Agility vs Systems Entropy
• Capabilities vs Processes
• From Processes to Services
• EA: Maps & Territories
• EA: Work Units & Workflows
• Data Mining & Requirements Analysis