Introduction
A long time ago, when the internet access was limited to the armies and universities, the teenagers had very little reliable information available about the relationship with the other sex. Our knowledge was based on rumours and hearsays. One day, one of our classmates told us that it found at home, a copy of the Kamasutra. Very quickly, he learnt by heart all the positions described in this book and enjoyed miming them before us. We were impressed and stupid as a teenager in the 80's; we thought that his first relationship would be a firework for his partner and the hearsay of this unforgettable moment will provide him all the girls of our high school.
Unfortunately for him, his first relationship was a disaster. His ephemeral conquest told the other girls of the school that he was a deviant, a sex maniac and because of the name she made to him, he had to wait for the university to find another girlfriend.
The story
A few years later, our company got a contract to support an English governmental organisation in architecture design. For this project, the organisation had to hire an IT architect, and during our first day on the project, we have been asked to be present to the job interviews and give our feedback on the candidates.
The complete interview was made up of three steps.
The first step was an interview led by an RH person who asked some technical questions written on a page. The first question on the list asked the candidate to give the name of five message patterns found in the book Enterprise Integration Patterns. We were surprised by this question, wondering why the question referred to this book and not another one. Moreover, we thought that an architect could be aware of a communication channel between a consumer and a provider, but ignore it is named "Message Channel Pattern" in that book. Also, the candidate can master the XSL transformation but ignore that Hohpe and Woolf named this technology a "Message Translator pattern". The interviewer who has no technical skill was unable to evaluate the knowledge of the candidate and just checked if he responded matching the answers on her page.
For the most accurate (or luckier) candidates, came the second interview led by two technical people. The first question asked of the candidate was: "What patterns do you use in your projects" and once again, the candidate had to name some pattern he/she used. The more you named the best you were. We were amazed because the interviewers did not ask any question about the main concepts used when designing an architecture: relationship with the stakeholders, the legacy integration, the scalability, the reliability, the context management, the different protocols used, the coupling between services, the data management and all the other concepts used in IT architecture. They just asked a question about design patterns and DevOps.
The last step of this process was an interview with the project manager. That day, we had the opportunity to talk with her and understand the team's obsession with design patterns. We reported our comments about the questions asked of the candidates. When we started talking about integration and services, she claimed to have a strong development background but confessed a weak skill on integration and architecture design. However, to compensate this confession, she immediately claimed that she read "a lot about Enterprise Integration patterns" and explained that integration and service-based architecture are not a big deal if you can find out the right patterns to represent the exchanges between the systems to integrate. We replied that if some parts of architecture could be described with design patterns, it requires broader such as the conformance with business services, scalability, service granularity, or reusing. So, if the design pattern concept could be an effective tool, it did not cover the multiple facets of the architecture and the integration design.
She coldly replied that her company promoted a wide use of design pattern as an industrial process for the development and the architecture and added in the same sentence that the design pattern concept is good protection against the hare-brained ideas and unstructured works of the architects. Glooouups.
No need to say that after 2 or 3 similar conversations, days of tension and considering the team management's lack of willingness to collaborate with us our inability to provide a good hand over or architecture design support, we stopped our collaboration with the project.
Design Patterns which position?
In the sixty's, when Christopher Alexander formalised the concept of design patterns, he expected to bring easiness in the repetitive tasks during the architecture design. He never aimed to stop neither the architects 'creativity nor to limit their capability to think differently.
The same rules apply to IT. Design Patterns are a nice way to formalise one of the solutions to a repetitive problem in the architecture design (Building or IT).
So, the IT architect's mission is to understand a technical or a business requirement, design or identify a solution that could fill this requirement. He/she must evaluate which technical solution is the most accurate to the customer context and consider additional constraints such as the future evolution of this context. Then, if his/her design matches a well-known pattern, the architect can use it "as a convention" to make the solution quickly understandable by the other architects or developers.
Giving a name to this solution is the cherry on the cake, but certainly not the core of the architect work. An architect works with more complex concepts than just a list of design pattern names. He is responsible for the architecture adequation with the customer requirement, its adaptability, scalability and reliability. As far as we know, these concepts are not covered by the design patterns. Strong knowledge of the basic architecture concepts is required to use the design patterns efficiently. Starting by choosing a design pattern puts the car before the horse.
So, the ones, who use the design pattern as the basis of their work, is exactly in the same situation than our classmate who thought the intercourses in term of positions but ignores what are is the touch, the feeling, the pleasure and the love. When they think about architecture, they imagine it as a pattern design list and ignore the realities of the topic.
For many years, IT discussions, seminars or exhibitions were swamped with design patterns talks. When a new technology emerges, experts and specialists race to publish books of patterns that demonstrated their skill and hindsight on that technology. Books such as enterprise design patterns, enterprise integration patterns, Java design patterns, SOA patterns, microservices patterns offers hundreds pattern description pages in modern terms, but without real innovation, compared with the original "Design Pattern" book published by the Gang of Four in 1994. If the technologies progress, the scope of possibility gets wider, but the core of the topic remains mostly the same.
Today, IT architecture projects turn into a list of design patterns to apply without any global vision of the architecture objectives. The most depressing is to be said: " Which pattern do you want to implement?" when you suggest to your colleagues an alternative view of architectural design. Our interlocutor is unable to think that a design could be something not already classified in a design pattern book.
Thinking this is the end of the architectural creativity. Alexander, Gamma, Helm, Johnson, Vlissides, Hohpe and Woolf must be sad seeing how their creative works have been distorted to limit our creativity.
Conclusion
Like a virgin reading the Kamasutra, the design-pattern-oriented zealots mix up the architectural concepts and the name of the concepts, deep learning on these concepts and the result of this hard work. Like our classmate who called himself "Don Juan", they call themselves "Architects". We think that the result of this misunderstanding has a part in the denigration of the architect role and knowledge and hope that underlining this confusion could help us to focus our efforts on the right concepts in architecture.
Paul Perez
IT Architect at Pymma