Does your company have architectural principles that are written and agreed upon? How did they come about? How do you manage ownership and acceptance of these principles? Are they helping you or hinder you?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
migrated from stackoverflow.com Feb 28 '11 at 4:43
This question came from our site for professional and enthusiast programmers.
We internally maintain a set of architectural guidelines for engineers in the organization. These are reviewed and vetted out by a developer advisory forum run across the organization. The developer organization forum is a small forum of developers having sufficient representation across all product streams. This developer forum internally debates different architectural practices and once consensus is reached for a guideline, it is incorporated in the document templates for different specifications to be used by developers.
So far we have found these practices helpful as they help maintain a set of guiding principles. However sometimes we internally debate process to see that we are not causing process bloat leading to decrease in productivity.
I am outlining the process here but for confidentiality reasons cannot shares the patterns themselves.
We have core principles (non-technical; company philosophy), which do not change. Architectural principles change as technology changes, and as required by the project.
It is common in larger companies to have architectural principles, often overseen by a committee. It is far too easy for these to become an excuse not to think, and often they become an institutionalized policy of stagnation.
Guidelines are great, they offer suggestions. Principles imply axiomatic acceptance and application, and can lead to progress-killing dogma.