How to tackle challenging situations as a solution architect?

Software development is more than implementing the functional requirements based on the technical roadmap. Since development is teamwork, you need to interact with different project members.

In this blog, I will explain how to tackle challenging situations based on my experience. It doesn't mean my behaviour is the best for specific situations. I will mention different cases and how I behaved. You can review, and use it as an experience.

How to find the ideal solution within multiple teams?

While implementing software development projects, there are different stakeholders. The development team wants to implement the best architecture, product team wants to see the feature as soon as possible and would like to proceed with a cost-effective solution. In this case, how to find the best option.

Let’s elaborate on some details;

• Roles in the team: Developer, Solution Architect, Product owner
• Situation: The development team wants a real-time processing solution. It takes more effort and increases time to production. However, the product owner thinks that offer complicates the solution, and thinks there is no necessity to follow this option.

In this case, how solution architect find a solution to make the team happy?

First of all, you couldn’t make everyone happy. The best option is to be transparent with everyone and find the optimal option. Based on the analysis, the current system is implemented with batch processing, and the solution architect will do more analysis.

As a solution architect, you can list down all options and write pros/cons for all possible solutions. I won’t deep dive into all the technical details, we are just looking for the tactical methodology

Real-time processing advantages

• Process data real-time
• etc...

Real-time processing disadvantages

• 7/24 Support and Monitoring
• etc...

Batch processing advantages

• More stable
• Needs less maintenance effort
• etc...

Batch processing disadvantages

• Latency
• asdasd

You can see all the advantages and disadvantages. As a second step, what you can do is to put some comments for the listed items. For example;

• Latency does not matter for the business
• The technical team doesn't have enough capacity to monitor real-time processes and fix immediately when the issue happens
• etc…

These are small tips for a decision about the final solution. It seems, that development can be done via batch processing option. If you clearly explain why the batch option is selected, it would be better to put the most important advantages and disadvantages. Hence, everyone aligns on the solution

How to behave in a failed project?

In one investigation, it was said that %70 of software projects failed. In this subject, we won’t discuss the reason for failed projects. I will give one example of how to behave within a team if the project has failed. If the project is implemented to the customer, it would be a more challenging situation

Let’s elaborate on some details;

• Roles in the team: Developer, Solution Architect, Project Manager, Customer (Business owner)
• Situation: The project is processing the documents in order to make them searchable in the search system. After 6 months of work, the application has been deployed. However, most of the document process has failed due to unexpected load to the application. The project has been handed over to the customer, but they are not happy about the application, They asked to fix the problem without any cost, and they are not happy about the work, and don’t want to sign any contract in the future.

In this case, how do solution architects find a solution to convince the customer that they fix the problem and work together for the upcoming projects?

First of all, you need to do some internal meetings to raise the issue and pay attention to risks. Put all the problems on the table, but do not blame anyone. At this time, you have to tackle all issues as a team, real teams can be seen at this moment.

Once you align on the problem, it would be better to find the optimal solution that fixes the problem. You need to also get some support from the management team. If you need more capacity, feel free and ask for support from the management team. As I mentioned, this kind of issue usually happens.

As a second step, please be transparent to the customer. Explained the challenge and the reason for the problem. And you can commit, that you will fix the problem as soon as possible without any cost from the customer. As expected, the customer will make some noise, but they also want that the issue will be solved. You will show that you are solution-oriented.

Once the implementation has started to fix the problem, make a demo as much as possible to the customer. It might have fewer features, however, it is always better to move away from over-commitment. They might change some features.

How to tackle long-term projects?

In ideal scrum projects, your team implement the features and deploys them with 2–3 weeks iterations. When you start a transformation project, there will be more work you couldn’t foresee during the project. As a solution architect and project team, you might be given 6 months to complete the transformation. Most probably, it will fail in terms of timeline.

Let’s elaborate on some details;

• Roles in the team: Developer, Solution Architect, Product Owner
• Situation: The company wants to move from the monolith database to a cloud-based database. It is not just a lift-shift approach, some of the components need to be transformed. The transformation team has 6 months to complete the project. After starting the project, the development team found more work to complete the transformation and it would take more than 1 year, even more.

Once this issue happens, the project team ask to find a solution and approach to finish the project successfully.

First of all, you need to clearly explain that the project has more work than the initial estimation. It should be explained to everyone, that it is not a development or architecture issue, the problem is wrong estimation. Even if you make a good estimation, you need to be open to surprises.

In this case, I would recommend splitting the transformation project into smaller parts. It will accelerate your life.

Let’s assume you are planning to do the following transformation

Instead of transforming everything at the same time, you can make transformation step by step. For example;

• Transformation Phase 1: Order Placement Transformation
• Transformation Phase 2: Inventory Transformation
• Transformation Phase 3: Analytics Transformation
• Transformation Phase 4: Customer Communications Transformation

Once you finish the first phase successfully, the team can start other phases. There might be still surprises, however, it shouldn’t be big like a full transformation.

Conclusion

As you see, there are different approaches to solving the challenges in the project. As a solution architect, you are not only responsible for architecture, you should also lead the project. There is no certain recommendation for each use case. There are some problems and solutions that happen in real project work.