Enterprise Architecture involves a lot of forecasting and planning, and there are benefits to making it explicit.
The “to-be” architecture is a plan for changes to business strategies and technology resources, based on guesses about the future external environment. Even the “as-is” architecture involves predicting which architectural elements are important enough to document.
This may be surprising because an EA doesn’t look like a project plan; it has little temporal information. An EA is expressed as a static description, either a snapshot as of a particular date, or of a state to be reached at some unspecified point in future. The architect tries to anticipate the likely changes to the enterprise, for example by generalizing the data model and choosing scalable technology infrastructure.
An EA should make its forecasting explicit:
- What assumptions were made about the future external environment?
- What changes in the environment would trigger a change in the architecture? (Example: company merger or buyout)
- What need to change in the architecture, if the assumptions are no longer true? (Example: if transaction volumes go beyond a scalability boundary, what infrastructure would need to be replaced?)
A to-be architecture should also be complemented by an implementation plan, as in TOGAF phase E:
- When will each architectural element be implemented?
- How will the enterprise operate until all the architecture is implemented?
- What is the cost per month or year of delaying something specified in the architecture?
With this changeable information documented, an out-of-date EA can easily be updated, rather than dismissed wholesale. Reviewers can easily check that the EA’s assumptions are realistic and flexible enough for an unpredictable future in an uncontrollable environment.