In the Reference Model, only the types of components are shown, while in the actual Business Architecture, specific components would be identified. For example, the Business Process category might include processes for selling a product, while the Business Component category may contain an Address Component. The answer varies according the to category. For the Technical Infrastructure Category, we can look to industry and standards organizations for support. Therefore, key to the success of the Reference Model will be its ability to incorporate new standards as they emerge so as to identify a proper set of components.
Components are however only one aspect of an architecture.
To that end we incorporate patterns and frameworks, and like components, they exist in each of the categories of the reference model. Frequently there may be several alternatives, each offering a different trade-off on performance and cost. By cataloguing this information with the architecture developers have a mechanism to go back to their business partner and explain the issues they face, the trade-off available, thus including the partner in the decision making process. Frequently we face a problem with communications between people working in different categories. As our catalogue of components grow, they start to form a language, enabling better communications resolving the first source the of communications problem.