Success Skills for Architects with Neil Ford
Introduction
Neal Ford of ThoughtWorks chats with Kim Carter about what the required skills are in order to be a successful Software Architect, how to create and maintain them, and how to transition to them from other roles, such as Software Engineering. Neal discusses that the required skills can be learnt, you do not have to be born with special attributes.
Overview
People makes architecture decision even if it not in their title or qualification.
For an architect “soft skills” are essential like presentation skills. Nowadays there are higher standards against architects. Nowadays architect should think of DevOps aspect of the architecture. Architect responsibility is broader than before. Much more thing to consider.
Architects needs to stand meeting. So if you do not be able to stand a meeting then you are fucked up.
There is leadership aspect of software architect.
A really effective one should be good speaker and presenter. Be able to speak not only for technical but to business people.
Most important characteristic of software architect:
- understand technical aspect
- soft skills. Important to find compromised between contradicting parties with different priorities
- express architect vision to business and technical.
- understanding the different nature of knowledge: Depth of knowledge is not as important as the breadth of knowledge. Knowing multiple ways of implementing an architecture/tool is more important than knowing a single tool to implement the architecture. He has to give up certain expertise to in exchange to get more breadth. Broaden your technology knowledge.
- all these “-ilities”: knowing the broader context. Especially broader business aspect: resiliency, scalability, reliability, maintainability, etc. One of these what architects are not emphasizing enough is the feasibility. Should we even try this? Should/could we do that? Timeframe and cost constraints. Understand feasibility.
- understand how a tool might have effect on your architecture.
How to handle not to be as technical as before?:
Keep developing. But not on the critical path. One of the best way to pair with a developer.
- Pair with your team regularly
- see how architecture get to live code.
- guide junior to understand architecture
- see the problem come up in real codebase, etc.
How to transfer essential knowledge to developers
- pair programming is the best for sure.
- a kind of good specification language: certain spec language has the problem of being too tech to a non-tech and not enough tech to a programmer. UML is not a good communication language. Alternative could be C4 model might be suitable because in C4 you have think in different layers and aspect of architecture . (He is giving a summary). It is targeted to different audiences implicitly.
- Lightweight Architecture Decision Records: Text based. Capture essence why we made certain architectural decision. Put into version control. Try to capture the essence why you have made these architecture decision. Do not lose all the analysis work you have made what drive to the conclusion of the usage of current architecture. It could include simple status indication that it is an idea, approved and even that it is implemented and finally removed (as the system is evolved later and it had to change).
Q: Keeping Simple is hard — what do you think?:
Why is it going so complicated over time? The why things got more complicated because metawork is more interesting then work.
e.g.: Writing a new framework is always more interesting than using an existing one to create something valuable to the company. At the end your job is simply read, put value and write back to database. Metawork is much more brain challenging. (E.g. replacing Angular to React because they “assume” it will be better in the future)
Q: Learn from history. Why is it interesting?:
Learn how to make decision about things (Dreaming in Code book) Infinite resources (aka no constraint) could still drive to project failure. Is there any value in the thing we are doing?
“Are we delivering value?”
Q: help young engineer the importance to learn from history:
Not to run into the same problem over and over again.
Component replacement: we think it is like replacing LEGO. But it is more like organ transplantation.
Q: Clever Code:
Useful sometimes but in general it is not good. Good examples: multi-paradigm languages. That is the why multi-paradigm languages cause trouble (e.g. Scala). Too many way to do the same things. So it could be difficult to others to understand. Anytime the tool has SIMPLE in it name that it is probably not simple at all, marketing only (e.g.: sbt, SOAP). Don’t create too clever stuffs. Developers like creating clever stuffs.
Eliminate complexity!
Be aware of accidental and essential complexity. Example: Routing physical mails. Accidental complexity is when the routing is done by complex character recognition algorithm instead of (e.g.) color code/unit of the paper they use (blue color for unit1, red color for unit2, etc.) what is much simpler.
Conclusion
Software architecture is a fast-moving, multidisciplinary subject where entire suites of “best practices” become obsolete practically overnight. No single path or curriculum exists, and different types of architecture application, integration, enterprise require different subject emphasis. Whether you’re at the outset of a career as an architect or in the midst of such a career, series editor Neal Ford has curated this collection of tools and guides for aspiring and seasoned architects alike.