5 shared process improvement challenges for business analysts and solution architects

A process change can look settled long before it’s understood.

The business analyst may leave a workshop with stakeholder notes and a first view of the operating problem. The solution architect may leave with a list of systems, integrations, and technical constraints. Operations may believe the discussion captured only part of the work they actually do. Each perspective can be reasonable, but together they can still provide a weak basis for change.

This is why the usual list of role challenges—unclear requirements, stakeholder management, and poor communication—doesn’t go far enough. Process knowledge changes shape as a project moves forward. It begins as discussion and evidence, is organized during discovery, becomes structured process logic, informs requirements and design decisions, and is tested before implementation. Meaning can disappear at every handoff.

Business analysts and solution architects have different but connected responsibilities in that chain. Both depend on a shared understanding of how work happens now, what needs to change, and what that change may affect.

Why process-centered projects challenge both roles

Business analysts usually focus on needs, processes, stakeholders, rules, and requirements. Solution architects use agreed business needs and constraints to shape feasible technical designs.

The International Institute of Business Analysis distinguishes a requirement, which represents a need, from a design, which represents a possible solution. Meanwhile, Microsoft's guidance for solution architects connects business alignment with technical design, collaboration, documented decisions, and assumption validation.

The overlap becomes most visible in process-heavy transformation and system implementation projects. Not every solution architect needs to model business processes. However, process context becomes important when a proposed solution changes approvals, handoffs, decisions, data exchange, customer journeys, or operational responsibilities.

Where the roles differ and overlap

Exact responsibilities vary by organization and project. Still, the following comparison shows why both roles need a dependable view of the process.

Both roles therefore depend on reliable information about outcomes, responsibilities, decisions, exceptions, and dependencies.

A shared process model can give them a structured reference point for those conversations. It can show activities, roles, events, decisions, data, systems, and exceptions. However, it doesn’t replace requirements documents, architecture diagrams, or architecture decision records. Its value lies in helping both roles examine how business needs connect to operational work and technical change.

This article focuses on five challenges within that shared process layer. It doesn’t cover every challenge faced by either profession. Solution architects also address security, scalability, integration, and other technical concerns. Business analysts may manage stakeholder priorities, organizational change, and broader requirements work.

The five shared process improvement challenges are:

1. Reconstructing a reliable as-is process from fragmented knowledge.
2. Preserving discovery context on whiteboards.
3. Turning business needs into process logic that informs requirements and solution design.
4. Keeping the shared process model aligned as decisions evolve.
5. Testing future-state, or to-be, process assumptions before implementation.

To make these challenges concrete, we will return to the CRM implementation and sales-process redesign described in our article about reducing IT development costs by modeling processes first. The account contrasts a failed CRM rollout with a separate project that used process models and a formal system requirements specification before acquiring and adapting a new CRM system.

The sales-quoting redesign provides the recurring example. Where the source doesn’t describe a specific role or activity, the sections below identify the interpretation or frame it as a possible extension.

Challenge 1: Reconstructing a reliable as-is process from fragmented knowledge

An accurate as-is process rarely comes from one interview. Business analysts and solution architects depend on a reliable account assembled from process owners, frontline employees, system records, and policies. They may lead or contribute to that discovery depending on the project.

No stakeholder sees the process from every angle. People usually describe the part they know best, and experienced employees may skip steps that feel obvious to them.

In the published sales-quoting case, a potential customer sent a request directly to one salesperson. Nobody else knew that the request existed. The quote could then be delayed if that person was too busy, absent, or no longer employed by the company.

Each account can be accurate yet incomplete. The challenge is to combine these perspectives without smoothing over meaningful differences.

Treat conflicting accounts as evidence

For a business analyst, missing knowledge can hide:

• Unofficial workarounds.
• Rework loops and exception paths.
• Unclear ownership.
• Business rules that exist only in people's experience.
• Differences between policy and actual practice.

For a solution architect, the same gaps can hide:

• Manual system handoffs.
• Integration and data dependencies.
• Security or approval checks.
• Volume and timing constraints.
• External services or legacy systems.

A simplified account of the as-is process can create false confidence. The team may design the future process around assumptions rather than complete evidence.

If two stakeholders describe the same handoff differently, the team shouldn’t hide that disagreement. The process may vary by case, or important details may remain unverified. A structured discovery routine can help:

1. Define the process trigger, expected outcome, owner, and boundaries.
2. Include every role that performs, reviews, approves, or receives work.
3. Examine the normal flow, exceptions, workarounds, and rework loops.
4. Compare stakeholder accounts with procedures, system data, records, and direct observation where available.
5. Investigate conflicting descriptions instead of forcing them into one version.
6. Validate the emerging process view with people who perform the work.

That last step matters. Managers can explain the intended process, while frontline employees can confirm how the work actually happens.

At this stage, the goal is to establish a reliable account of the current process, including variations, conflicting descriptions, and missing evidence. Its accuracy depends on who participates and the evidence they bring.

Challenge 2: Preserving discovery context on whiteboards

Once business analysts and solution architects have gathered and assessed evidence with process owners and subject-matter experts, they must preserve both the findings and their context. Otherwise, notes, decisions, assumptions, and open questions may remain scattered across workshop files, messages, and personal records.

A shared whiteboard can bring these materials into one visual space without presenting every detail as settled. Business analysts can capture stakeholder needs, pain points, rules, exceptions, and evidence. Solution architects can add system touchpoints, data exchanges, technical constraints, and dependencies.

The whiteboard should clearly distinguish confirmed findings, proposed changes, and unanswered questions. Without this distinction, ideas can appear as facts, conflicting accounts may disappear, and open questions may lose their owners. Preserving that context helps both roles understand why process and technical decisions were made.

A practical way to preserve discovery context:

1. Capture the context: record the process purpose, stakeholders, pain points, evidence, and constraints.
2. Organize the findings: group notes by roles, activities, decisions, data, systems, rules, and exceptions.
3. Mark their status: separate confirmed facts, assumptions, conflicting accounts, ideas, and open questions.
4. Record decisions: note what participants agreed, why they agreed, and who approved it.
5. Assign open questions: identify who must provide the missing information before formal modeling begins.

In Cardanit, business analysts and solution architects can create a project and use sticky notes and whiteboard shapes to transfer findings from workshops, interviews, documents, or physical whiteboards into one digital space. This keeps supporting context visible while the team distinguishes confirmed evidence from proposals and open questions.

For example, participants might record, “A nonstandard quote can remain in one salesperson’s inbox,” as a confirmed problem. Creating a CRM lead or assigning requests by workload should remain labeled as improvement ideas until the relevant stakeholders approve the future flow.

A well-organized whiteboard preserves both the findings and the reasoning behind them. However, discovery material alone cannot provide the structured process logic needed for requirements and solution design.

Challenge 3: Turning business needs into process logic that informs requirements and solution design

Once the discovery findings are organized, business analysts and solution architects need confirmed business needs, decisions, constraints, and process evidence translated into structured process logic. Depending on the project, one role may create the model while the other reviews and contributes to it. This is also where the transition from whiteboards to BPMN begins.

Whiteboards support exploration, while BPMN gives agreed process logic a consistent structure. The Object Management Group’s BPMN specification defines standard meanings for activities, events, gateways, participants, and message flows.

Translate discovery findings into BPMN

Not every whiteboard note belongs in the process model. Unresolved ideas shouldn’t appear as approved process logic.

1. Review the whiteboard’s scope, evidence, decisions, and open questions.
2. Translate the validated current flow into an as-is BPMN model.
3. Create a separate future-state model using agreed process changes.
4. Keep assumptions and unresolved questions beside the relevant model.
5. Ask operational and technical stakeholders to review both views.

In the sales-quoting example, the future-state model can show the agreed redesign: the website receives the request, standard quotes follow an automatic route, and nonstandard requests create CRM leads. Questions about missing data, failed transfers, or overdue work can remain visible until stakeholders resolve them.

Cardanit combines digital whiteboarding with BPMN modeling in the same project. Once it’s confirmed which findings represent agreed process logic, users can translate them into BPMN activities, events, gateways, participants, and message flows. Supporting notes and annotations can remain beside the diagram without becoming part of the formal model.

Use BPMN to clarify requirements and solution decisions

A process model doesn’t turn a business request into complete system requirements. Instead, it exposes sequence, ownership, data needs, rules, interactions, and exceptions that requirement lists can overlook.

In the sales-quoting case, reducing delays and missed opportunities requires more than a general business goal. The team must define classification rules, required data, assignment logic, response targets, and status exchanges.

The answers affect both formal requirements and technical design. For example, “The website must create a CRM lead for every nonstandard quote request” doesn’t cover timing, missing fields, duplicate requests, failed transfers, or human intervention. BPMN places the requirement within the surrounding process, making these gaps easier to identify.

The same process detail can raise different questions for each role:

The BPMN model helps business analysts identify what formal requirements must cover. Meanwhile, it gives solution architects the context needed to assess interfaces, controls, constraints, and technical decisions. Supporting descriptions and comments can remain beside the model, while detailed business rules and decision logic can be modeled separately with DMN.

However, the process model shouldn’t become the single source of truth for every project artifact. It provides a shared view of the process, while requirements tools track granular details such as identifiers, ownership, status, and traceability.

Architecture records document design rationale, alternatives, and consequences. The process model informs and connects these artifacts; it does not replace them.

Challenge 4: Keeping the shared process model aligned as decisions evolve

A process model loses value when requirements, technical constraints, or operational findings change while outdated exports remain in circulation. Stakeholders may then make decisions using different versions of the process.

As the redesigned sales process is refined, the business might change what qualifies for a standard quote or shorten its response target. The business analyst would need to assess the change and ensure that the process logic and related requirements are updated. The solution architect would then assess the effects on website rules, CRM lead creation, workload-based assignment, reminders, and capacity.

Both roles need a current process view. Process-model history should show meaningful changes, while related requirements and architecture records must remain aligned.

A lightweight process-model governance routine can keep that shared artifact useful:

1. Assign a process owner and define when the model needs review.
2. Record the model's purpose, scope, assumptions, and effective date.
3. Review the shared model before an important design or release decision.
4. Save a version at meaningful decision points.
5. Update linked requirement and architecture records after process changes.
6. Label or archive old exports so nobody treats them as current.

Features such as automatic saving, named versions, restoration, and shared editing support process-level continuity. Business analysts, solution architects, and other authorized contributors can preserve a model before a significant change. They can then return to that state when needed.

However, technology alone cannot keep a model relevant. A defined owner and review routine ensure that the shared process view evolves with the decisions it represents.

Challenge 5: Testing future-state process assumptions before implementation

Even a current, agreed BPMN model cannot show how a future process may perform under different volumes, durations, resources, or routing choices.

To examine those performance questions, teams can use process simulation. The distinction between BPMN modeling and process simulation matters:

A systematic review of business process simulation research describes simulation as quantitative process analysis that supports process improvement.

What BPSim adds to a BPMN model

BPSim adds process-analysis parameters to a BPMN model, including workload or arrival patterns, processing times, resources, calendars, routing probabilities, and costs. Business analysts can use these parameters to test assumptions about future process performance.

The published CRM article closes by asking how someone can identify process inefficiencies without relying only on experience or intuition. It suggests data analysis or simulation as a stronger next step. For the redesigned sales process, this raises questions such as:

• How do quote volume and request type affect waiting and completion times?
• What happens when fewer salespeople are available?
• Do alternative assignment and routing rules reduce delays and resource use?
• How do different reassignment or escalation rules affect waiting and completion times?

However, simulation doesn’t validate security, code, integrations, or scalability. These areas may still require prototypes, load tests, or proofs of concept.

Compare scenarios one change at a time

A controlled comparison makes the results easier to interpret:

1. Confirm the baseline and proposed BPMN models.
2. Define baseline parameters, their sources, and uncertain assumptions.
3. Create the to-be scenario you want to evaluate.
4. Change one main variable and compare time, waiting, cost, resource use, and bottlenecks.
5. Test uncertain inputs using alternative values.
6. Document the decision, limitations, and next validation step.

Cardanit process simulation applies BPSim parameters directly to BPMN models. It presents scenario results through tables and visualizations, keeping the assumptions connected to the process under evaluation. Cardanit's simulation documentation explains how to configure and analyze these elements.

A business analyst could compare the original direct-email process with the redesigned website-and-CRM flow. A solution architect could then use the results to identify which CRM configurations, integrations, or automation options require further technical validation.

Simulation doesn’t predict the future with certainty. Its value depends on the process model, input data, and documented assumptions. However, it helps both roles compare possible outcomes before real-world implementation.

Using the five challenges as a diagnostic

The five challenges can also help business analysts and solution architects identify where their shared process work breaks down.

Use the table below to identify the next gap to address. It offers a starting point for diagnosis but doesn’t replace the detailed analysis above.

These gaps are closely connected. Weak discovery can produce an incomplete starting point. Lost workshop context can then weaken the process logic used to discuss requirements and solution decisions. Meanwhile, model drift can disconnect later decisions from their original assumptions.

Therefore, business analysts and solution architects should begin with the earliest unresolved gap, not necessarily the most advanced modeling or simulation capability.

Don't ask a diagram to do every job

A BPMN model can make a process visible, but it cannot resolve every assumption, reveal every operational constraint, or prove how a future-state process will perform.

Business analysts and solution architects bring different perspectives to these gaps. However, they make better decisions when discovery context, structured process logic, requirements, design decisions, and scenario evaluation remain connected. The process model can then serve as a shared reference for what the business needs, how work should change, and which questions still require evidence.

When business analysts, solution architects, and process stakeholders need one environment to connect these activities, Cardanit is process improvement software that combines visual whiteboarding, BPMN process modeling, collaboration, model history, and BPSim-based simulation. It supports this connected process work without replacing the requirements, architecture, or technical validation practices each project still needs.

Explore how Cardanit supports process modeling or start testing process scenarios with simulation.