A great software architect needs to master both sides of the architect’s coin: business and technology
While it is important, even critical, to stay abreast of the latest trends and technologies, this should never happen at the cost of the customer. Always put the customer’s long-term needs ahead of your own short-term needs and you won’t go wrong.
Learning to treat people with respect, and learning give them the benefit of the doubt, is one of the core skills that turn a smart architect into an effective one.
All too often, software architects sit in their ivory towers, dictating specifications, technology decisions, and technology direction to the developers below.
Be sure to have a digital camera with you at all times (in order to take a picture of a whiteboard after a meeting).
One thing most software architects fail to realize is that a software architect is also a leader. As a leader, you must gain the respect of your co-workers to work in a healthy and effective environment. Keeping developers in the dark about the big picture or why decisions were made is a clear recipe for disaster.
By asking for the intended value of a requested feature or requirement, architects are able to address the real problem, and hopefully provide a better and cheaper solution than that suggested by the client. Arrange workshops and meetings where the architects focus is on customer needs – helping the customers to answer the “why” question.
Experienced architects understand that they need to “sell” their ideas and need to communicate effectively in order to do that. Standing up automatically communicates authority and self-confidence. You command the room.
No design is perfect from the start; all designs need to be modified as they are implemented. If you are also a developer on the project, value the time you spend writing code, and don’t believe anyone who tells you it’s a distraction from you work as architect.
Commit and run is a crime because it kills flow. It’s one of the most common ways for a developer to try to save time for himself, and it ends up wasting other people’s time and is downright disrespectful. Why? Usually because it takes too long to build the system properly or to run the tests. Invest time in making the system fast to work with.
The architect, in conjunction with development management, must create and nurture the means for regular, ongoing information feedback loops. A way is doing frequent releases of working software to the business starting early in the project.
A good architect should lead by example. He should be able to fulfill any of the positions within his team, from wiring the network and configuring the build process to writing the unit tests and running benchmarks. It’s difficult to imagine how team members can have confidence in their architect if the architect doesn’t understand the technology.
“Fast” is not a requirement. Neither is “responsive”. Nor “extensible”. The primary reason why not is that you have no objective way to tell if they’re met.
This sentence want to remember the importance of having requirements that can be measured (example: “Respond under 5 seconds”).
Specifications alone have no value. The ultimate goal of a software project is a production system. A software architect must always keep an eye on this goal, and remember that design is merely a means to an end
It is perfectly respectable for an architect to ask for help from the team. The team should feel it is part of the solution, but the architect should chair the discussion and identify the right solution(s).
The architect does not have to make the decision, he or she merely orchestrates the decision making process.
When I went to DevWeek 2012 I had the opportunity to discuss with a speaker (that was an senior architect) and I remember very well how much he underlined the importance of his team. As usual, it is all about trust.
Negotiating skills and a knack for influencing people can be valuable resources.
Every software architect should know and understand that you can’t have it all. It is virtually impossible to design an architecture that has high performance, high availability, a high level of security, and a high degree of abstraction all at the same time. There are several tools available to architects to determine what the tradeoffs should be when designing an architecture. Two popular methods are:
- Architecture Tradeoff Analysis Method (ATAM)
- Cost Benefit Analysis Method (CBAM)
Most software developers are optimists. Natural pessimists on development teams are often unpopular, even if they are consistently right.
Architects pour themselves into each design. Criticism of your creation feels like criticism of you. Defensiveness is easy. Learning to stop it is hard. Pride in our accomplishments is easy.
How can we see quality? Aggregates large amounts of data and multiple metrics, such as method count, class fan out, cyclomatic complexity. Once a suitable view is available, software quality becomes a little less subjective.
Accepting the fact that programming – or more precisely software development – is a processes of discovery and learning not a process of engineering and construction, is fundamental to bringing software practices forward.
As a developer you rarely get the time to sit back and really look at how the whole system fits together. AS an architect, this is your main focus. If you are doing a great job of being an architect, you really shouldn’t have enough time to interfere with developers. You do need to watch closely enough to see that the design is being implemented as intended. It is reasonable to make suggestions when you see people struggling, but it’s even better if you create the environment where they come and ask you for suggestions.
We say it to ourselves: keep it simple, stupid. We say it, but we don’t do it. When an architect enters a project, there is an understandable desire to prove his or her worth. Showmanship, the act of appealing to your audience, is important in marketing, but it’s counter-productive to leading a software development project.An architect must act in the best interests of his customer and not pander to the needs of his own ego. The simple problem-complex solution trap can be an easy on to fall into because we like to demonstrate our knowledge.
Never forget that you are playing with other people’s money.
Software architecture is a craft, and it certainly takes practice and discipline to achieve success in the field.
Every time I make a decision about how a program behaves, I am really deciding what my users can and cannot do. It’s not ethical to worsen the lives of others, even a small bit, just to make things easy for yourself. It’s OK to release an application that only does a few things, as long as users value those things enough to pay for them. In fact, the earlier you release your application, the greater the net present value of the whole thing will be.
To be an effective software architect you must understand the basic architecture and design patterns, recognize when those patterns are being used, know when to apply the patterns, and be able to communicate to other architects and developers using them. It is also important to be aware and understand the various anti-patterns as well. Don’t let your desire to exhibit design pattern knowledge could your pragmatic vision.
Sometimes the most important decisions are not about what you put in, but rather what you omit.
The architect should concede to good ideas and cultivate an atmosphere for ideas to grow. It is an open mind that will succeed in architecture. To the extent your responsibilities allow, you should do everything possible to empower your developers. Protect developers from non-essential parts of their job. Too much paperwork and too many office chores add overhead and reduce their effectiveness.
It should be made clear to you, your managers, developers, and other software stakeholders why one solution was chosen over another and what tradeoffs this entailed. Benefits:
- It forces you to be explicit about your reasoning in order to verify that your foundations are solid.
- It can be used as a starting point to re-evaluate a decision when the conditions that influenced it have changed.
Assumptions should be visible and explicit for the sake of posterity and for future re-evaluation. It is even more critical to make sure that any assumptions that aren’t based on relevant empirical evidence be validated before a decision is finalized.
The best and easiest way of working through it is to attempt to explain it to another person. We really want to share our knowledge and experience to help the industry progress; we also realize it helps us to understand and correct it.
Since over 80% of an application’s life cycle is spent in maintenance, you should pay a lot of attention to the problems of support and maintenance when you’re designing. Make the support lead a core part of the team. Involve a support lead with the planning for the application support. Design such that the learning curve for the support personnel is minimal. Traceability, auditing, and loggin are crucial.
Remember this: when you try to guess at future requirements, 50% of the time you’re wrong and 49% of the time you’re very very wrong. Get the application out the door on time and wait for feedback to generate real requirements.
Don’t give in to the temptation to make your design, or your implementation, perfect! Aim for “good enough” and stop when you’ve achieved it.
The business is our reason for existence. Show the business domain experts the respect you expect to receive.
Don’t use a pattern in your design that you haven’t personally implemented before. Don’t rely on a framework that you haven’t coded against before. Don’t use a server that you haven’t configured before. If your architecture depends on design elements that you haven’t personally used, there are a number of negative side effects: you won’t be able to give good estimate, you will not know the pitfalls to avoid when using the elements and you will lose the confidence of your developers. When they ask questions about the design and you aren’t able to give solid answers, they will quickly lose confidence in you and your design. Before anything, an architect is a developer.
Ingenuity is a key trait of successful architects. However, an equally important characteristic of the activities of a successful architect is diligence. It is an exercise in perseverance and paying the right amount of attention to each task and each architectural goal of the system.
You should not claim that an architectural decision has been made until the following two conditions are met:
- A decision has been put in writing because architectural decisions are rarely trivial. They must be substantiated and traceable.
- A decision has been communicated to the people who execute it and the people who will be affected directly or indirectly.
Clever software is expensive, hard to maintain, and brittle. Don’t be clever. Be as dumb as you possibly can and still create the appropriate design.
You need to carefully select your development team and diligently protect it once assembled. Good developers are often strongly motivated by recognition. Use this fact to your advantage and acknowledge stellar performances. Finding great developers is difficult; letting people know they are valued is not. Don’t miss simple chances to build morale and boost productivity.
Grady Booch: “All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change”.
An effective architecture is one that generally reduces the significance of design decisions.