What drives the architectural decisions at most organizations? Is it based on history - we always did it that way? Does data drive the decisions? Does popular press influence it? Does corporate culture come into play? Does the size/skill level of the development/operations/support group(s) make a difference? What about other non-functional requirements?
My take on things: The decision making process isn't easy if you truly wish to manage the trade offs. The architectural effects on the operations & support organization should be seriously considered since that is where most of the effort occurs long term. The technical/development group should take all the above items into account. Having previous experience means there is likely some comfort level with dev, support and operations issues of the architecture. If there is knowledge regarding data or performance characteristics which promote certain solutions then they should be considered. Basing decisions on popular press is a double edged sword - technology with true efficiencies can promote better solutions but a lack of real world case studies can result in buying into empty solutions/hype. Corporate culture plays a part in the organization of teams and the scope of responsibilities with effects rippling into development, operations and support. Size and skill level of a group matters for both development and operations/support. A development group could produce an architecture which can scale beyond any need an organization will reach but is it worth it if it is costly/difficult to support and the operations/support group is not adequate for the needs. As for other non-functional requirements, I think items such as useful logging, metrics, efficient/reliable deployment and similar things should get lots of attention at the architecture level but typically doesn't.
Other items affecting decisions; enhance vs rewrite, rate of changes, expected lifetime of application.
No comments:
Post a Comment