Good Architects are like surfers …
Surfers are the “Cool Kids on the block”. You will easily realize this when watching movies (like Point break, especially that Anthony Kiedis singer of the “Red Hot Chili Peppers” is part of cast) or commercials or marketing videos. For an IT-Architect it would be really cool to be seen as the surfers of the IT-Business. The starting point typically is good, because IT-Architects are somehow special.
- They are essential for the success of an engagement, and often they know it
- They don’t wear suits (even in banking and insurance context)
- They tend to be open minded and direct (that might lead to discussions with others (esp. managers)
- They are focusing on solutioning to overcome the given challenges
The good news is that this analogy works quite well and in the following chapters I will explain some similarities!
Ride the waves …
Surfers ride the waves and like all-natural things no wave is like the other, but in the end it’s still a wave. For surfers it’s essential to reflect what worked in the past, because most probably this will be a good starting point for the next surf session.
Architects also ride waves, not in the ocean but rather in technology, methodology and processes. Since I started to work as an Architect, I saw a lot of them. Sometimes I feel like “old wine in new bottles”. The good news is, that those are like natural waves: same, same but different …
Just to highlight some of them:
- Thin-UIs vs. Rich-UIs: We started with really thin-UIs on the mainframe: the 3270 block-oriented terminal with very limited characters. We moved on to have rich-UIs on Windows and Linux based on technologies like MFC, Swing, Gnome. Next wave was the rise of HTML which was a thin-UI once more. Soon the expectations on usability within the Internet grew and we moved on to have rich-UIs once more based on JavaScript like Ajax, Angular, Web Assembly. You can guess what the next trend in UI-technology might be? I would bet on thin-UIs once more maybe triggered due to edge computing with limited resources like compute and energy.
- Central vs. De-Central: On the mainframe everything was per definition central. All compute was done on the mainframe and we had dumb terminals as stated already. With the next wave to a client/server architecture this changed, and we started to use the de-centralized computing power. With the rise of the cloud we moved back to central resources which are accessed via the network. Nowadays we talk a lot about Edge-Computing and using the computational de-centralized resources. This wave is strongly linked with the UI topic.
- Mono-Culture vs. Zoo: To start again with the mainframe we had a limited and standardized set of technologies and programming languages in place. One RDMS, one Queue, few Programming Languages, one central Runtime Environment. With the move to client/server and Unix this changed dramatically we had tons of different RDMS, Programming Languages, Operating Systems, Queues and decentralized runtime environments. So, we ended up having a Zoo which is really hard to maintain. The answer to this challenge was Enterprise Architecture Management including standardization. One target of this was to get rid of the Zoo and escape the “Maintenance-Hell”. The drawback of this approach is, that you sometimes loose speed and in addition small solution tend to get more expensive. So nowadays with Microservices we open Pandoras Box once more and let the teams choose whatever technology they want. The drawback of this is: we’ll get a Zoo again! I recommend waiting some time and then the next wave most probably is more standardized.
- Async vs. Sync: When it comes to communication patterns, we also can see the wave of asynchronous vs. Synchronous communication. We started with punch cards on the mainframe which where a truly asynchronous way of communication. Later, punch cards got replaced by message queues which still are asynchronous, that is by the way the best and simplest way of load balancing for centralized computing resources. With the upcoming of 3270 terminals and transactions commands the mode changed to synchronous communication. You send a command and wait for the result to be displayed to you. Event-driven compute imposed to be asynchronous again. With SOA we moved back to synchronous communication based on Webservices. With the rise of Micorservices and decoupling using asynchronous communication (in the end still queues, even if we call them sometimes differently now) is the better choice. You should always keep in mind the users of your system typically expect feedback about the transaction they just started. So, if your technical communication is asynchronous you might need to simulate a synchronous behavior out of that.
- Out-Sourcing vs. In-Sourcing: A lot of my clients started to out-source the software development. This trend started in the 90s and some of them even sold their IT departments. Nowadays as software is everywhere and gets core of their business this wave now strikes back, and they are starting to in-source software development. This wave can be seen currently in automotive industry. As software is getting core, they ramp up own teams and invest in them.
- Efficient Development vs. Efficient Application: In the past we always had limited computing resources (e.g. memory, CPU, storage) and thus the task was to write efficient software that solves the given problems with the available resources. With the rise of the cloud and increased computing power (reflected also in Moore’s law) the focus moved on efficient development to reduce the implementation efforts. With the currently emerging topic of “Green Software Engineering” the pendulum will swing back, and the time of unlimited resources (especially in the cloud) are over.
Technical excellence …
Surfers are athletes and therefore performance is critical. A talented surfer can become even better by thoroughly investing in improving their techniques. Research, learn from the best, train consistently, and remembering that there is always room for improvement.
For Architects it’s the same. They must master the technology they use in their engagements. Lifelong learning is a given and this is typically based on research, attending conferences and trainings. Learning on the job is also key and the best architects I know had great coaches and colleagues to learn from and with them. An architect must safeguard that the given functional and non-functional requirements can be met by the defined architecture and the chosen technologies as part of it. To fulfil this technical excellence is mandatory!
Learning by doing …
Surfers won’t learn surfing by reading books. For sure it’s helpful to understand the underlying physics, but in the end, you must get into the sea and just do it. Train, train, train and get on the board.
As an Architect you can read tons of published books and attend universities lectures. You will learn a lot and master the theory. In real life the job as an Architect is multi-dimensional, it’s about technology, methodology, processes and very important people. During the last 20 years I learned most by just doing things and observing senior colleagues to learn from their experience. I just want to give you some examples:
- Designing domains, services & interfaces: For an Architect it is essential to make the initial design for a bespoke application. There is no standard methodology you can follow to achieve this. Designing the domains often starts with a gut feeling, intuition, a best guess. Based on this you iterate and improve the solution. There are some methods to support you like DDD or Quasar Enterprise, but in the end, you need to know the “magic trick”.
- Performance: For almost all systems I built in the last 20 years performance was critical. The tricky part is that sometimes you need to take decisions about algorithms and implementation early without knowing the details of the actual system to build. In this often the gut feeling helps you to take the right decisions.
- New technology: Often we need to master technology that we never used before and this will have an impact on our design. For this we typically lack good literature and best practices, thus it’s up to the experienced architect to create a proper design that works.
- Software Development Process: As we work in teams, we need a proper software development process to create the system. From my point of view, there is not one-size-fits-all process. You must shape it to your actual needs. For this you need to look on several dimensions and decide what fits best in your context: People, Technology, Tools, Trainings, …
Hands-on …
Surfers must be in the water and do their job. They need to get their hands “dirty” to succeed in what they do. In addition, all great surfers work on their equipment, e.g. their boards to improve them and getting better in surfing.
With Architects it is the same. Once you live in an ivory tower and work on design and architecture without getting feedback about the impact of your design and decisions you won’t learn. Thus, I strongly recommend getting involved in the actual implementation of your design. Walking around and talking to people helps a lot. Over a coffee you can learn much more about the impact of your work, than reading books and/or emails.
Striving for perfection …
Surfers are always searching the perfect wave and for sure the perfect ride on it. For this they invest a lot of time and energy. This includes a lot of research on the best surf spots and a lot of training to be on the point once the “perfect wave” is there.
Architects also strive for perfection. Technology and Methodology evolves and thus also the “perfect architecture” chances over time and what seemed to be perfect in the past might be only okayish now. Live long learning and improving is in the DNA of many architects I know.
Be a coach …
Surfers typically help junior guys to learn how to surf and as stated already this is needed, because you won’t learn surfing by reading a book. In addition, it’s a good way to improve your network.
Architects need to spread their knowledge and the easiest way to do so is to coach junior colleagues. By the way that’s the best way to get “out of your engagement”. So, I strongly recommend each Architect to select his or her successor on the first day on the new job. In the upcoming month and years one should coach and train him or her to be able to leave the engagement at a given point in time smoothly. Besides that, you can learn a lot from the junior colleagues. They are close to academia and the latest technology, method and process trends. For me it’s a best practice to discuss with them and reflect the new stuff with what we learned in the past… once more the waves come to play.
Re-Invent yourself …
Surfers always look out for other challenges and sometime re-invent themselves. For example, some surfers wondered what they can do during winter in a skiing resort and just invented “Snowboarding”.
Architects also need to look on their profession and work on their profile. Technology, Methods and Processes are changing over time and we need to adjust or even better drive this change. Life-long-learning shouldn’t be an unknown pattern for an Architect, thus always try to improve! In the service industry this can be achieved by just moving on to other engagements and with each change one can always change roles or responsibilities. So, get out of your comfort zone and try to get better each and every day.
Team players win …
Surfing is a team sport! You “hunt in a pack” and this has several positive effects. First, you have an audience to “prove” what great ride on the waves you did. With all the social media nowadays, you need someone to make a video from your achievement. On the other hand, for riding the real big waves you need someone on a Jetski to pull you into the “big ones” and you really need to trust this guy, because you might get killed by wave if something goes wrong.
Good Architects work in teams! The typical challenges we face are big, thus you need to work together and utilize all the available skills in the team to overcome them. I strongly recommend not being a Napoleon-Style-Architect, but rather a real team player who listens to others and let the others shine. They will honor that, and you will grow!
Network is key …
Surfers need to know the best spots to find and ride the best waves. They’re typically part of the huge professional surfer community and are very well connected. Once they start to take part in a championship they are in!
For Architects it’s key to have a well working network of colleagues. This should be inside and outside of their company. For Architects it’s almost impossible to have all the knowledge they need for their job. Thus, one needs to rely on others. When you start your career it’s essential to work on your network besides the obvious content driven topics. It’s essential to know whom to contact or even better call for specific challenge. Over time it’s a best practice to invest time on a regular basis in your network to keep it active and alive. Liquid networking is a special way of doing so, that typically works very well in bar full of architects during conferences, trainings, or other events.
Sell, Sell, Sell …
Surfers need to earn their living. There are several ways to achieve this, having a sponsor, getting prize money by winning events, and sell surf-stuff. Most of the successful surfers are good in selling themselves and surf merchandise.
Architect also need to know how to sell things. There is and was always a debate how much management skills and Architect needs. My view is quite simple on that: A good Architect in a large-scale engagement needs also to be a manager to some extend and for sure he needs to be a leader. To make it more concrete: I wouldn’t recommend focusing on controlling, but an Architect should be always involved in change requests, estimations, staffing, strategy and innovation topics. A very easy way to achieve this is to sit in the same office as the project managers. I know that some Architects don’t like that, but it works … it’s almost impossible not to be involved in the important topics once you are in the same room! By the way an Architect should always keep in mind not to over-engineer the solution. This will lead to additional effort and thus cost. Good is good enough is not only a phrase.
Some Architects think it’s a good idea to make themselves indispensable in an engagement. I strongly recommend not to do so, but instead selecting a successor early as already mentioned. This is a good way to make a career by getting new and challenging roles in a different context.
Build your own brand …
Good Surfers are often a “brand”. They are well known in the community and even more important to the possible sponsors. This is essential if you want to earn a living as professional Surfer.
For Architects it’s also a best practice to build your brand. You can look at that from different angles. First: What is your specific topic? What are you well known for? Where are you an expert? You should be able to answer the question: I’m the “go-to guy” for “whatever topic”. In Architecture there are tons of topics you can choose of. Please be aware that this might evolve over time!
Second you can also work on your “visual” brand. In Germany we have the saying, that all “regular” Architects drive a SAAB Turbo and wear a turtleneck sweater. You can do the same, there are a lot of other possibilities. By the way, if you know me you should have an idea how I handle that!
Own language …
Surfers have their own language. It’s just a slang, which only surfers can understand, thus successfully excluding surfers from the rest of society. Typical terms are: Aerial, Blown-Out, Brah, Goofy-Foot, Shubee.
Architects also define their own language. Microservices, Sidecar-Pattern, Hexagonal-Architecture, . On top of that we also tend to use, tons of cryptic abbreviations that you have to learn, e.g. ESB, UML, SOA, OSS, SDLC. This makes it even worse for juniors to follow a conversation between senior architects.
Finally …
If you follow those recommendations, I would say one can clearly state that this kind of IT-Architect is comparable to a surfer! I’m glad being part of the cool guys, even as an IT nerd …
