Transcendental Architecture

Vor ein paar Jahren habe ich eine Anleitung für angehende Software-Architekten geschrieben, die ich gerade wieder entdeckt habe. Der Text richtet sich an Architekten, die zwar Karriere machen wollen, sich aber die Hände nicht mit den vielen Details schmutzig machen möchten. Wenn man dieser Anleitung folgt, kann man Karriere, Können und Verantwortung weitgehend entkoppeln.

– irony on –

The basic problem with software architecture is that there is normally a moment in time when the actual software is finished and has to meet the requirements and expectations of reality. This is the decisive moment, when it eventually turns out whether or not the architects have done a sufficient job. Quite often, it is possible to blame somebody else (e.g. the developer, management or simply the buggy frameworks) or the software is shelved before delivery but sometime the architect is identified as the root of the problem and there is no escape left. Although, normally not devastating for the career, being held responsible for a bad architecture can be a quite depressing moment in the architect’s life.

Assuming that every architect wants to avoid these ugly moments of guilt and disillusion, how can he manage this? The answer is quite simple: take it to the next level and move from architecture to transcendental architecture. The benefit with transcendental architecture is that it will never (and never really means never) be validated against reality but the architect can shine in all kinds of meetings, explain his brilliant thoughts and make an impressive career based on his work.

Creating a transcendental architecture is simple and can be achieved in a few simple steps:

  • Search for one of the tough problems that seems to be important to your company but that has some very fundamental issues preventing a solutions. Examples are solving a route optimization problem in linear time, making customers upgrade to new versions of your software although upgrades are expensive and provide little new features, transmit a signal between Europe and the US in a few nanoseconds or make software projects completely predictable. Do not be a wimp and ignore the part of your brain that says, “there is no solution to this problem”. You are approaching transcendental architecture; this is not the time for doubts.
  • Chose a very bold name for your new architecture and put at least a few buzzwords in that appeal to management, e.g. “Secure Programming Framework”.
  • Now you need to create a PowerPoint presentation that contains your pitch and is used to sell the idea to management. Do not create any written document because this bears the risk that people read it and start reasoning about your proposal - and the only thing you do not want to have right now is people having doubts. Your PowerPoint show must be well crafted and should not contain a single word on how you want to solve the problem but it has to excessively explain the problem with all the bad impact the company will suffer in case it is not solved. Take some words from the company strategy (if present) and put them on the slides of your presentation to increase credibility even more.
  • Present your idea to some top executives and promise to address the chosen problem with it. Directly provide a proposal for a project setup with a management steering (containing all the people you are just presenting to) and at least four different work streams. It is important to think big here, because your idea is much more convincing if you provide a plan for execution and ask for significant resources to develop the architecture. If you do not require at least 20 people contributing to the architecture definition, management will get doubts whether you can really address such a big problem with so little people.
  • After you received the go from management, it is time for developing the collaterals; here you need to create the notion that something very big is going on in your project. To achieve the goal of a transcendental architecture you need to ensure that your concepts can neither be implemented nor be discussed or validated - that is the reason why we call it a transcendental architecture. This can easily be achieved with again a few very simple steps:
    • Create new terms for well-known concepts. Use “adaption point” for “interface” or “foundational executor” for “runtime”. Create many of these terms because this minimizes the number of people who can talk about your topic to yourself and your team. Additionally, new terms create the notion that you created something novel, never seen before.
    • Explain all your new terms in a meta-cyclic manner. Do not say “an adaption point is an interface” but say “an adaption point can be used to access code running in the foundational executor and helps people to adapt their software at this specific point”.
    • Fill your material with paradoxical statements like “our solutions allow generic but specific behavior”. The benefit from such kind of statements is that you can later derive every other statement from them; because of their paradoxical nature, all conclusions are true. For people less trained in logical thinking, this enforces your image as a very intelligent and brave architect all others are simply confused and will stop asking questions.
    • Create some high-level Visio diagrams that support your statements, for example draw a box labeled “generic” and another labeled “specific” and connect them with a dotted line.
    • Again avoid written text but deliver only PowerPoints. This refers to all kinds of material including meeting minutes; never use Word, Pages or Notepad.
  • After the collaterals are finished, try to get on the agenda of all architecture meetings in your company and present the material to everybody you can get hold of. If people ask for concrete stuff, invite them to participate in the work streams. If people are silent, tell them even more about your great idea.
  • You are now prepared to create a group of devotees following you and your idea. Throw all people out of your work streams that raise doubt or ask for concrete implementations. With this continuous and evolutionary selection process, you should be able to form a consistent and coherent group of zealots following you and spreading the word of your transcendental architecture concept in the whole company. The best thing that can happen is that people connect your name with the concept and talk for example about “Alfred’s concept” (assuming your name is Alfred).
  • Every time someone tries to implement your idea - which should normally not happen because people cannot understand it due to its transcendental nature - invite him to meetings and explain that he has not understood the full depth of your concept. Repeat this until he either converts to a believer of gives up.

If you follow this advice, you can have years of interesting fun, career growth and the guarantee that you will never be blamed for any mistake. It is always the others who are not able to implement the great concept, it is never the concept that is wrong.

– irony off –