One of the most important words in enterprise architecture is View. A normal architect who designs a new office building has lots of drawings. There are drawings for the customer to see so that they understand what the new office will look like. There are drawings for the builders so that they understand how to construct it. There are drawings for the plumbers so that they understand how to get water in and waste out. There are other drawings for electricians, glaziers, heating engineers, and so on. Lots and lots of drawings. There isn’t one drawing that shows everything because it would be impossible to read. But the architect produces all of the drawings and has a good understanding of what is on them.

In enterprise architecture, those drawings are all Views and those people (the customer, builders, plumbers, electricians, etc.) are the stakeholders. It is important to understand that something like the data architecture is just one View/Viewpoint of the enterprise artefacts.

To my mind, it is the responsibility of an EA (and team) to provide all of the Views (drawings/documents/information) that the stakeholders need to make the project/programme a success. It is all very well to be a brilliant designer but you have to be able to communicate that design to the people who will build it. To do that successfully, you have to understand a good part of the job of those people.

A normal architect needs to understand that concrete can be poured but does not teach the builders how to pour it. The architect tells the customer he needs a builder who knows how to pour concrete, i.e. that the builder is skilled in a particular area. The same is true in enterprise architecture. An EA provides enough information so that a skilled stakeholder can construct the relevant artefacts.

“Architecture View” is like saying “Database Report”. The stakeholders only want to see the bits they need, not all of the data architecture or all of the business architecture, etc. Different views should be produced to show different subsets of the business, data, application and technology architectures. For instance, some views might include the Risk architecture or KPIs. Each view addresses the concerns of different stakeholder.

As an enterprise architect, do you understand the artefacts that need to be built? Do you understand the requirements of any existing artefacts? But, most importantly, do you have enough grounding in the skills involved that you can communicate your architecture to the stakeholders? After all, they’re they ones who are going to build it and their success depends on your ability to give them Views that take advantage of their skills.