Pattern Matching Experience - The Effective Software Architect
It's an ongoing journey...
By no means do I categorize myself as a top notch architect, but I do constantly aspire to be one, and I know a good one when I see one. Over the years I have had the privilege of working on many and diverse large scale systems. In the process I have had the honour of working with extremely talented individuals who not only are good developers, but also good architects and communicators. I have also had the opportunity to write and rewrite/refine my own code as well as, as the years pass by one gathers experience by greater exposure to the diverse systems out there. One can quickly start identifying the good and bad practices (good that you can enhance on; or bad that you should avoid), this besides other common sense approaches, are what gets used as content that will feed and grow your pattern matching library repertoire.
Credibility and Integrity
| In order to further yourself as an aspiring architect you need to gain credibility. This can be done in many ways, but the acid test is that you must talk from a position of authority. i.e. You must have solved or understood each problem context/scenario. When you recommend an action you should know it from first hand exposure (perhaps state your sources and how it relates to the current scenario). If not the chances of your advice will fall on deaf ears, as people tend to ignore others that make un-researched statements/actions that may have led them down the wrong path. (I have this wonderful saying but find it difficult to express it in public... but here goes... "We the developers share from this common pool of pure and undisputed knowledge. Treasure it, as it is sacred... but, don't dare to piss in the pool of shared knowledge", this will be a sure-fire way of decreasing your credibility... hear cry wolf... "It is better to be approximately right than precisely wrong.", people will respect you for that. |  |
The passion to make life easier for others
The universe of IT project development role-players tends to conspire with each other with the intention of succeeding. Typically, what's been observed are developers and designers stretching themselves in different ways. Some designers can go further in understanding the challenges developers face. And some developers can relate more effectively to the challenges designers face. This applies equally as well between Abalysts and Developers... Having tools where there’s an overlap, where there isn’t an absolute boundary between a design tool and a developer tool, is extremely important and helpful. It does not help if we have a gap between the different players in the lifecycle of any project. We need to constantly talk a common non-ambiguous language that is simple and to the point, but understood by all role-players.
Pattern Matching - based on facts
| In my opinion, being an architect is really about pattern matching. It’s about being exposed to enough tools and techniques of the trade that over time you start to develop a toolkit/library of different patterns that work in different situations under different contexts. This is true of software architecture and probably other types of architecture as well. Whether you build bridges or design buildings, you’re trying to apply design patterns to a given situation. You don't want to keep on re-inventing the wheel... Stand on the shoulders of those that have come before you. You also need to be able to think laterally and out of the box. Before deciding on an approach, always compare to past solutions, then evaluate possible completely new approaches, by removing many of the known assumptions. Sometimes this can lead one to questioning the base assumptions and even come up with a simpler design. | Once upon a time there was a frog, sitting on a lily pad. The frog wanted to get to the next lily pad, but the pond was filled with crocodiles. The frog started to think out loud - I wish I knew how to get to the next lily pad - when the wise old Owl sitting above in a tree heard the frog and said - why don’t you fly? I can’t fly, exclaimed the frog. The Owl then explained to the frog that if she could dream it - it would happen. The frog believing the all knowing wise owl, decided to give it a try. Of course the frog did not fly and fell into the middle of the pond, and betwixt all the crocodiles. Looking up at the owl the frog anxiously remarked, you silly owl, you knew that I could not fly!! The owl simply hooted - I deal in concepts, you have an implementation problem.
 |
Pay your dues
One's role becomes essentially a cross-cutting one. By that I mean understanding how customers are using multiple products together, and then asking myself what patterns I see. What’s the smallest possible thing I could suggest to a product team that they could do to re-architect their product in order to minimize seams with other products? Or from a business perspective, what’s the smallest possible thing I could overlay on these products to add value for our customers, and advantage our solutions in the market. At the very highest level, my advice to aspiring architects is, don’t jump in too quickly. You need to do your time as a programmer to understand the different patterns that are out there, and recognize the attributes of a well-architect system, in order to raise yourself to the next level of abstraction in the solutions you’re building. No task should be to trivial to be undertaken.
Experience - Staying in touch
It especially pertains to the things that nobody at the architecture level likes to think about. For example, performance characteristics, IO characteristics, reliability characteristics… You might have had experience with a system that works well given a certain level of complexity, but if used in a more dynamic environment it could be too fragile. You only learn that through experience.
It’s really an interesting combination. The easiest and most natural thing is to just talk to people in your sphere of influence, and gain exposure to different technologies as a part of your job. But in order to be successful long term, you need to stay in touch with the trends and what’s going on externally, especially staying in touch with what customers or individual users are saying and doing.
Awareness of peers and the Industry
| Spend a fair amount of time reading blogs, tracking specific influencers that have very interesting voices both related to your products and completely unrelated to your products. Go to a combination of ‘head’ and ‘tail’ conferences. Attend a few where the "known" industry influencers congregate. These allow one to track major competitive issues, or at least the outward presentation of what competitors might be saying and doing. But also enjoy the tail conferences, where you can get a closer-to-the-ground perspective on what’s really happening. Meet people who are just out of school, who have startups and understand the kinds of technology choices they’re making and why. Read credible mentor blogs as well as books. Keep on working at it... |  |
Defining characteristics of an effective software architect
At the highest level, my advice to an aspiring architect is find the right balance of focus on internal and external trends that will give you the perspective you need. The most effective architects I’ve dealt with are the ones who’ve paid their dues. These are the architects who’ve spent time in the trenches building and debugging fairly complex systems. They are not afraid of being wrong and will admit when they do not, but the are also quick learners. You can learn a lot about how things work by fixing other people’s bugs. When something fails and the person has left the company, you can learn a lot by either reverse engineering or looking at the documentation. The more systems that you can learn from the inside out, the more you can develop an understanding for bad practice and good practice design patterns. As I mentioned earlier, it’s this library of patterns in your mind that will define you as an architect.