When business architecture is described as the blueprint of the enterprise, it needs to be followed by a clarification of what kinds of a blueprints we are talking about. The simplistic answer to this would be “business blueprints”, but what really are business blueprints? Wouldn’t everything in an enterprise be part of some business blueprint? Technically, that interpretation could be correct, but down that path you boil the oceans. A cleaner interpretation is that business blueprints should only show those components directly relating to the core business of an enterprise. This excludes a lot of blueprints which may be very important to an enterprise. For example, for most enterprises, the networking blueprint would not be part of the business architecture even though it would be very important to the daily functioning of any enterprise.
Drawing an analogy to the physical world of buildings, business blueprints would be those which help the buyer and ultimate occupants of the building, to understand what will be built, to help them provide feedback ahead of time, and approve what is to be built. For an enterprise, business blueprints would be those blueprints which help the owner (leadership/management) and ultimate occupants (management/employees) to understand what is being built. Those blueprints that only help the professionals to build the building are not business blueprints. Analogous to the network blueprint example above, the electrical blueprint of a building would not be very relevant to its owners and occupants even though functioning electricity likely would be a necessity.
The building analogy does bring up a difference which is worth pondering. For buildings, the owner and occupants are apart from the building. For enterprises, the leadership, management, and employees are part of the business which is being captured in a business blueprint. So when an enterprise embarks on creating a business architecture using business blueprints, the enterprise already exists. This is one difference between business architecture and building architecture.
We can use blueprints to describe some future state of the enterprise. This could be valuable, but it is currently somewhat challenging to accurately describe a future state of an enterprise. I am not saying that it is challenging to create a future state blueprint. It is however challenging to create a future state blueprint which accurately describes what the enterprise really will end up looking like in the future. Building architecture has the benefit of dealing with real physical structures. Even if most buildings by the time they have been built, have deviated from the original blueprints, it is only by a small degree. The end result and the original blueprints are recognizably the same. The same does not hold true in today’s field of business architecture.
You can use business blueprints to describe the current state of the enterprise. Understanding the current state of the business has its own benefits. It will bring light to any problem areas within the enterprise. It will also provide great value when adding to or changing the enterprise. To me, one of the greatest values of creating current state business blueprints is that you have a real enterprise to compare and validate your business blueprints against. If you can’t create a business blueprint when you have the real thing to compare it to, the what chance do you think you will have in creating an accurate future state one?
To sum it up, business blueprints are for the leadership, management, and employees to understand the business of the enterprise. For this purpose business blueprints capture those components which directly relate to the business of the enterprise.