One of the many discussions we had on the training course in London recently was about the actual process of software architecture and design. There's a perception that software design is a complex process steeped in formality where you must produce a large number of diagrams drawn using a formal notation. We like to present a very straightforward and lightweight approach to software design but really the important part of the process is understanding what drives the architecture. It's about understanding the functional requirements, the non-functional requirements, the environmental constraints that are imposed upon you and the architectural principles that you want to adopt. Understanding these and how to work within them does more to contribute to successful software projects than using sophisticated modelling tools and formal methodologies. I'm not saying that you shouldn't use them, but you do need to understand the drivers so that you can make the right decisions and come up with the right design. And coming up with the right design is really what matters.
↧