Are Comprehensive Enterprise Level Blueprints a Waste of Time?

When done correctly, blueprints are great.
Not enforcing them, makes them a waste of time.

Yes, as long as:

1. The EA team does not get stuck in "analysis paralysis" in an attempt to overengineer the "comprehensiveness" of the Blueprints.

2. The Blueprints are so "comprehensive" that they constantly get outdated making maintaining them next to impossible. As a result the Blueprints are never current nor relevant.

Comprehensive Enterprise blueprints are most useful to the enterprise stakeholders that own that aspect of the Enterprise or for occasional inspection by other professionals.

Since the blueprints are designed and owned by the stakeholders in charge of the specific Enterprise views, they should have as much detail as necessary to execute the day to day work.

Nevertheless, most enterprise stakeholders would be satisfied with a high level EA blueprint.

The concern comes from fear that the EA architect is asked to deliver comprehensive blueprints that he/she is not suppose to or not able to, for lack of deep enough knowledge.

The EA architect does not provide detailed blueprints but establishes the framework, that links these blueprints back into the whole EA, and coordinates the blueprint work.

Enterprise Blueprints are a great way to align everything within a systems environment towards a common set of principles. In my experience they work when:

1. Obviously if they are "correct" - a highly subjective and debatable thing in architecture
2. The _principles_ are comprehensive and do not require large scale re-engineering to align systems to
3. You don't try getting common buy in (which will end in paralysis) but the leadership is empowered to enforce them

Enterprise blueprints, and practically any EA deliverable for that matter, are only useful if:

1) They have a purpose in someone's process
2) They are updated by appropriate processes

The problem is that they are all too frequently created in response to a fire drill- a one time process with focused on solving one specific thing. At the end of the fire drill, all material associated with it is forgotten. Even if not forgotten, it's usually out of date or inappropriate/incomplete for the next drill, resulting in a whole bunch of wasted effort.

Only by ensuring that the blueprints have a purpose in ongoing processes, educating the people who manage those process on when and where it should be used, and making sure that processes that cause the blueprints to be inaccurate actually change the blueprints so that they stay accurate will your blueprints/deliverables be effective.

They're only a waste of time if no one bothers to read them. Planning in the absence of buy in and participation from the rest of the organization is crucial. You need that organizational committment that the group will actually implement, maintain, and refine the plan. Otherwise it will become a colossal waste of time.

It was once written of old, "Without a vision the people perish".

A master, colorful blueprint is great for providing an organization a architectural vector to follow. However, the big pretty diagram needs to be followed up with 1) incremental views of the architecture over time and 2) a roadmap/plan that can be executed upon.

Future State Arch - Current State Arch = List of projects to execute.

I think the most effective EA practice is top down but also must have elements/values from the agile community (just enough, just in time) in order for the architecture to be realized.