I want to share some answers from this question that I found particularly useful.
Even though this question can be taken in different directions, I found these to be good reads no matter what you are trying to get out of the situation.
Comment Not Found
Software architects usually interact with the clients and stakeholders of a project. They - ideally - will need to be involved in figuring out exactly what kinds of requirements the client is looking for, being able to make sure the requirements are business requirements and not just "make this page have a floating top menu bar."
Total aside: Yes, I've been on a project where we literally spent hours of meetings with CEOs of two large insurance companies just to decide whether to use a floating top menu on the web site 😜. It happens...
Anyways, the architect needs to make sure that the technical direction of the project is viable/feasible give the business needs.
So there are two primary parts:
- You need to know tech really well (system design and knowing what problems specific tech solves)
- You need to be able to communicate well with non-technical people and convert business needs into software systems/designs that will allow the business to achieve those goals and yet allow flexibility of the system to change over time.
Knowing multiple programming languages, paradigms, etc. as mentioned in the "question" of this post are helpful because every language and paradigm solve specific and different kinds of problems.
If you have a business, for example, who needs a system that will be developed and maintained by hundreds of developers, then you need to know that there are specific patterns for building these kinds of systems (DDD, Microservices, etc.)
Imagine the need for an e-commerce site which needs to keep the data of all user interaction with the site (via products ordered, products added to cart, products removed for cart, etc.) so they can do analytics in the future (I.e. predictive analysis, etc.). Knowing that Event Sourcing can solve that problem would be applicable here.
So, a big part of being a good architect means your knowledge is broad enough that you at the very least know what technologies are available to solve which problems. And you can figure out what business problems map to which technological problems and solutions.
It's good to first know what you're asking for. A "software architect" position usually refers to the job in an enterprise setting. This clarification may be useful.
What you're describing as examples is more about people who are actively engaged with the programming community, present and past, with a very specific set of questions:
- Will this change in how I think improve some aspect of how I write software?
- Will it break some other aspect?
- What led the people who did this to do so?
So once you have been through this many times you look at a new library, framework, or language, and can quickly categorize most of it. Usually you can categorize all of it, in which case it's interesting only insofar as you may have to use it to get paying work done. Sometimes it remains interesting because of interactions that you haven't seen tried before (e.g., Scala trying to wed the Java type system with Hindley-Milner type systems, and experiment that I feel was a failure). Occasionally there's an interesting piece of something and you spend a few hours or a few days beating on it, trying to find what's there.
When you're just starting out, you can flail at the usual suspects and get a lot of mileage. A short list of things that I guarantee will not be a waste of your time:
- Ullman's Elements of Standard ML. Then go look at the ML language family and read the papers of people who designed the various members and what drove them.
- Leo Brodie's Starting Forth and Thinking Forth, then go mess with Pygmy Forth and read about what Charles Moore has done with colorForth.
- Spend some time working with Pharo or Self, and learn what it's like not to have a separation of a system into programs, shell, etc. Then go read the literature of people who worked on these systems and find out about the problems with them.
- Learn to write Prolog.
- Read a bunch of Dijkstra's EWDs, especially the late ones, and get into his ideas on calculational mathematics. And read a bunch of Alan Kay's work. These two couldn't stand each other's work, and being able to switch back and forth between their perspectives is a diabolically valuable ability.
SICP is a wonderful book. If you enjoy it, go to it. Branch prediction is worth understanding. If you know probability, it should take you about half an hour to understand how it's supposed to work. There's no reason to understand it at a silicon level unless you're designing chips or fighting with truly bizarre performance problems. Likewise, Types and Programming Languages is more machinery than you probably need right now. If you find yourself building type systems or programming languages, then you will read it cover to cover and it will seem like the most wonderful, applied advice ever. If you aren't in that game, you're better off getting the basics down so you can understand how various type systems differ and what the experts mean when they argue about them, and then moving on to something else. Remember, your time is finite.
Happy coding!
Top comments (3)
In my opinion, an architect is the person that should be aware of the main basis of the entire system, and take the responsibility of the architectonic design. Should be a monolithic application or microservices-based? How many components should we make? How will be the communication between processes / other systems? Should we use a NAS for store the content or can we use blobs at database? Will be neccesary a CDN / Akamai service? Thats the kind of stuff that he or she must take care. No talking with the stakeholders, and not to make resources management at all. For that purpose, there is a project manager or functional analist. There are totally different things in my opinion. Could an architect manage projects? It could be, but that is not the main point of that role.
On the other hand, i would like to recommend the article "Who needs an archictect?" from Martin Fowler. I think that the differences of the "Architectus Reloadus" and "Architectus Oryzus" are faced from a good point of view files.catwell.info/misc/mirror/200...
Unfortunately the title "architect" becomes the new "manager". It is used inflationary:
...and of course our beloved "software architect". None of them is a product of my fantasy - just google them and you will find job offerings for all of them. Worst of all: the specification of these roles is different in each company.
After following above discussion, I see that despite software development involves a lot of communication, architect role seems to be more communication aware. Recently, I found the communication in my project is not effective due to no standard and variety of tools. Require too many plain text documents and few diagram which can lead to diverged experience. I did some research and found several standards: ArchiMate, BPMN, UML in general. Overall I see ArchiMate is very good of splitting different aspects of architect.
Is there anybody here actually use it before?
Is it a good intention to apply this into a project?