Many discussions of how-to-do architecture talk about modeling the domain 'as-is' then defining the 'to-be' state.  In general I agree, clearly defining the problem before identifying the solution is a risk mitigation technique.  By focusing on the current state you avoid artificially injecting constraints or driving change for the automations sake into the business.


While valuable for application architecture this really doesn't hold true for enterprise architecture.  When establishing enterprise architecture it is your job to define the constraints.  At the enterprise level we define boundary conditions in multiple dimensions. Political boundaries, fiscal limitations, as well as the vision and strategy of the business are captured ‘As Is’ to guide the individual projects.


Enterprise guidance is implicit not explicit.  It creates an environment fostering growth over time. It's the applications that decide what the ‘To-Be’ implementation is for their portion of the enterprise.  Applications are free to do as they please as long as they are well behaved citizens of the enterprise.