Why Architects Need to Understand Business Analysis Tools and Techniques

Salesforce is now a strategic application in the IT landscape. Salesforce’s vision of Customer 360 is becoming a reality in organization after organization. A key aspect of that vision is that customer data is available to different upstream systems (including marketing systems, websites, self-service portals, and communities) as well as downstream systems (including CPQ, ERP, and accounting systems).

Trust, speed, and relevance may be the most important currencies during a crisis. Businesses must adapt quickly and leverage technology to gain a competitive advantage. Agility, adaptability, discipline with respect to change management, and implementation life cycles are capabilities that companies must develop to successfully compete in [the] digital economy. — Vala Afshar, Chief Digital Evangelist, Salesforce

Digital transformation exposes organizations that are not able to execute at scale. Can the back-office systems deliver on the promises made by the organization’s website or customer-facing staff? Is the organization agile enough to rapidly change business operations (people, process, and technology), whilst keeping everyone on the same page, even if that page may look different tomorrow? This level of change puts a huge strain on all areas of an organization. To facilitate rapid, large-scale change, architects must have a deep understanding of not only architecture, but also the tools and techniques used in business analysis.

Agility and execution are vital

The growing interconnectedness of systems and the need to change at pace have highlighted the need for a more holistic view of Salesforce implementations and a more rigorous development cycle. Any change — no matter how small — can have a material impact on system downtime, company reputation, and regulatory compliance. As a result, many organizations tend to resist making changes or make them slowly and carefully.

But these tendencies are at odds with the need to increase the frequency of updates. Agility is a business differentiator. If the apps that support the business are not built to change, then they cannot support the business. Organizations that can master agility and are able to execute flawlessly will dominate.

Enter the architect

The architect’s role has never been more important, but architecting Salesforce solutions can be challenging. Each Salesforce solution must be architected to make sure it meets end-user goals, scales, performs, and is secure. At the same time, each solution must be architected to enable agility. A lot of what’s needed to be successful at this extends beyond architecture, but architects are the critical link between business analysts and development teams.

Business analysts work with senior management to understand their goals — both short term and long term — and also with the end users to develop a crisp, clear understanding of their requirements. The way to validate the requirements is to document the business processes that are being streamlined and supported by new apps.

The architect is involved in the initial solution designs. This involves taking the business requirements and creating the technical specifications (including work items or user stories) that are passed to the developers. Technical specifications are related to, but distinct from, the requirements which are a business definition. Elements of the technical specification are developed with the end solution in mind, considering the data model — the entity relationship diagram (ERD) — and the impact on the org.

Shift left

It is exponentially better to discover problems at the design phase than in development, test, or worse, in production. This concept — shift left — is about finding and fixing problems earlier in the implementation lifecycle. Initially, shift left efforts were focused on the development phase, but you can shift even further left, into business analysis and design, to get even greater benefits. It is significantly easier and less costly to resolve problems, metadata change conflicts, and other issues in the analysis phase, than it is to fix them in production when you have thousands of users who are unable to use Salesforce while you are desperately troubleshooting and trying to roll back changes.

When the focus on validation and defect detection comes only late in the lifecycle, an organization’s speed of implementation may be high, but the speed to value is poor. This approach also erodes trust with end users. The resulting rework takes time, adds cost, and often garners less engagement from business users than the first round. This is a dangerous downward adoption spiral.

Many teams feel pressure to start building too quickly before the analysis is complete. A rushed design that doesn’t validate the true business need or a data model that hasn’t been architected correctly for reporting will fail to be adopted by the business. Worse yet, a change in metadata where the impact wasn’t anticipated due to insufficient analysis may break the org, resulting in system downtime and panicked roll-backs.

Documentation accelerates implementation

Architects and business analysts are allies. They need to fight to ensure that sufficient rigorous analysis is completed. The Agile revolution and low-code / no-code approaches are great advances. But they have both driven a rush to start development before enough analysis and complete user stories are developed. Agile is fantastic at scoping sprints into smaller releases that can be delivered more frequently. But Agile does not mean taking shortcuts on analysis or documentation. Similarly, low-code / no-code does not mean no-analysis / no-documentation. It means the solution can be developed more quickly, and declaratively.

Even with Agile and low-code / no-code approaches, the business analysis mantra should be “build the right thing” before the development phase mantra of “build it right”. To accelerate the implementation lifecycle repeatedly, organizations are standardizing documentation and using DevOps tooling and technology to automate wherever possible.

The 3 Cs of documentation

Too often, documentation is viewed as slowing implementation. And that may be true if you think of the huge, wordy Business Requirements Documents (BRD) developed in waterfall-style implementations that are thrown away after the project is delivered.

Documentation in this new Agile, low-code / no-code world is different. It needs to be reusable because implementations are iterative. Constant changes building on previous changes are driven by the changing demands of the business.

In the last 12 months in Elements.cloud we have created over 1,000 user stories and delivered 77 releases with zero roll-backs. Salesforce (and integrated systems) change at the pace of the business and that drives up agility. It also drives up the business’ trust in IT to deliver results. — Jack Lavous, Business Excellence Manager, Elements.cloud

The single, huge BRD is gone. Instead, documentation is driven by three Cs: a combination of different forms of content, connected to each other to provide valuable insights and delivered in the context of the different audiences using it, including business analysts, architects, admins, developers, end users, and regulatory auditors.

Documentation grows over time. It captures the institutional knowledge of the configuration of the business and supporting systems. It reduces technical debt because it accelerates impact assessment of future changes. And, while it may feel that documentation slows the initial implementation (actually it doesn’t), documentation also dramatically accelerates future changes. The following ERD shows the interconnections between the different types of business analysis content, with the connections and the context, or audiences.

Note: This diagram (created using the Salesforce diagramming framework) does not include other architecture documentation that is part of Salesforce diagram standards such as System Landscape, Integration Layer, and User Provisioning and Deprovisioning Flow diagrams.

The elements of this diagram are:

• Goals, Feedback, Change Initiatives. These are the drivers of change. They can be strategic (“we need to implement Einstein”) or tactical (“we need a new picklist item”).
• Requirements. These describe the Goals, Feedback, Change Initiatives as discrete business requirements that the business users can agree to. These are also used in user acceptance testing (UAT).
• Business process maps. The way to validate requirements is to engage business users in workshops to map the business processes that are being streamlined and supported by new apps. This is a hierarchical structure of diagrams using the Universal Process Notation (UPN) standard that is endorsed by Salesforce.
• Systems metadata. The metadata dictionaries of the Salesforce orgs (Prod and Sandboxes) are kept up to date by nightly sync using the APIs. The automated analysis of the metadata gives impact, dependencies, and field population plus automated documentation. It can also include future metadata items identified in the design.
• ERD/data model. These are subsets of the full data model that cover the scope of the solution. An ERD of all objects would be overly complex and does not aid the design.
• User stories. This element is the technical definition of the work to be delivered (often called a work item). It is the key hand-off document to the developers, so it is connected to all the other metadata types to provide as much context and information as possible.

The hidden benefits of documentation

There is a strong case for great documentation to ensure that developers build the right thing; documentation leads to reduced rework, faster implementation, and better user adoption. But there is another benefit: When future changes are made to metadata items the links to the other documentation make it faster and easier to perform the impact assessment. For very little additional effort (that is, simply linking documents together) you build up institutional knowledge, reduce technical debt, and make every subsequent change faster and less risky to implement.

This is why we say this approach “accelerates time to value”.

Final word

Because Salesforce is now such a strategic part of the IT landscape, it must be agile. You must be able to make changes at pace, and you have to be able to make those changes with confidence that they will not break the org.

To do this you need rigorous business analysis and design, ensuring complete user stories are passed to developers. Business analysts and architects are allies and have a shared responsibility to create unambiguous documentation that is interconnected. This documentation not only forms the growing institutional knowledge of the business and Salesforce configuration, it also reduces the time to assess the impact of changes and reduces technical debt.

There is a clear business case for better analysis, earlier in the implementation life cycle, and architects have a pivotal role in this shift left approach.