A colleague of mine - fellow AppTx practice lead - Shaun Anderson posed a very interesting question last night
1. *Mr. Boxes and Lines*, *Mr. Ivory Tower* : Knows all the latest frameworks and technology choices and answers questions the right way; however could not code up a simple program to save his life.
2. *Mr. Hoarder*: Architects the system in such a way that only he understands the intricacies and holds it close to his chest. Refuses to call his baby ugly.
3. *Mr. Framework*: Frameworkify everything even spring such that all the developers only need to extend the UBER framework at the edges. Assumes developers are dumb and cannot think for themselves and therefore need to be provided abstractions suitable for a seven year old. This is an egregious form of a hoarder. Sometimes this is taken to the extreme where a meta framework will generate other child frameworks aka Mother Of All Frameworks.
4. *Mr. Kafka-lover*, *Mr. Serverless-lover*, *Mr. Reactive-lover* : Answer is Kafka OR Answer is Serverless... What is the question ? This is an architect who falls prey to Microservices-envy, Kafka-as-an-esb and layered-tech-driven architecture anti-patterns. Answer is r2dbc - Now what is the question ?
5. *Mr. Async* : Makes the genuine mistake of equating event driven architecture to event sourcing. Does not realize the four forms of event driven architecture. see Many meanings of event driven architecture
6. *Mr. Pussyfoot* Hesitates to make any architectural decision without deferring to a central committee.
7. *Mr. Shit-it-all* : Periodically swoops down from an ivory tower to shit all over the current project architecture and implementation leaving behind a bunch of half-ass diktats without full context.
8. *Mr. Manager-upper*: Architect only shows up when his boss or adversary shows up and is largely absent without their presence.
9. *Mr. Idiomatic*: Architect does not engage in fruitful debate and unwilling to reassess their state. They have made up their mind and are not willing to experiment or concede that their world view may be wrong.
10. *Mr. Cowboy*: Solution first - ask questions later. Indulges in premature optimization or premature solutioning without fully understanding the question, intent or context.
11. *Ms. Alice in Wonderland*: jumps deep into each and every rabbit hole one can find
12. *Ms. I Told You So* : As soon as something goes just a bit sideways drops the “I told you this was not going to work and here’s why” in front of your stakeholders.
13. *Mrs. Nit Picker*: The architect who needs to understand every single detail prior to coding anything.
14. *Ms. But Why*: When you don’t understand something 100% and the only thing you can do to prove your presence is to ask “But Why” > on repeat.
As an architect we all make these mistakes and there is no shame in admitting that; however recognizing some of these behaviors in ourselves and others helps us improve and become better architects that build something real that delights our customers and stakeholders.
"tell me about the behaviors of all the people you have not had success working with"which got me thinking. Our industry has some established norms on what a software architect should do; however we don't have prescriptive guidelines around what an architect should NOT do. What behaviors an architect should not display. To capture these ANTI-architect behaviors , I outline the the architect styles you should probably NOT copy.
1. *Mr. Boxes and Lines*, *Mr. Ivory Tower* : Knows all the latest frameworks and technology choices and answers questions the right way; however could not code up a simple program to save his life.
2. *Mr. Hoarder*: Architects the system in such a way that only he understands the intricacies and holds it close to his chest. Refuses to call his baby ugly.
3. *Mr. Framework*: Frameworkify everything even spring such that all the developers only need to extend the UBER framework at the edges. Assumes developers are dumb and cannot think for themselves and therefore need to be provided abstractions suitable for a seven year old. This is an egregious form of a hoarder. Sometimes this is taken to the extreme where a meta framework will generate other child frameworks aka Mother Of All Frameworks.
4. *Mr. Kafka-lover*, *Mr. Serverless-lover*, *Mr. Reactive-lover* : Answer is Kafka OR Answer is Serverless... What is the question ? This is an architect who falls prey to Microservices-envy, Kafka-as-an-esb and layered-tech-driven architecture anti-patterns. Answer is r2dbc - Now what is the question ?
5. *Mr. Async* : Makes the genuine mistake of equating event driven architecture to event sourcing. Does not realize the four forms of event driven architecture. see Many meanings of event driven architecture
6. *Mr. Pussyfoot* Hesitates to make any architectural decision without deferring to a central committee.
7. *Mr. Shit-it-all* : Periodically swoops down from an ivory tower to shit all over the current project architecture and implementation leaving behind a bunch of half-ass diktats without full context.
8. *Mr. Manager-upper*: Architect only shows up when his boss or adversary shows up and is largely absent without their presence.
9. *Mr. Idiomatic*: Architect does not engage in fruitful debate and unwilling to reassess their state. They have made up their mind and are not willing to experiment or concede that their world view may be wrong.
10. *Mr. Cowboy*: Solution first - ask questions later. Indulges in premature optimization or premature solutioning without fully understanding the question, intent or context.
11. *Ms. Alice in Wonderland*: jumps deep into each and every rabbit hole one can find
12. *Ms. I Told You So* : As soon as something goes just a bit sideways drops the “I told you this was not going to work and here’s why” in front of your stakeholders.
13. *Mrs. Nit Picker*: The architect who needs to understand every single detail prior to coding anything.
14. *Ms. But Why*: When you don’t understand something 100% and the only thing you can do to prove your presence is to ask “But Why” > on repeat.
As an architect we all make these mistakes and there is no shame in admitting that; however recognizing some of these behaviors in ourselves and others helps us improve and become better architects that build something real that delights our customers and stakeholders.
