The pragmatic architect

is obviously use-case-driven

A pragmatic architect is someone that gathers use cases and constraints before thinking solution.

Even more, a pragmatic architect cares about the 'why are we doing this?' (i.e. the underlying business goal, that is too often not clearly explicited and shared). He reviews and confronts any option or action with this initial business objective. He tries to deliver projects that will have impact, not only to ship software.

A pragmatic architect does not confuse architecture with tools and frameworks. He also likes architectures to scream their intentions.

knows there is no such thing as 'absolute truth or architecture'

A pragmatic architect knows that there is no absolute truth or solution. She understands that every choice or trade-off is depending on a context (including human considerations).

A pragmatic architect experiences what she recommends to the others. She stands by her choices with the rest of the team or stakeholders.

A pragmatic architect fosters situations where people can live without her. She tries to setup systems that make people fall into the pit of success.

is also a pragmatic programmer

A pragmatic architect is also a pragmatic programmer and a software craftsman. He really enjoys coding and to improve himself at it. If he could not code during working hours (i.e. the slides and diagrams kingdom), he may contribute to open source projects at home.

As every pragmatic programmer, he likes to script and automate every recurrent and painful things as much as possible. He is obviously a big fan of Continuous Delivery.

A pragmatic architect also understands that Continuous Build is not Continuous Integration.

A pragmatic architect is not only talking about Test Driven Development to every reluctant mate, he tries to show the benefits of TDD as often as possible during concrete pair programming sessions.

A pragmatic architect knows the 9 indispensable rules of debugging, and is always willing to remind them to anyone that may need it. A pragmatic architect is also an ego-less programmer.

A pragmatic architect is capable to discuss the strengths and weakness of Object Oriented Programming or Functional Programming to other mates. He likes to step aside and get perspectives on things, and fundamentally needs to understand the reasons of every choices.

A pragmatic architect knows about patterns and anti-patterns, he values GRASP, GOF and POSA patterns, but also cares about the Capacity and Stability ones. As every software craftsman, he also embraces the SOLID principles. But more than anything else, he likes that things stay as simple as possible.

A pragmatic architect likes abstractions, but is aware of the law of leaky abstractions. He also knows that "the pitfall of dogmatism is inherent in any effort of abstraction".

A pragmatic architect has lots of ideas, but he likes nothing more than to share and to debate them with others. But mostly to confront his ideas with the real world. Also, a pragmatic architect does not fear to try. He knows that failure is mother of success. And he usually does not put all his eggs in one basket.

A pragmatic architect does not fear risks, he rather mitigates them.

cares to understand the business stakes.

A pragmatic architect is curious, this is one of the reasons why she chosen this job. And even if she's an hardcore technical addict, a pragmatic architect is someone that cares to understand the business stakes.

A pragmatic architect always prioritizes the work according to the value it brings to the project. This is why she usually defers decisions about the choice of frameworks or tools to be used (db for instance)..

A pragmatic architect always asks 'Why?' five times, so that she can find out the real root causes, intentions, or needs behind her interlocutors words.

A pragmatic architect likes to explicit every kind of implicit. She makes everyone to be on the same page. She's even able to ask naive and silly questions she already knew the answer, just for shy people in the room to heard it. She usually ask people to re-phrase things in order to check they have understood what was said.

A pragmatic architect has not only a vision for the project or the IS, but she cares to share it with ALL the stakeholders involved.

A pragmatic architect is an enthusiastic team player. She really enjoys to collaborate with people and teams.

A pragmatic architect understands that Behavior Driven Design (BDD) is not a matter of tools, but a matter of collaboration and communication among various actors (Biz/BA, ops, QA & DEV).

A pragmatic architect is agile, but doesn't feel the need to repeat it to everyone. She is now more concerned about how to scale agility within the organizations, and how to improve current practices.

A pragmatic architect is as capable of putting project's primary focus on the core domain with Domain Driven Design (DDD), that understanding the technical challenges of all technical stacks. She is multilingual (biz, managers, dev, ops,...).

A pragmatic architect understands that we should stop trying to model the real-world, but only what matter to our software usages instead.

A pragmatic architect understands that event sourcing is not only a technique for technical challenges like High Availability, but something that may bring real business added values.

does not guess, he measures.

A pragmatic architect doesn't like early optimizations. A pragmatic architect does not guess, he measures instead.

A pragmatic architect has both network and hardware skills. He knows not only HTTP, but he masters IP, TCP, UDP... He also tries to avoid having too many war stories, by learning from others' experiences. He also knows how multicast is working under the hood, and other stuffs like it's possible to do unicast with UDP, what is false sharing, what every programmer should know about memory,  etc. A pragmatic architect is able to understand the impacts of route flapping and network routing convergence on the systems we build. He is a real interlocutor for infrastructure guys and network engineers. He can do that because he is dramatically curious, and always willing to discover new things when he heard about it.

A pragmatic architect is a multi-threading expert, and this is why he tries to help people not to play with threads. A pragmatic architect also likes to spot the deadlocks at home, but hates to do that in production.

A pragmatic architect knows about Recovery Oriented Computing (ROC) and builds production ready systems. He tries to minimize the impacts of bugs on the system when they happen, rather than trusting the idea of a world without bug (ha, ha, ha ;-). Thus, he cares to setup some 'what if ...' workshop sessions before going under production, and to deal with exceptions at system integration points within the system he builds.

A pragmatic architect also knows and cares about mechanical sympathy. He also knows -thanks to the CAP theorem- that you can't have your cake (HA) and eat it (Utter Consistency) too! 

A pragmatic architect is still wary of benchmarks. He knows that almost all of them are done under conditions that have no relationship with what's interesting in the real-world.

A pragmatic architect remembers Schrödinger's cat when he profiles systems (and is also wary of heisenbugs).

likes 'easy in, easy out' technologies 

A pragmatic architect hates golden hammers. She constantly tries to avoid having her own ones.

A pragmatic architect likes 'easy in, easy out' technologies. That's kind of logical, cause she naturally does not like strong dependencies and coupling. And this is why she often promotes the hexagonal architecture.

A pragmatic architect is usually wary of frameworks and rather uses libraries. She tries to know when and where the abstractions will leak.

A pragmatic architect has more to propose than layers architecture only. When she proposes a layers architecture, she intentionally knows why, and is able to explain it to her mates.

A pragmatic architect knows various technologies such as LDAP, NTP, RDBMS, NoSQL, etc. She's really curious, and always willing to discover new things or paradigms.

Of course, a pragmatic architect likes, but also animates Brown Bag Lunches!

reads tons of books, but doesn't blindly apply things 'by the book'

A pragmatic architect is open-minded, and curious. He likes to break silos, and thus enjoys reading things on various other disciplines (not only IT).

A pragmatic architect enjoys to step back and raises his head; he's usually good for the job thanks to his systemic mindset.

A pragmatic architect reads tons of books, but he does not apply things 'by the book'.

A pragmatic architect attends to various IT conferences or 'geek' meetups. He's very social, and always willing to share what he has learned to the mates that couldn't attend those events. He then  spreads the words via twitter, blogs, mails, presentations, coffee breaks, etc.

A pragmatic architect may use acronyms (when he's tired ;-) ; but is always willing to explain their meaning when he sees question tags in the eyes of his interlocutors. He cares about how people receive and understand his words and messages. Thus, he's able to use tricks to re-focus his interlocutors on the core objectives when they diverge.

I already told you, but a pragmatic architect likes simplicity.

A pragmatic architect is aware of the power of humor to communicate with others (except within this current post ;-P

has no IT religion

A pragmatic architect has no IT religion and is not dogmatic. He doesn't care stupid debates like java vs. NET, etc. He's able to think out of the box, and adapts to contexts and people that will implement the systems.

A pragmatic architect cares about others point of views.

A pragmatic architect is able to convince others with a crystal-clear speech. 

But above all, a Pragmatic architect is able to adapt his positions and to challenge himself. 

Last update: November 16th 2013