Simon Brown

Congratulations to the winners and many thanks to everybody for the fantastic discussion ... it's great to see that interest in software architecture is still alive and well.

Kent, do you have any meetups/user groups in your area? If so, I'd certainly recommend heading along to these, particularly if they run coding dojo style sessions where you can pair with somebody else you practice your craft. If there are none, perhaps that's an opportunity.

Saritha Penumudi wrote:Quick question on technology selection from article http://www.infoq.com/articles/brown-are-you-a-software-architect. As there are more than one possible solution/problem for every problem, How would you go
about picking one technology/framework over other. It can get overwhelming to try out (do POC) on each framework to see if it fits the solution.

Are there better tools or process that makes this selection easier?

There's no single piece of advice I can give you here, but here are some of the things that you should consider:

- Avoid jumping on technology choices simply because they're cool or in fashion. I'm not saying that you shouldn't innovate though, but you do need to focus on delivering value rather than enhancing your CV/resume.
- Look at the team you have around you - if you have a team of traditional Java developers (e.g. building Struts-style webapps), then I'd be wary trying to jump ship to something like node.js. It's a huge change.
- A collaborative architecture process can help identify potential technologies and highlight personal preferences.
- If you see any risk with the technology choice, ensure that you isolate that technology as much as possible from your business code, enabling you to change that technology choice in the future if necessary.

I typically tend to be slightly more conservative with my technology choices, but that's just a personal preference. As an example, I'm about to start building a new webapp ... I'm going to be using Java, Spring MVC and a JavaScript framework (e.g. something like Angular or knockout) on Apache Tomcat because I know that it will get the job done.

Hope that helps!

K. Tsang wrote:Another question based on this is to become a software architect (or another other architect), how technical (depth) does one need and in how many topics? Eg programming xyz, design pattern, framework abc, app server pqr, etc There are so many products or technologies one can delve on. And at the same time, one can't be expert at everything.

On the contrary, for the breath, being aware of such and such technology but not knowing what its purpose or benefit would be like not knowing it at all. But when one start researching/learning it the depth mode may take over. How much is enough for breath?

This is an interesting question. Architects need to know something about the technology that they are using to design something. So if you wanted to design a Java EE solution, you need to know about Java EE. The danger, of course, is that as your depth of knowledge increases, you become a "Java EE architect" rather than just an "architect". I actually don't think this is bad, provided that you have an open mind and an awareness that there are other solutions out there, some of which might not be Java and some of which might be better. This is the breadth part of the "T". Ever heard the saying, "if all you have is a hammer, everything looks like a nail"? I've seen a team who specialise in Microsoft SharePoint and pretty much all of their solutions are SharePoint-based, despite SharePoint clearly not being the right solution in many cases. It's all about choosing the right solution, and sometimes you have to admit that somebody else might be better suited to providing the answers. As you said, we can't know everything.

Jeanne Boyarsky wrote:(and unit test - I wish that went without saying.)

Me too.

Burk Hufnagel wrote:I don't know about a system architect, but I do believe that a software and solution architects should have a background in programming - and keep up with what's new in the languages they're designing for; otherwise how will they know that their solutions will work?

That's my view too, and it's why architects do need some technology knowledge and experience.

Here's a question to everybody else ... given that the software development industry is moving so fast, how do you keep your technical skills up to date?

haha, cheating, those questions sound familiar ... https://leanpub.com/software-architecture-for-developers/read#questions-6

As I've said in some of the other threads, I basically take a risk-driven approach to architecture in order to stack the odds of a successful delivery in my favour. Too much risk-mitigation quickly leads back to big design up front and analysis paralysis though.

Reading will certainly help, but it's no substitute for gaining real-world experience. One of the big problems that we have with software development is that even the majority of existing software architects don't get to design software systems from scratch all that often, so actually getting experience can be hard. I would recommend pairing up with an existing architect as a way to fast-track gaining some experience. You could also do some architecture katas as a way to practice your software architecture skills.

charlsy chuks wrote:On the other hand with regards to tools and patterns, when the architect does not know much about a pattern like MVC and his team members are equally green horns but he insists MVC must be used because of the benefits, I think you have a recipie
for trouble because initially the team will be slow (opposite of agile) as they will be learning new stuff and coding at same time.

Yes, that's right. This is why I promote a risk-driven approach to software development. We don't (and can't) know everything, so it's worth addressing the risky things that could force your project to be cancelled or you to be fired. Processes like the Rational Unified Process (RUP) have said this for years, but somehow the focus on risk has taken a back seat in our new world of agile approaches and delivering features. As always, there's a happy balance to be found.

You're welcome ... if it makes you feel better, I have an ever-growing list of books to read too!

Junilu Lacar wrote:Coming from anyone else, saying that the book is "theoretical" would be a disservice -- I would go with "philosophical" instead. You discuss a number of things that architects should do based on your own values and beliefs as a software developer: "Architects should code," "Architecture should be 'just enough'," "Architecture is a role, not a rank" to cite just a few. IMO, these are key foundational values and principles that guide all the other aspects of an architect's work.

Thanks, I'll stop using the word "theoretical" then. "Philosophical" and "priniciple-based" works for me.

Thanks for the clarification, much appreciated ... unfortunately it's not a topic that I'm familiar with I'm afraid.

Hi Comal, I'm not quite sure if you're asking about process (iterations) or technology (object pooling) ... could you expand on the question, please?

You're welcome. No, nothing about TOGAF I'm afraid.

Jayesh A Lalwani wrote:In my last job, I eventually became the "chief architect". I'm like dude!! stop giving me bullshit titles. I "demoted" myself to technical architect

Brilliant!