The path to architecture practice – overview

There is a common understanding about the importance of conceptual integrity, nowadays in the software industry. This typically shows in conversations about this notion called software architecture.


This is good. But...


…something that has proved very typical in software development industry is to abuse concepts and technologies treating them as silver bullets and trying to over-generalize and apply them to out-of-context situations indiscriminately.


In the below posts I talk a little about some:


Modern business rules specification


Architecture is not about scalability, not even about user, it is all about usage


Help with misconceptions about eXtreme Programming


Does SOA imply that OO is dead?


It is the people, as always has been



Questions to think about:


What are the key elements of good architecture practice?


How we can tell that concepts and technologies have been pushed too much?


Which analogies from other disciplines are right for software development?


How can we prevent “take the form but not the substance” of good techniques and technologies?


How can we tell apart genuine growth in architecture practice from marketing hype?


What should you observe when hype from CMMI, MDA or agile comes to your table?