다음을 통해 공유

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?

Comments