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

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

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

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

Help with misconceptions about eXtreme Programming

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

Does SOA imply that OO is dead?

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

It is the people, as always has been

https://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?