Bryan Rees on Cloud Architecture - Think Components

[fusion_builder_container hundred_percent="yes" overflow="visible"][fusion_builder_row][fusion_builder_column type="1_1" background_position="left top" background_color="" border_size="" border_color="" border_style="solid" spacing="yes" background_image="" background_repeat="no-repeat" padding="" margin_top="0px" margin_bottom="0px" class="" id="" animation_type="" animation_speed="0.3" animation_direction="left" hide_on_mobile="no" center_content="no" min_height="none"] Among the tips that Bryan Rees at InCadence posts in a blog about Architecting for the Cloud, he highlights the importance of solving for all requirements in a whole solution instead of thinking of requirements as a silo.  We do this by grouping requirements together and solving them in groups.  The way he puts it is:

Architect your solution in a componentized way: The key to being a cloud architect is to step away from the mindset of trying to crank through all the functional requirements by yourself. One has to step back and think about the business requirements and then architect a solution of loosely coupled components that address the overall requirements. This takes a bit more work upfront but pays huge dividends later, not only in terms of executing on the initial project but also for maintaining and evolving your solution.

A(n overly-)simple way to think of this is a scenario where a custom field will solve an immediate need.   The temptation is to just create the custom field and move on; however, if the field is representative of a list of items, then, in order to accomplish the list, a custom field must be created for each option on the list.  That line of development will leave an organization with 15 fields on a page instead of one picklist or custom object.  Since the fields can't really be combined well into a report to get onto a dashboard, the organization then exports to Excel in order to share it with the executive who needs to see it.

The article is worth the read his next point about API's over language and his later comments on crowdsourced solutions are also worth a read.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]