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 role and its value to the project.
Why do we need TA explicitly?
How does it differ from having a senior engineer in 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 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, organisation 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.
As mentioned above, a technical architect is not just another senior software engineer. Sure, they can code. And they usually code well, preferably both front-end and back-end which can come in hand to challenge the team’s estimations. What matters most is their ability to communicate with the client and the team, build trust, and develop relationships through their expertise and experience in transferring business requirements into system architecture design that backs up their decisions.
There are several touchpoints between the BA and the TA. Let's start from the beginning. The technical architect might potentially work with the business analyst at every stage of the project. I have organised the project phases below writing how business analysts and technical architects collaborate using my professional experience.
While the business developer aka sales representative leads the phase, the TA can bring more value to the picture that will be appreciated by potential customers. The business analyst at that stage shares his/her high-level initial overview of the product, and it’s requirements and risks. In contrast, the TA can already begin proposing technology, researching solutions or identifying where ready components can fit in. That cooperation can lead to leverage by giving the clients more in-depth analysis and proving understanding and engagement at the beginning 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 mobile fitness tracker the BA may ask:
When the answer to both questions is YES, it gives the BA an area to deepen the perspective and dig into functional requirements in terms of 3rd party accessories integration and sports types we should track through GPS. On the other hand, what the TA will source from this conversation is that a cross-platform framework such as React Native or Xamarin might not be right for this solution. The app will probably need access to Bluetooth communication and GPS sensor in the background while taking care of battery use at the same time. That is a foundation to discover OS platforms and priorities on approaching them. Probably many other assumptions and questions could arise when a skilled TA reading this article could form from the top of their head.
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.
Already from day two, there is a recommendation for the TA to participate in the workshop. That is so, as there are plenty of aspects where BA-TA duo will significantly improve the workshop outcome. Often the TA will discover a need for an API interface, external system integration, legacy data or even brand new technology research.
The TA is responsible for digging into details where the BA doesn’t have competencies and providing such a perspective, which will support an estimate’s precision. One good practice to estimate the project is to validate with the Client at every stage before and during the project need for discovered process and confirm expectations. Even before the discovery workshop, it is possible to deliver 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 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, 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 Owner to explain 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 need 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 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 discuss 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 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 prioritise tasks.
So there it is. From my experience, the more complex the project and the more sophisticated setup is at our Client’s organisation, 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.
-cropped.png)
.jpg)