The Pragmatic Architects Creed … no thank you

I got informed about a new deliverable from the folks from Pragmatic Enterprise Architecture: The Pragmatic Architects Creed. They collected a list of statements about architecture and ask you to sign it so you can show your support.

Since this felt like a good thing, I headed over to the list to sign it. Luckily I decided to read it first before I would sign it. In my opinion, most statements are too generic, some are plain wrong and only a small number qualify for my signature.

Here is the list of statements with my comments inline. See for yourself if you agree or not, leave a comment if you want to share some of your thoughts.

I put the interests of any organisation I work for above the personal or siloed interests of the individual that employed me.

Euhm … perhaps … never? As an architect it is my responsability to design a system that realizes as much of my clients wishes as possible while staying within the budget, time frame and the boundaries set by the environment. If that client is a business unit manager, I should only follow that manager’s wishes. If the manager asks me to try and go around some limitation set by the organization, than I will do so. It is up to the organization to set the boundaries.

If I wouldn’t do that, I would not be able to build a trust relationship between the client and me. My client would not experience me as someone who is helping him to achieve his goals but as someone sent from an outsider to make it difficult to reach his goal.

If the environment, the organization, wants to influence my design to make sure it serves the greater good, they have to do so in advance by setting rules. At a different moment, they can even hire me to do that. This is the role building regulations have in modern societies.

But honestly, as an architect I can’t serve two masters with potentially competing visions.

I can vehemently agree with someone about subject/point B when I have only recently vehemently disagreed with the same person about subject/point A.

I agree with this one. But is this limited to architects? To me this looks like a credo valid for any professional in any industry.

I love to be proved wrong.

Whoever claims he or she loves to be proved wrong, is lying. Nobody likes to be proven wrong. I do like to learn from other people and I am willing to adjust my ideas or statements whenever needed. Being proven wrong is never a good reason to stop learning or become unreasonable.

I relate new things that people do not know to . things that people already know.

I agree but again think this is a generic credo for any professional in any industry.

I spend more time understanding a problem domain than determining a solution.

Why? I don’t understand this one. If the problem domain is simple and the solution complex, I’ll spend more time thinking about the solution. I don’t see how you can objectively see this as a credo.

I stand up and give an unpalatable truth when no one else will, even though it may mean I lose my job.

Please do so, that frees up a spot for me 😉

But seriously, depending on the “unpalatable truth”, the context and the involved players, I’ll speak up or stay silent. I do take my responsability as an architect and I often do tell people things they don’t want to hear. At the same time I am not trying to improve everything around me nor do I stop people from learning from their mistakes.

I constantly ask myself and others; Why?

Nothing to add, I agree.

I see patterns and structure in everything from traffic congestion to Pop Music.

Given the previous credo … why? Why would it help me, my clients or the profession in general if I see patterns and structure in everything from traffic congestion to Pop Music? As an architect I must have a solid understanding of patterns and structure, those are at the core of the profession, but there is no need to see them in everything around me.

I can see disagreement between people when those people think they are in agreement.

This is a good one in fact. All to often I see people agree when they are in fact talking about two different things. As a person who has often more expertise in the subject, I see it as my duty to inform them they actually disagree.

I can abstract any thing or idea to a logical and conceptual level.

A solid understanding of idealization/realization is a must for every architect so I will agree with this one. I do feel a bit uncomfortable with the words “any thing or idea” however.

I never, by admission or omission, lie.

I would have agreed if it wasn’t for the word “never”. You can help people if you sometimes lie to them. Lying should be an exception however and must never harm. But as Robin Williams, playing the role of Theodore Roosevelt, said: “Sometimes it’s more noble to tell a small lie than to deliver a painful truth.” (

I know the difference between a Model, a Metamodel, and Metametamodel.

Basic knowledge for any architect, I agree.

I know the difference between layers of abstraction; Contextual, Conceptual, Logical, Physical.

Is this a more generic version of the one about logical and conceptual level? I think so. I still agree.

I know the difference between Architecture, Design & Construction

One can start a civil war by discussing about the difference between “architecture” and “design”. So I challenge the author of this statement to explain the difference to me. Oh, one catch, the difference has to be described in a scientific and objective way. Definitions like “design contains more detail” or “architecture is about managing risk and cost” won’t cut it.

Writing Requirements … is HARD

An interesting bit from a summary from a Keynote by Martin Fowler:

Requirements gathering is also very tough on large projects. Martin provided an interesting comparison between writing requirements documentation and writing books. Writing a book requires a very large investment of time and energy. Even after peer reviews and feedback from professional editors, the author still is not always successful at communicating his/her intended message to the audience. His point was that if authors have a hard time doing this with books, imagine what it must be like to capture the requirements around a complicated business application given far fewer resources.

If a professional author is not always capable of communicating his/her intended message, what chance does the business have in getting their requirements across to IT with far less time, expertise and resources.