Avoid the ivory tower in software architecture

In this talk I will tell you a story about an architect and a dev team wanting to develop a perfect product...the outcome is...well see and hear for yourself :)... In the talk I will point out common problems in the communication betweeen developers and architects, and show potential mitigations.

Transcript

1. Avoid the ivory tower (stay connected with the engine room) Jan Moser, Senior Technical Architect, NFQ Asia
2. Jan Moser • Working for NFQ Asia as Senior Technical Architect • Native Swiss, mostly living in Asia since 6 years • ISAQB Instructor and certified Azure Solution Architect • Specialized on Microsoft technologies • Besides work often to find behind the DJ decks of the clubs of the world, or in the Muay Thai ring jan.moser@nfq.com https://www.linkedin.com/in/moserjan/
3. What is this ivory tower?
4. What is this ivory tower? • Wikipedia says: An ivory tower is a metaphorical place—or an atmosphere—where people are happily cut off from the rest of the world in favor of their own pursuits, usually mental and esoteric ones. From the 19th century, it has been used to designate an environment of intellectual pursuit disconnected from the practical concerns of everyday life. • For us as tech people this means: If we are working from an ivory tower, we may be creating an architecture or design based on a perfect-world environment that really doesn't reflect real scenarios. In addition, we may not be working closely with the developers or engineers who will be creating implementations based on the architecture / design.
5. From the ivory tower…
6. Let’s start with….Garlic
7. Garlic Architecture… • We gathered all the requirements of our customer to build a perfect garlic for them ;) • We created and architectural draft of the garlic we want to build. • We also showed in graphics and documentation how we want it to be integrated (planted). • We communicated this to our dev team and let them build it.
8. Why software architecture and engineering are not the same For the software engineer…this is the ultimate goal Whereas a software architect like this the most
9. The infamous big picture • The Software Architect job often means that you have to create or maintain the customer’s or company’s vision in a technical manner. • For this the interaction of system parts, its homogeneity or accessibility to your infrastructure can be more important than the technically best solution of one part. • This is imho the big difference between a software engineer, who wants to solve a system part as optimal as possible, and the software architect who has to create the best maintainable, cost fitting , sustainable solution given the customer’s or company’s constraints.
10. To the engine room…
11. The garlic plan
12. In love with the details… • Our software engineers do a great job, they split our garlic in cloves, then create a detail design per clove… • It looks complicated (this Is good…I mean..they are engineers…) and they can still explain every part to their peers. • They make sure every detail is perfectly optimized and every clove is super performing…
13. The result…
14. What happened! • As software architect we built the perfect garlic in our mind • We tried to communicate it as best as possible to a team of very capable engineers. • We fully trusted each other and did only check on project completion how the result looks like.. • As Software Engineer we had the perfect part of our system in mind • We did not overly communicate with our peers (I mean there are interfaces and stuff…) and focused on our system. • We thought we understand fully the requirements and there is no need to talk to our software architect, once the implementation phase has started.
15. So how can we get… From this… to this…
16. Tools, Tools, Tools… • The better we can communicate an architecture or design, the better the implementation team understands it. • Use a structured template to document and communicate your architecture… • Examples here are: ARC42 (https://arc42.org/) C4 (https://c4model.com/) TOGAF (https://www.opengroup.org/togaf) • Another good point is to enforce architectural constraints. • To do so use a CI/CD pipeline that does certain validations during build and before deployment. • Tools here can be: Sonarqube (https://bit.ly/3M2yMrb) ArchUnit (https://www.archunit.org/) Ndepend (https://www.ndepend.com/) Jarchitect (https://www.jarchitect.com/) Structure101 (https://bit.ly/3nBwxkg)
17. Next….people! • Software architecture is much more a people job than many people think. • Software architects are to certain extent deeply involved in the requirement engineering process of a project or system • They gather information from the stakeholders, define with them together quality goals and a system vision • They support the development team(s) in understanding the architecture blueprint and guiding them during the implementation • They periodically review the architecture of the system and address deviations
18. Stay connected to the engine room… • To avoid classic ivory tower fails, we need to stay connected to our implementation teams. • Join their daily standups or organize periodic meetings to see what they are working on, if there are things unclear or not feasible • Create a culture where people feel safe to challenge everyone’s technical decisions. Explain and support them, rather than play the almighty super person! • It also helps big time to “eat your own dog food” sometimes. Meaning you can take over smaller development tasks or help the team debugging or bugfixing or reviewing code. • I recommend you spend like half a day or one day sprint, keeping connected to the codebase.
19. Last but not least… Together as a team we can build awesome software without an orange-garlic flavor! ;)..but we need to collaborate with each other
20. Any questions? Thank you! 20