To make proper technology assumptions for your product roadmap, a product owner or business analyst is not enough. The process may get complex right after the first user story you try to debrief. In this article, we share our understanding of a Technical Architect's role and its value to the project.
Why do we need TA explicitly?
How does it differ from having a senior engineer on your team?
What are the touchpoints between business analysts and technical architects?
Continue reading, and you will understand why the collaboration between these two is crucial for successful delivery.
Understanding Business Analysis in Software Development - Part 5
This article is part 5 in a five-part series about business analysis, discovery workshops, and the preparation phase.
The key result is to influence through this practice the success of your product delivery and shorten time-to-market through informative and balanced collaboration between analysts and architects.
I bet that there are many ways to elaborate on the subject depending on one's experience, organization profile, or current project, whether it’s a product company, start-up, or software house. When writing this article I’ve decided to source mainly from my professional experiences, therefore, my take on the matter originates in my work as a business analyst (further BA) in a software house that delivers bespoke solutions to clients.
Let’s consider a technical architect (further TA) as a person who:
Understands product’s architecture, quite often even designs it. The TA is the one who validates it with the Client and propagates that knowledge to the team.
Knows most of the limitations of the technical approach and technical dependencies of the development items to act prior they become blockers or issues.
Does plenty of work ahead of the development sprint (doing spikes, PoCs, maintaining communication with the client’s IT department and technical leads) so the team can smoothly conduct refinement and planning sessions.
And last but not least, it’s a BA’s right hand when eliciting requirements from the Product Owner and delivering full feedback when technical limitations restrict previously assumed software design.
Indeed, a technical architect is more than just a senior software engineer. While they are certainly proficient in coding, often excelling in both front-end and back-end development, their primary value lies in their capacity to communicate effectively with clients and teams, establish trust, and foster relationships. They leverage their expertise and experience to translate business requirements into system architecture designs, which serves as the foundation for their decision-making.
There are several touchpoints between the BA and the TA. Let's start from the beginning. The technical architect may potentially work with the business analyst at every stage of the project. I have organized the project phases below, writing about how business analysts and technical architects collaborate using my professional experience.
During the phase led by the business developer, also known as the sales representative, the TA can contribute additional value that potential customers will appreciate. While the business analyst provides a high-level initial overview of the product, its requirements, and risks at this stage, the TA can start suggesting technology solutions, conducting research, or identifying suitable existing components. This collaboration can result in added value by offering clients a more comprehensive analysis and demonstrating understanding and commitment at the outset of the sales process.
2. Discovery workshops
When running workshops, a business analyst is commonly the central figure in the picture. It’s their responsibility to plan the schedule, propose exercises, and ask the right questions. Whereas the BA will be asking about business goals, the TA will be processing the answers in the context of technical solutions. Just to give an example, when designing a mobile fitness tracker the BA may ask:
When the answer to both questions is YES, it provides the BA with an opportunity to delve deeper into the perspective and explore functional requirements related to integrating third-party accessories and tracking various sports types through GPS. On the other hand, the TA can deduce from this conversation that a cross-platform framework like React Native or Xamarin might not be suitable for this solution. The app will likely require background access to Bluetooth communication and GPS sensors while efficiently managing battery usage. This lays the groundwork for identifying OS platforms and establishing priorities in addressing them. Many other assumptions and questions may arise, which a skilled TA reading this article could generate spontaneously.
Below you can find an example of the three-day workshop plan to identify both client and customers’ values. The expected result of that workshop is to shortlist the most important features.
Starting as early as day two, there is a recommendation for the TA to actively participate in the workshop. This is because the BA-TA partnership can significantly enhance the workshop's outcomes. Often, the TA will identify the need for an API interface, integration with external systems, handling legacy data, or even conducting research on new technologies. The TA's responsibility includes delving into details where the BA may lack expertise and offering a perspective that enhances the precision of estimates. One good practice for estimating a project is to validate the need for discovered processes and confirm expectations with the client at every stage before and during the project. Even before the discovery workshop, it's possible to provide a Rough Order of Magnitude estimate.
For bigger projects, once we collect more information or go through the workshops, we tend to create product backlog estimates of User Stories in story points. It’s best to perform task breakdown and hourly forecast these stories which will later go into the whole scope. When a project is so small that even introducing the Scrum framework seems like overkill it can be useful to choose a fast and cheap estimation technique as a simple hourly estimate with taxes for every other activity, such as testing or code review.
At that stage, the TA becomes a technical leader of the software development team. It’s when the BA should stay in the shadow and prepare for upcoming sprints, and the TA should shine. Sprint 0 needs a thoroughly thought plan and execution that creates the foundation for seamless work in the future. The TA who was working closely with the client and the BA from the very beginning will have all the pieces and will know well what needs to be done.
Need a professional technical architect? Give us a call!
In everyday work, the technical architect is the right hand for the business analyst. I value this cooperation the most when I have a draft of acceptance criteria written down in user stories.
User Story: Forgot password
As a Client, I want to have the ability to set a new password so that I can access the system when I forgot it.
1. A User has access to “Forgot password” functionality from the log-in page.
2. On the “Forgot password” page, the user can input the email address used as a login to the system.
3. If an email doesn’t exist in the users’ database system displays “incorrect email” notification
4. User can trigger change password functionality by clicking the “Send reset link” button.
5. When the action was triggered user receives an email with a unique link allowing to reset the password
6. When the user clicks the link, he/she navigates to the page containing the following components:
a) Textbox: New password
b) Textbox: Re-enter new password
c) Button: change password
7. User can type-in a new password.
8. When passwords don't match the validation message is displayed.
9. When the password doesn’t meet the complexity criteria validation message is displayed.
10. When the password was typed in and repeated correctly, the user can confirm the change by clicking “change password” button.
11. When the user has changed the password, success information is displayed.
On the higher level, the TA also helps me understand dependencies between backlog items and identifies which stories qualify for research, spikes, or even a short Proof of Concept before they can feed the refinement sessions.
Below you can see an example of epics and user stories being considered as a backlog for the online store project.
The TA is the one who runs those activities, documents outcomes to help the BA better understand the product, and helps the team with valuable input needed when working on the tasks. The technical architect also participates in meetings with clients' Product Owners to explain the technical aspects of the solution.
There are multiple cases when a complex project involves the IT department and technical leaders from the client side. The TA takes charge of handling communication and working out solutions that will allow the product to fit into the client’s existing infrastructure and solution portfolio from a technical point of view. Those are the areas where the Business Analyst doesn’t often have the expertise and defining specific business or functional requirements needs a TA’s support. To support the project, the technical architect should create respective diagrams and even describe developers’ guidelines. These will help craft the code that accommodates specific technical requirements.
Before the development phase, the BA works with every user story to make sure that it covers all the details needed. In most cases, team members will challenge the assumptions of the user story during the refinement session. They will share doubts which will be discussed later with the client. As mentioned above, the TA who actively collaborates with the BA knows the stories’ scope before refinement. In addition to running spikes and PoC, they can also take off team's shoulders some of the investigation work needed to plan stories for the upcoming sprint while they are involved in delivering the current sprint’s goal.
*Example of the Sprint backlog*
Sprint goal: Assure secure access to the system
User stories:
1. Log-in functionality
2. Log-out functionality
3. Change password
4. Reset forgotten password
5. Session time-out and automatic log-out
6. Two-factor authentication
It is a perfect situation when all user stories in the sprint jointly create a piece of functionality to link it later as a sprint goal. The sprint goal becomes a narrative for the whole work and shows direction when team members hesitate to prioritize tasks.
So there it is. From my experience, the more complex the project and the more sophisticated setup is at our Client’s organization, the immense value comes from the TA’s presence and their cooperation with the business analyst. The technical architect is a vital role, and I can boldly state that my work becomes way more effective when I have such a professional acting hand to hand by my side.
.jpg)