TOGAF® is a registered trademark of The Open Group in the United States and other countries. All other trademarks are the property of their respective owners. “Enterprise architecture deals with the design and implementation of the high-level structure of the enterprise. It is the result of assembling a certain number of architectural elements in some well-chosen forms to satisfy the major functionality and performance requirements of the system, as well as some other, nonfunctional requirements such as reliability, scalability, portability, and availability.
Enterprise Architecture, from a business perspective, is not about designing systems, processes, information flows or new technology, but it is about communication, risk and managing change in the organization. This perception of EA is normally found in businesses (or enterprises) where the EA team is treating the architecture effort the same as if they are designing a software system and where the team members have not made the transition from IT Architecture to Enterprise Architecture.
Before you share information with someone in the organization, the following questions must be answered; you need to communicate with, to organize a communication session, needs to be shared, to represent the content you want to share, you are sharing the specific content and lastly you will store the content for future reference. The first question we want to answer is why do we want to involve other people (stakeholders) in the architecture activity? The answer can be found in the architecture concepts defined in ISO 42010, which are now widely used in the architecture community, including TOGAF® 9. . • The Architecture concept represent the key elements in the organization and their relationship with other elements and their environment, • while the Architecture Description is the collection of models and views that represent the architecture in documented form. • We now have people inside and outside of the Enterprise that have key roles in the Enterprise or who have concerns about the Enterprise, these people are called Stakeholders, and can be users, developers, managers, government regulators or key partners.
Stakeholders can be individuals, teams, or organizations and all have different concerns about changes to or risk exposure of the Enterprise. • The key interests of the Stakeholders that are crucially important to them are called Concerns and addressing these concerns is crucially important in determining the acceptability of the risk or change within the Enterprise. • It is the function of the EA team to ensure that Stakeholders’ concerns are being addressed by the architecture description, and the only way that it can be done is by creating Views.
From the previous section we concluded that a stakeholder’s concerns must be addressed by a view. The ArchiMate 2. 0 standard define a View as being part of the architecture description of the enterprise that addresses a set of related concerns of a set of stakeholders. The viewpoints defined in ArchiMate are used to specify which the concepts, models, analysis techniques, and visualisations are provided to its corresponding view. . To be able to identify a final stakeholder viewpoint, the right content abstraction level must be selected. Business Process Viewpoint Meta-model Example Business Process View (Model)
As part of the ArchiMate 2. 0 Architecture Viewpoint Library, the meta-model plus an implementation example are included for all the pre-defined viewpoints. The ADM provide guidance on How views are created and the ADM lifecycle selected by the Enterprise will determine When the views will be created. The core architecture design views are created during Phase B- D and there is a strong link between these phases and the ArchiMate 1. 0 standard architecture viewpoints within their three Layers; of Business, Application and Technology. How do I present information to stakeholders?
In the TOGAF® 9 ADM Phase B: Steps below I highlighted the activities in red that involve the definition of How the views will be created or used for a specific project during the Business Architecture definition phase. TOGAF® 9 ADM Phase B: Steps Select Reference Models, Viewpoints, and Tools Develop Baseline Business Architecture Description Develop Target Business Architecture Description Perform Gap Analysis Define Roadmap Components Resolve Impacts Across the Architecture Landscape Conduct Formal Stakeholder Review Finalize the Business Architecture Create Architecture Definition Document
Now that you have created this magnitude of viewpoints for different stakeholders Where do you save the content for future re-use. How do you classify your information after the project is completed? The Zachman framework is a 6 x 6 matrix that define the total set of primitive models that you need in an organization and any view that you built before or are thinking about building in the future can be defined in the framework. Building Enterprise Architectures in an organization should not be internally focused, but should support key stakeholders in the enterprise (and outside of the enterprise).
I briefly introduced a few frameworks and standards that can be used when working with stakeholders and I tried to make the elements involved in defining views easy to remember by asking 6 questions: • Why: Understanding stakeholders and their concerns and why we use views [ISO 42010] • Who: Identify stakeholders and classify type of stakeholders [ArchiMate Viewpoints] • What: Select the right viewpoints for the identified stakeholders [ArchiMate Viewpoints] • When: Identify the phase in the Architecture development cycle when the viewpoint will be used o build the view [TOGAF® 9 ADM] • How: Understand how views fit into the activities performed during the Architecture development cycle [TOGAF® 9 ADM] • Where: Select the right place to store the views and understand the value of a good repository that is flexible enough to store any view [Zachman Framework] http://www. orbussoftware. com/downloads/white-papers/