To-Be vs. Should-Be

Analysts and architects often create as-is and to-be models of a business or system.  In to-be models, sometimes I am asked to include future enterprise-wide solutions, to make sure they will be integrated with whatever I am architecting.

This becomes a problem when my to-be model is for a project that has funding and a deadline, while the future enterprise solution is merely a good idea with no certainty of implementation.

This could be called should-be architecture.  It belongs on a different diagram than the to-be architecture that will realistically be implemented within a planned project.