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


http://blogs.msdn.com/marcod/archive/2004/08/01/204336.aspx


 


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


http://blogs.msdn.com/marcod/archive/2004/07/30/202733.aspx


 


Help with misconceptions about eXtreme Programming


http://blogs.msdn.com/marcod/archive/2004/05/30/144717.aspx


 


Does SOA imply that OO is dead?


http://blogs.msdn.com/marcod/archive/2004/06/07/150420.aspx


 


It is the people, as always has been


http://blogs.msdn.com/marcod/archive/2004/03/30/103704.aspx


 


 


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?


 

Comments (5)

  1. In an recent presentation, I heard the presenter emphatically referring to someone else code as “crap”;

  2. In an recent presentation, I heard the presenter emphatically referring to someone else code as “crap

Skip to main content