Ask HN: What makes a good solution architect?

[ythen]

I was recently tasked to architect and develop a solution, with limited time and human resources. I was only given 3 months although I speculate the project will need minimum 6 months. I never believe a good quality software can be deployed in such short period of time. I argued to no avail. I have 3 fairly experienced developers at my disposal.

Despite this, I proceeded designing the architecture. We need to develop an app server, a mobile client and a desktop client. I alone handled the architecture design, research, development, and deployment. We survived, unpleasantly. I believe I have then suffer with some level of depression.

As retrospective, I:

* failed at properly documenting the architecture

* failed at properly setting up the dev env so that the other developers can run their instances of the solution locally

* dwelled too much time to achieve the above point

* dwelled too much time to automate things, especially at trying to automate dev, staging, production setup

* failed to look at minor details (I need help with this, I'm a big picture guy, never the details)

* should have sticked to SDK provided by third party, instead I chose to go with something totally new to me just because the SDK is only available with COM Interop and I do not have any Windows machine with me.

I believe I have the knowledge, and not afraid of looking for the knowledge and the "proper" ways of things should be done. And maybe trying too hard.

Back to the topic, what makes a good solution architect, how can I improve myself?

[UK-Al05]

How did you deliver the software? One bit at time, or at the end of 3 months?

Things in my experience that increase the success of a project.

Deliver small bits very frequently and demo and ask the stakeholders for feedback. If i was unsure about delivering all the features in 3 months, I would tell them that. However I would try get the real priorities of their needs and focus on them first. At the end 3 months you should be able to deliver something that provides something valuable but not everything.

Make sure you build quality in as your building.

They should judge progress of the project by what your giving and showing them, not a timeline and a status report.

Upfront documentation isn't necessarily the best way of getting knowledge accross(Although it should be used). The best is collabarating, pair programming with your team etc

I don't know what your situation was, but these days setting up ci/cd pipeline to a staging/prod slot for a small project is fairly quick...

[ythen]

100% agree with you on delivering small bits at a time. That's where I came from. However this time round, contracts are signed, everything listed in the functional spec must be delivered by end of 3 months, non amendable. We still do weekly progress update and demo.

What I failed to convey to my team is that qualities are important too. Instead, I've got many hardcoded things from them at almost the end of the project, no test, no nothing.

Stakeholders do not understand that quality software needs time, yet they continue to stress on quality while sticking to the timeline. I figure I'll need to educate them better next time.

> Upfront documentation isn't necessarily the best way of getting knowledge accross(Although it should be used). The best is collabarating, pair programming with your team etc

Agreed! That's what we did, using PRs. I reckon that every developer should know how to write a good commit, breaking or squashing commits into meaningful pieces. that'll make PR easier to read.

> I don't know what your situation was, but these days setting up ci/cd pipeline to a staging/prod slot for a small project is fairly quick...

Well, let's just say I learn it too late while tangling with other issues. Also I find dev in the team underappreciated CI/CD, people really don't write tests too. More education planning in plan.

Thanks again for your time.

[apohn]

I'll say this as somebody who worked in consulting and has seen many projects fail for similar reasons. You are focusing on architectural and technical issues. Don't forget business issues.

>I was only given 3 months although I speculate the project will need minimum 6 months.

1)If you feel a project is not going to succeed, identify all the risks and make them very clear before the project starts. If you are forced to do a project despite objections, ensure that you present the risks and technical compromises to all the stakeholders. Make sure everybody knows the risks. Then just go ahead with the project and don't complain too much, even if you feel the project is going to fail. Also, if you have downstream projects (e.g. after your team is finished, another team will start phase 2 you really need to make those risks clear.

Part of identifying the risks is to present what needs to be in place to mitigate these risks. Statements like like "Dev Environment needs to be in place before we can start this project because of X,Y,Z."

2). I've been in situations where a client/customer was excited for us to do something and I felt there was only 20% chance of success. I said "Maybe, but there is some risk". They interpreted this in the completely opposite way - to the customer this was the green light of success. In retrospect I should never had uttered the word "Maybe" or given any similar indication.

>I believe I have the knowledge, and not afraid of looking for the knowledge and the "proper" ways of things should be done.

You have learned the way all Solutions Architects do. By failing and then asking what you could have done better. When I work with people who are just starting in their careers, they ask me "How did you know so early on this project would not succeed?" It is because in the past I was in their shoes and said "Yes, we can do it" and then failed and felt terrible about it. It feels worse if people work 60+ hour weeks and then it still fails because I misjudged the effort required.

Many people do not ask what went wrong when they failed. They don't take any responsibility and then go and make the same mistake over and over again. You are in a much better position - at least you are asking how you can do better the next time and what it takes to succeed.

Don't be depressed. You are learning by trial and error like everybody else does :)

[ythen]

Appreciate for taking your time to reply! I will definitely keep those in mind, especially informing about the risks.

Businesses are cruel, when they want to win projects over, they fight it by building the solution out in short time. Next time round, they'll demand even faster pace, because we managed to deliver the previous one. What's worst, they may not be able to sell it out after all the efforts.

I'm more an advocate of lean, but sadly in my country, it rarely worked.

Nonetheless, really appreciate your input! I will walk out from it, promise.

[cimmanom]

So you weren't perfect this time around. Nobody's perfect. And you were dealing with some pretty difficult constraints.

You've clearly already learned something from this process, and you'll apply that knowledge the next time around.

That next time won't be perfect either, but again you'll learn something and continue to improve.

Don't beat yourself up about not being a superhuman who could anticipate every possible issue the first time you did something. Even the best and most experienced architects still make mistakes with every project and still learn something new each time around.

[ythen]

Thanks for reminding me that humans do make mistakes. You're right, learn from experience again and again. Thank you!

[ankurdhama]

Question for you - what questions/problems a software architecture is trying to answer/solve?

[ythen]

Hmm, for a software architecture, I'd say to break codes into their appropriate parts/layers, DB models/schema.

For a solution architecture, I'd say to orchestrate pieces of different software, how to integrate them, how they communicate with each other, and how to deploy them as a whole.

I would love to hear answers for that question too.

[some_account]

Heavy technical background. Not Microsoft.

[quickthrower2]

That's the wrong attitude. An architect should say "Not only Microsoft". There is no reason to blanket dismiss MS products and solutions.

[ythen]

Not an advocate of Microsoft, tho I'm using GitHub and VSCode.

As for heavy technical background, would you elaborate on that? I'm more like a jack of all trades.