Business Analysts
Many business analysts spend most of their time in meetings documenting business requirements, explaining what they mean to developers, waiting for weeks and then figuring out why the implementation didn’t match the documentation, rinse and repeat endlessly! The job is often a series of iterations of user experience wireframes, record state transition diagrams, business process swim lane diagrams, and many other methods/diagraming/documentation tools.
Getting consensus on the business requirements may take several meetings with many different stakeholders as we iterate to a set of first drafts or mock-ups that we can ask the developers to build. When our stakeholders see the initial builds, we begin the process again because after they see a working application, the next round of requirements emerges. The developers now have to rework/refactor their initial build, so they aren’t happy. The project manager is facing another iteration of tasks and costs so they aren’t happy. The business stakeholders didn’t get what they asked for first time so they aren’t happy either! In fact, the average development team spends between 20 – 40% of their time refactoring code.
One of the main reasons that it takes so long to get consensus on business requirements is that most people think better when they have a working application to interact with. There are many factors that contribute to this challenge, including a gap in understanding implicit requirements, silent stakeholders, and incomplete functional and non-functional requirements.
One way of measuring the efficiency of the application development lifecycle process is to measure the time from the requirements discovery meeting to when the working prototype is available, and then the number of iterations required to get to a working application.
It’s not just the effort and cost of the business analyst in this continuous cycle. We also have to factor in the effort and cost of all of the stakeholders involved in the meetings and review process and the wasted effort and cost of the developers building prototypes that are incomplete or failed to achieve the business objective.
How can we increase the efficiency of business analysis?
We need to do two things: reduce the time to interact with a working implementation of the business requirements, and reduce the number of iterations. Fortunately, a good approach for reducing the first also directly reduces the second.
Most of the business requirements for a typical application relate to the movement of data between a user’s screen (the rendering of the application user experience (UX)) and data storage (Create, Read, Update, and Delete data (CRUD)). Analysis of many software applications shows that most (>90%) of the code is directly related to UX and CRUD functionality.
If business analysts can quickly gather the UX and CRUD requirements as configuration data, then we eliminate the time taken to both document the requirements and wait for the developers to build an initial prototype. In other words, we can have the business analyst configure the desired user experience without requiring a developer to write any code. This process “short circuits” the cycle of having a business analyst mock-up a prototype of a desired user experience and then hand it over to a developer to actually build the application. If the business analyst can configure the user experience as quickly as creating a mock-up, then we eliminate the development effort and significantly shorten our build. In addition, by using a requirements virtualization platform, we have eliminated over 90% of the code in a typical application. This makes the finished solution much easier to change in the future and permanently eliminates the cost and effort to refactor code.
The requirements configuration data will need to encompass: the defined user experience (e.g. form definitions, field definitions, data model, navigation and search, styles and color scheme, header and footer details); the record’s state transitions (e.g. “draft”, “submitted”, “closed”, or other record lifecycle); and the user’s role (e.g. admin, customer, supplier, etc.). To render the application user experience, the requirements configuration data is interpreted using a dynamic page builder to generate a working application.
Using this approach, a business analyst can change the user experience requirements during a workshop with stakeholders and then instantly demonstrate a working application to validate. The stakeholders being able to quickly interact with a working model of the business requirements both improves the quality of the requirements and reduces the time required to obtain consensus.
What about the other remaining 10% of the application? Workflow automation requirements will still need to be captured and passed on to the development team for implementation. Since the rest of the user experience has been configured, we can direct the developer to the exact place in the user experience that the workflow is invoked. This helps simplify our workflow automation requirements to focus on the specific result the workflow needs to complete.
As we continue to see the adoption of AI to augment the generation of code, it may even be possible to use natural language to create and deploy workflow automation services.
Software Developers
Many organizations are facing the challenge of how to get more productivity out of their existing IT staff – especially on the development side.
We can address this need as a step change rather than looking for a 5-10% lift. Using a requirements virtualization platform, we can change the role and responsibilities of the developer to fundamentally impact both the productivity and quality of their work.
The best way of improving developer productivity is to address the causes of what is making them unproductive in the first place.
A recent survey stated: the average developer spends more than 17 hours a week dealing with maintenance issues, such as debugging and refactoring. In addition, they spend approximately four hours a week on “bad code”.
When the developers were asked what makes them unproductive, the majority stated: “maintenance of legacy systems” and “technical debt”.
How can we refocus our developers to improve productivity?
Let’s start by reducing the amount of software our developers need to build, test, and maintain. The primary task of most of our applications is to move data between a user’s screen (UX) and underlying database (CRUD). When we analyze many forms-based applications, most (>90%) of the code is directly related to UX and CRUD functionality. If we can virtualize UX and CRUD requirements into configuration data, we can eliminate all of this code and significantly reduce the need for building the application at all. In many cases, virtualized UX and CRUD requirements calling into microservices to implement workflow functionality will eliminate the need for the application.
Adopting a requirements virtualization platform approach means that non-technical resources (e.g. Business Analysts or Citizen Developers) can be responsible for configuring the user experience which both improves the quality of the deliverable as well as taking a load off the developers.
If we have eliminated the UX and CRUD code, then we have also eliminated a major source of technical debt. As the business requirements change, modifying the associated UX and CRUD functionality is simplified to updating the requirements configuration data. Changing the configuration can be done quickly and with minimal cost and risk. Changes to workflow automation functionality are isolated to loosely coupled microservices – which also significantly reduces the time, cost, and risk of making changes.
By virtualizing requirements, we have also eliminated the dependency between the business requirements and the technology used to implement it. This means that our business requirements no longer needs to be reimplemented because our technology has reached “end of life”, or has been superseded by a new technology.
As we apply the requirements virtualization platform approach to more of our applications, we will reduce the complexity of our enterprise architecture. This reduces our overall sustainment costs and improves our security posture.
Merging of Business Analyst and Software Developer roles
Recent technology trends in SaaS and AI are enabling business analysts to deliver business solutions without the involvement of developers.
We are seeing posts on developer groups talking about adding value through activities that are typically performed by business analysts.
This is the start of a role change that will likely see the convergence of the developer and business analyst roles over the next 5-10 years.
This has happened before, back in the late 1900’s there used to be distinct roles for software designer and programmer that ultimately converged into developers.
Business analysts already have the required soft skills, but will need to become more familiar with AI to generate the code fragments required to customize UX and CRUD produced through requirements virtualization platforms and SaaS applications.
Developers have a bigger task – they need to develop the soft skills of business analysts: communication, negotiation, facilitation, consensus building, prioritization, data visualization, domain knowledge, decision-making, etc. They need to be able to understand how to generate and validate business requirements from diverse groups of business users.
Developers at the start of their careers need to be thinking 30-40 years out. It’s not so much about whether we are an expert in React, Angular, Blazor, etc. These technologies come and go. They become mainstream and sink into the background – one year they command high salaries, then the opportunities start to dry up and compensation falls.
Software Testers
To fundamentally impact the productivity of software testers, we need a step-change in their roles and responsibilities.
We start with the User Experience (UX) and Data (CRUD) because:
- This is where most of our application code resides, and where most of the defects are found. UX tests are brittle and often need to be changed as requirements evolve.
- Testing UX and CRUD is often more challenging than testing the associated workflow processing. For example: it’s harder to test the UX associated with creating a customer order, than with testing the actual processing driven by the order.
Test tools for workflow processing are fairly simple to set up and automate within a CI/CD pipeline. Trying to set up automation for UX and CRUD tests is much more complex and time consuming.
At the end of each test cycle, the defects will get passed back to the development team for resolution – which may also mean that the business analysts and the business users also get dragged in. Documenting and managing this process can be a significant effort. Then add in the extra time required from developers, business analysts, and business users to resolve defects and refactor code. When a defect is fixed, we need to re-test to make sure that the resolution worked without breaking anything else! Lots of fun cycles of unit, integration, system, regression and user acceptance testing which soaks up time and effort.
How can we improve productivity?
With the same approach as developers, we can start by reducing the amount of software that needs to be tested in the first place. If we can virtualize UX and CRUD functionality into requirements configuration data, we can eliminate all of this code and significantly reduce the amount of testing required.
Adopting a requirements virtualization platform approach means that we collapse much of the defect resolution cycle. There is no code at all in the UX and CRUD, therefore, there are no defects to resolve (barring configuration errors). Software testing can be focused on higher value artifacts like workflow processing, ML/AI, analytics, and reporting.
The business analysts working directly with the business users are responsible for ensuring that the UX and CRUD requirements configuration is correct – essentially requirements to UAT in one process. Which makes it more likely that the final user experience will be closer to what the business users actually need/want. It is also more likely that the user experience can easily evolve to meet the changing needs of the business.
Where we will still need the software testers is the validation of workflow process software. These workflow units are small and loosely-coupled utilizing a common interface and implementation architecture which makes them relatively easy to build and test.
Program and Project Managers
Much of the work of a program/project manager is about facilitating the success of others: scheduling resources, maintaining budgets, resolving issues, migrating risks, and maintaining expectations. It may “sound” simple, but it can feel a lot like running uphill, on a treadmill, in a bath of treacle!
What makes the manager’s job difficult:
- Poorly understood business requirements. If we do not know what we are building, then how do we know when its done? How do we know how long it will take? What resources will we need? When will we need those resources? Failure to gather and validate requirements up front will kill the chances of successfully delivering a project.
- Availability of adequate resources. On many projects, the assigned team members will have other jobs that they also view as priorities that may impact project deliverables. Business users are a classic case in point – they have actual day jobs, but act as subject matter experts (SME) consultants on your project. They don’t always agreed with your priorities and may even have internal conflicts regarding the project.
- If we are developing requirements as the project executes, then we will have challenges as requirements evolve over time. This builds up technical debt and refactoring draining effort across all of the project team members.
- Getting estimates for deliverables from our team can be challenging and then holding them to account can be impossible – especially if the deliverable is moderately large or complex and requiring several days effort to complete.
- Issues and bugs inevitably arise as the software is developed. When we add in effects of constant evolution of requirements, it can be difficult to properly estimate the costs and timeline of the project.
- Risk management is a challenge for managers. It may be easy to identify risks like availability of resources or missing a deadline. Many of the real risks on a project are unknown because they reside in the requirements that haven’t even been uncovered, gathered, or validated.
- Managing expectations can be a real worry for many managers. The constant erosion of budget and time as things change can be challenging when reporting to senior management. Even managing expectations with the business regarding what the application will actually do can be difficult.
How can we improve productivity?
- Having a requirements virtualization platform will significantly reduce the risks and costs associated with creating a new application. Knowing how we will deploy and sustain the application eliminates many of the non-functional requirements and increases certainty.
- Configuring the application’s UX and CRUD requirements means that we can get clarity of what the application needs to do before engaging technical resources. Going from requirements gathering to UAT in business workshops – where business users can interact with the working application – helps to build a rapid consensus on what the business wants and ensures that the business expectations are both properly set and maintained as requirements change.
- Identifying workflow requirements during the business requirements validation provides more certainty about what effort will be required from the technical team enabling much better quality estimates of effort and time.
- Keeping workflow requirements loosely coupled and simple means that they can be easily shifted between team members to deal with resourcing issues.
- Many requirements changes will be purely configuration changes – as such are not a source of technical debt or refactoring.
- Risk management is also significantly simplified as many of the sources of risk have been eliminated completely and those that remain are mitigated by having clearly defined, loosely coupled deliverables.
If you would like to discuss the content and ideas raised in this blog please reach out to me: Tony@GreatIdeaz.com I’d love to talk to you!
Like to learn more?
If you would like to schedule a virtual meeting or learn more about trellispark, please contact us and provide a brief description of your interest. Or simply drop us an email at info@greatideaz.com.