Software Architecture and Management

Business should understand the risks that are involved when you put speed in front of architecture. I worked on a project that was considered such a cash cow that they rush to get the application out without considering the architecture. When it was deployed, soon we noticed several problems:

• Complexity - it took a long time to fix problems due to the fact that we did not had a domain model and the business rules where scared throughout the code
• Poor performance - the application was slow
• Scalability - we had to invest a lot of money in hardware because the application was not scaling to the amount of users

Ultimately, the team had to explain to the business why we had to take a long time re-factoring the code. Not only we jeopardize architecture over speed, but we missed to explain the causes and effects of this decision. I stumbled on a book in Barnes and Noble named: 97 Things Every Software Architect Should Know. If the team would have applied some of the followings, the project would have been such a great success:

• Architecting is about balancing
• Application architecture determines application performance
• It's never too early to think about performance
• Shortcuts are paid back with interest later

All these items are very true indeed and I am taking them in consideration in my current and future projects. Eventually the company was hit hard with the US recession and Miami's Real-estate. The entire team was laid off.