
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.<p>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.<p>As retrospective, I:<p>* failed at properly documenting the architecture<p>* failed at properly setting up the dev env so that the other developers can run their instances of the solution locally<p>* dwelled too much time to achieve the above point<p>* dwelled too much time to automate things, especially at trying to automate dev, staging, production setup<p>* failed to look at minor details (I need help with this, I&#x27;m a big picture guy, never the details)<p>* 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.<p>I believe I have the knowledge, and not afraid of looking for the knowledge and the &quot;proper&quot; ways of things should be done. And maybe trying too hard.<p>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.

