Architecture as a Crosscutting Concern

Architecture as a service

I have been practicing software architecture for a while, and I have tried many approaches to effectively work with development teams. At times, I attempted to micro-manage engineers by giving constant guidance and feedback for every little detail that they implemented. This approach proved to be too cumbersome, time-consuming, and discouraging creative thinking in developers. On the other extreme, I have tried to completely disconnect from engineering teams by only drawing high-level system diagrams and presenting them to the technical audience without any guidance on how to implement proposed solutions. This tactic resulted in systems that did not conform to architectural or enterprise vision and solved problems in a less than optimal fashion. An ideal level of engagement with development teams varies from one group to another, and it is somewhere in between the two models that I described.

I currently believe that software architecture is a service to other functions of IT organizations, such as development, testing, product and project management, and application support teams. This service is available for consumption, and it delivers the best value when the consumer is interested in leveraging offered service. To effectively practice this approach, several key initiatives must take place:

• The role of software architecture must be clearly understood by organizations and functional areas that might need input from architects.
• A partnership must be established

...