What things Software Architect should know? Effective Java was the first book I’ve read whose table of contents had read like programming commandments. The rest of the book provided commentary and examples, but the section headers read like axioms to program by. I found a similar book in 97 Things Every Software Architect Should Know. 97 Thingis a collection of 97 short essays from a number of architects on topics such as soft skills, leadership, and software architecture. The table of contents for 97 Things also reads like commandments or axioms. 97 Things Every Software Architect Should Know is a collaborate effort from numerous contributors. The project wiki is available here. Below are 101 axioms taken from the different essay titles from the project. The axioms have been rearranged from the original order provided online to provide context, and in cases edited for legibility.
Software architect is a general term with many accepted definitions, which refers to a broad range of roles. Generally-accepted terminology and certifications began appearing in connection with this role near the beginning of the 21st century.
With the increased popularity of multi-tier application development, the choices of how an application can be built have also increased. Given that expansion, the risk that a software development project may inadvertently create an end product that in essence already exists has grown markedly. A new 'Software architect' role became necessary during software development.
The software architect concept began to take hold when object oriented programming (OOP) was coming into more widespread use (in the late 1990s and early years of the 21st century). OOP allowed ever-larger and more complex applications to be built, which in turn required increased high-level application and system oversight.
The main responsibilities of a software architect include:
Limiting the choices available during development by
choosing a standard way of pursuing application development
creating, defining, or choosing an application framework for the application
Recognizing potential reuse in the organization or in the application by
Observing and understanding the broader system environment
Creating the component design
Having knowledge of other applications in the organization
Software architects can also:
Subdivide a complex application, during the design phase, into smaller, more manageable pieces
Grasp the functions of each component within the application
Understand the interactions and dependencies among components
Communicate these concepts to developers
In order to perform these responsibilities effectively, software architects often use Unified Modeling Language and OOP. UML has become an important tool for software architects to use in communicating the overall system design to developers and other team members, comparable to the drawings made by building architects.
- Prefer principles, axioms and analogies to opinion and taste.
- Don’t put your resume ahead of the requirements.
- Requirements are not the measure of success but the beginnings of a conversation.
- Simplify essential complexity; Minimize accidental complexity.
- Make sure the simple stuff is simple.
- Chances are your biggest problem isn’t technical.
- Warning, problems in mirror may be larger than they appear.
- Communication is king; clarity and leadership its humble servants.
- Lead by influence.
- Skyscrapers aren’t scalable.
- You’re negotiating more often than you think.
- One line of working code is worth 500 of the specification.
- There is no one-size-fits-all solution.
- Commit-and-run is a serious crime. Respect your colleagues.
- Continuously integrate.
- Understand the business domain.
- Business Drives.
- Use uncertainty as a driver.
- Prioritize challenges to drive architecture decisions.
- Change is a constant; architecture needs to be adaptable and the architect needs to be a change driver.
- The user interface drives the user experience.
- For the end-user, the interface is the system.
- Architects must be hands on.
- If you’re unwilling to be hands-on, maybe you should keep your hands off.
- If you design it, you should be able to code it.
- Before anything, an architect is a developer.
- The title of software architect has only lower-case ‘a’s; deal with it.
- Architects focus is on the boundaries and interfaces.
- Software architecture has ethical consequences.
- Architecting is about balancing.
- Share your knowledge and experiences.
- Take responsibility for your decisions.
- There is no ‘I’ in architecture.
- Work on thy soft skills just as much as on your hard skills.
- An architect’s responsibility never finishes after the architecture is created.
- It’s never too early to think about performance.
- Application architecture determines application performance.
- It’s all about performance.
- Give developers autonomy.
- Value stewardship over showmanship.
- Find and retain passionate problem solvers.
- Empower developers.
- Don’t control, but observe.
- Scope is the enemy of success.
- “Perfect” is the Enemy of “Good Enough”.
- Challenge assumptions – especially your own.
- Simplicity before generality, use before reuse.
- Reuse is about people and education, not just architecture.
- Get the 1000 ft view.
- Programming is an act of design.
- No, the goal is not the code nor the design.
- Avoid scheduling failures.
- Time changes everything.
- Everything will ultimately fail.
- Context is king.
- Engineer in the white spaces.
- Choose frameworks that play well with others.
- Try before you choose.
- There can be more than one.
- Prepare to pick two.
- Kevlin Henney and O'Reilly announced today that the web site "97 Things Every Software Programmer Should Know" is now public and open for contributions.
The "97 Things Every Software Programmer Should Know" book is part of a larger series of books which already includes "97 Things Every Software Architect Should Know" and "97 Things Every Project Manager should Know" both of which you can find at a book store or order from Amazon.com. The books are published by O'Reilly the folks that do the cool animal cover books. I edited the Software Architecture book and blogged about it back in February.
- Heterogeneity wins.
- If there is only one solution, get a second opinion.
- One alternative is a trap, two are a dilemma, three are freedom.
- Fight repetition.
- Don’t stretch the architecture metaphors.
- Stretch key dimensions to see what breaks.
- Record your rationale.
- Start with a walking skeleton.
- It is all about the data.
- Control the data, not just the code.
- Focus on application support and maintenance.
- You have to understand hardware too.
- Your system is legacy, design for it.
- Understand the impact of change.
- Don’t make worlds, make containers for worlds.
- Great content creates great systems.
- Choose your weapons carefully, relinquish them reluctantly.
- Shortcuts now are paid back with interest later.
- Your customer is not your customer.
- Don't be clever, be deliberate and thoughtful.
- It takes diligence.
- Software doesn't really exist.
- Software should be invisible.
- It will never look like that.
- Pay down your technical debt.
- Great software is not built, it is grown.
- You can’t future-proof solutions.
- Know all the rules – so you know which ones you’re breaking.
- Design for needs not wants.
- Consider application failures and design for ease of recovery.
- Not all problems are solved with a layer of abstraction
What is really cool about these "97 Things" books is that they are as close to open source as a book can get in my opinion. Each book contains contributions from people all over the world. Every contribution is licensed as Creative Commons, which is kind of like open source for literature. Each book contains 97 short essays from experts in a particular field.
The "97 Things Every Software Programmer Should Know" contains essays on every thing from how to improve performance of your software to advice about reading more from the humanities in order to improve your programming. Each bit of advice is written by a professional software programmer for other professional software programmers.
There are a lot of authors in this kind of book and you can be one of them! Anyone can make a contribution to the growing list. When the editors feel there are enough contributions, they will chose 97 of the best ones and put them in a paper book. This gives experts all over the world, who know programming inside and out and have really great advice, the chance to share their wisdom and get published for the first time.
Check out the growing list of submissions and learn a lot from people all over the world about the best practices in software programming. If you have an axiom or idea for a contribution, simply sign up to the wiki and submit it. If your contributions is poignant, coherent, and unique you may be published in a book from O'Reilly!
In 97 Things Every Software Architect Should Know, Richard Monson-Haefel collaborated with over two dozen authors to collect 97 axioms of software architecture. In this presentation he has distilled knowledge from his own experience and from personal interviews with the World's best software architects to define 10 principles every software architect should know in order to be effective.
About Richard Monson-Haefel
Richard Monson-Haefel is the author of Enterprise JavaBeans (Editions 1 - 5), Java Message Service and one of the world's leading experts and book authors on enterprise computing. He was the lead architect of OpenEJB, an open source EJB container used in Apache Geronimo, a member of the JCP Executive Committee, member of JCP EJB expert groups, and an industry analyst for Burton Group researching enterprise computing, open source, and Rich Internet Application (RIA) development. Today, Richard is the VP of Developer Relations for Curl, Inc. a RIA platform used in enterprise computing. You can learn more about Richard at his web site monson-haefel.com.
Reference
Computer Architecture Questions on Technical Interview
Top 30 questions you should ask the interviewer
Interview Questions for Senior and Mid Software Engineers
97 Things Every Software Architect Should Know
Book author site monson-haefel.com
Summary
Check this out very cool podcast about Simplicity in Architecture design. This article present book, good advices that need to be well known by software architects. Every Software architector also have to communicate effectively, not only to understand the business needs, but also to advance their own architectural vision. They can do so verbally, in writing, and through various software architectural models that specialize in communicating architecture.
What software architect should know?
- People are the platform
- All solutions are obsolete
- Data is forever
- Flexibility breeds complexity
- Nothing works as expected
- Documentation is the universal source code
- Know the business
- Maintain the vision
- Software architects should also be coders
- There is no substitute for experience
