Tech Aside: Architects Suck! Architecture Rocks!
Who was I?
Who am I?
- every Software Product needs to have a well defined Architecture
- there has to be a person responsible for that Architecture, it won't get created on its own
Having that said, I feel that there are two main issues about being an Architect, that need to be tackled: Level and Responsibilities.
Choosing a Level
There are multiple types of Architects - System, Solution, Enterprise, etc. I feel that they differ in Scope of their work. After all Architecture can be applied to many different levels inside a Business. It can be an Architecture of a single Product, it can be an Architecture of an Infrastructure (Cloud vs Local, appliance of Containers, choosing messaging technologies etc), an Architecture of a Business Line (that has multiple interconnected Products, that together should fulfill business goals). Furthermore I'm certain that there are different cross-cuts of all of those fields, depending on the actual Company.
As I've said, I want to stay close to the code (because that's what I love and that's what's been propelling my entire career up to this point), so my Level of choice is a Product Architect. OK, but what does it exactly mean?
In the Devoxx talk James takes on different anti-patterns of being an Architect:
- Someone that works with lots of legacy systems and doesn't promote practices that would lead to Business and Technology growth, but instead, consciously or not, promotes creation of knowledge silos, deepening the technological hole that the Company is in.
- "Technology Police"
- Someone that obsesses about technology standardization at all costs, making charts and spreadsheets of stuff that's allowed and stuff that's not allowed. Who doesn't promote the 'use the right tool for the job' attitude, forcing everyone to use the same tools for every problem.
- "Framework Builder"
- Someone that, in order to make sure no one makes bad design choices, builds an actual Framework that all the Dev Team members have to use. That forces his visions, ways and ideas onto the Team without letting them make any meaningful decisions, thus squandering the creativity potential of the Team.
- Someone that believes that Software Architecture is actually all about the documentation. That obsesses about documenting every single technical detail and, even worse, tends to come up with upfront detailed technical designs (in a form of a documentation) of entire Epics and/or Stories.
Out of those four, I was, for a pretty long time, the "Framework Builder". I've created some pretty complex and "sophisticated" Frameworks that in general, worked good. However there were 2 problems with them:
- they imposed too many patterns and practices for the developers to feel truly creative and to feel the freedom that we all love, when tackling new business problems.
- they aged badly, because they were revolving around either a concrete technology (jQuery, raw PHP (way, waay back in the day), GWT-based Vaadin, etc) or a concrete methodology (Event Sourcing, CQRS, DDD, etc)
I felt that I had to have total control over what everyone is doing and how are they doing it. I needed to make sure that no one makes a bad design decision that will cost us in the long run. And you know what? To some extent, I still feel and need all of those things, because I bear the sole responsibility for the Products I'm working on. Management doesn't want a shared, distributed responsibility, they want a single person to blame if something happens. And that's OK. We don't live in a perfect world where everyone can communicate with everyone else with utmost empathetic and understanding attitude. Every company has a chain of responsibilities (chain of command) and I am a block between the Management and the Dev Team. I shield the Team from any backlash and pressure, giving them space to actually work and create. To be able to do that, I need to employ some control measures, that will ensure high technical and architectural quality of the Product I'm responsible for. The question is, how to do that without becoming the dreaded "Framework Builder" and/or any of the other anti-patterns?
There are a couple of key points to me being and Architect:
- I've realized that building Frameworks makes no sense. We need to utilize the Frameworks that are already there and that are battle-tested and production-ready. Instead of building new ones, lets use the ones that are available, making sure that we don't misuse them and/or turn them into anti-patterns.
- I came to a conclusion that, instead of hard-coding the Architecture, I need to come up with a generic set of well-established principles that won't feel too restrictive, but will ensure that all the developers in the Team produce code that the others may easily navigate, understand and extend. Focus on modularization, proper packaging, visibility and naming conventions. Choose the right Persistence/Messaging tool sets. Promote good testing practices, like BDD. Make sure that automated tests are on the right level and of the right quality. Be an enabler for the Team, not a Policeman. Let everyone do their things the way they want, as long as they adhere to couple of high-level general rules and conventions.
- I always was and will be a practitioner. I don't believe that you can come up with something useful and practical, if you haven't used it yourself. That's why I always will strive to combine my Role as an Architect with a role of the Lead Developer. One of the most important things when establishing rules and conventions is Developer Experience (DX for short). Ideas can look good on paper, but you won't know if they work, until you'll actually try to apply them in a real-life scenario. In that sense I'd rather be called a Lead Developer responsible for the Architecture, than an actual Architect in the traditional, non-coding meaning.
- The Product has to not only look nice and slick on Demo sessions, but has to be ready for real-life production usage. That's why all of my decisions, designs and principles always revolve around performance. I tend to tackle the most performance-critical parts of the Product myself or have a very close oversight on them, performing very thorough Code Reviews of all such components and creating additional performance verification, in a form of JMH test suites.
I don't know if I'll ever want to be the kind of Architect that only goes to the meetings, works with whiteboards and tools like JIRA and/or Confluence. The kind that only draws the Architecture in little boxes that look nice to the Management. Don't misunderstand me, I don't think lesser about such Roles, they are simply not what I want to do. I love to code and I love to bring real, concrete value to my Customers. Being an Coding Architect I am right now, I can double up on that, because I can treat both the Business Stakeholders and my Development Team as my Clients and deliver them the best possible experience. I truly believe that my current set of Architectural Principles is generic enough to allow for the much needed creative freedom and can even be ported to other JVM and non-JVM platforms. I've battle-tested and tailored the Agile approach to achieve great results and to deliver features on time, on scope and on budget. I don't know what the future holds for me and I most definitely am not done learning. It can be that 10 years from now I will read this article and laugh at my own naivety and/or lack of knowledge. For now, I'm happy with the things being as they are.
Thank you for reading!
Post a Comment