From Discovery to Solution Design
Development’s D-words
The software development process has four broad stages:
Discovery and Analysis determines what an organization needs
Design decides the best way to create a high-quality solution
Development builds the solution to meet the organization’s needs
Deployment prepares users for the solution and makes it available to them
When a stage completes, it produces deliverables for the next stage. The table below defines “done” for each stage and its deliverables.
| Stage | Done When | Deliverables |
|---|---|---|
| Discovery and Analysis | Solution requirements cover the version's scope. | Requirements, process map(s), specifications such as user stories |
| Design | Stakeholders agree on major design decisions and what to build. | Models, prototypes, high-level solution decisions, architectural diagrams for complex projects |
| Development | The solution passes quality assurance and user acceptance tests. | A solution ready for deployment |
| Deployment | Users trained and confident with the solution. | Solution working as expected for users and management |
Discovery Deliverables
Business analysts lead discovery and analyze the organization’s needs, producing a variety of requirements including:
Business requirements - specific beneficial outcomes expected from the solution
Functional requirements - expected solution behavior
Process flow, best shown on process map(s)
User stories for specific cases
Data requirements
Data supporting functional requirements
Information expected by users and management
Security requirements - who can access what data
Quality requirements, primarily for reliability and performance like:
The number of users per process
Transaction rates
Percentage of time solution is available
These deliverables go to the design stage, starting with a business analyst educating an architect on the requirements.
Domain-Driven Collaboration
A business analyst and architect can manage complex business problems by breaking them down into domains based on business departments or areas of expertise. Each domain has its specific requirements.
For example, a customer relationship management solution has three domains: marketing, sales, and customer service. The table below shows the high-level business requirements for each domain.
| Domain | High-Level Business Requirements |
|---|---|
| Marketing | Run campaigns Generate leads for people indicating interest |
| Sales | Convert prospective leads to account contacts Create and close account opportunities |
| Customer Service | Resolve account cases Provide product and service information |
Domain-driven design protects data by keeping changes in exactly one context - the domain. As a rule, one domain can access data from another but shouldn’t change it. Keeping data changes in a domain reduces the risk of losing data integrity from out-of-context changes.
For example, Sales inserts new accounts, contacts, and opportunities. Customer Service accesses accounts and contacts to create new cases. Domain-driven design keeps Customer Service from changing account status, which could conflict with opportunity status.
Focusing on one domain at a time has the additional benefit of reducing the cognitive load for business analysts and architects.
Getting the Details Right
Business analysts transfer their complete understanding of requirements to architects.
They review each domain’s requirements, analyzing the process flow, ideally shown on stakeholder-reviewed process maps. They outline use cases for quality assurance to thoroughly test the solution.
Business analysts and architects collaborate on building the data model, specifying data containers such as objects and fields in Salesforce. A concept map showing the relationship of domain terms can inform the data model, but it needs additional details, such as data types and access permissions.
Architects need to know how heavily each process will use the solution. Process flow analysis gives them an idea of transaction complexity. Then, they need to know how many users will execute transactions over a period of time. For example, a solution checking in tens of thousands of attendees to an event in a matter of minutes needs a design for sub-second response time with high throughput. On the other hand, an attendee registration solution does not need nearly as much performance but must be continuously available for global attendees.
Designing the Right Solution
Business analysts and architects need thorough requirements understanding to optimize design decisions. Insufficient comprehension can lead to poor design choices. Fixing design flaws in a solution costs far more than investing time and effort to make the right design decisions based on complete, well-understood requirements.
Business analysts and solution architects develop a shared understanding of requirements, leading to a well-designed solution meeting the organization’s needs.