Bonus Section A: Architecture Vision
A.1 Stakeholder Interviews to Capture Concerns
Minutes: Architecture Team Meeting
Date: July 1
Present: Kathleen Stone (KS), Tony Gonzales (TG), Nick Ross (NR), Terri Nichols (TN), Rakesh Gupta (RG), Greg Morrison (GM), Philip Potter (PP)
KS outlines the plan to identify stakeholders in order to start conducting interviews.
NR facilitates the meeting to compose draft lists:
-
To identify the stakeholders.
-
To gather any concerns the team is already aware of for each of the stakeholders.
-
To identify the level of interest and artifacts that may need to be created for each stakeholder.
TN asks where all of the information to be collected and the artifacts built will be stored to enable stakeholder access from across all of the functional groups.
TN points out it might make sense to have a common repository for documents with multiple functional groups being involved to avoid fragmentation of the documentation in each functional group’s own document collaboration site.
TN suggests that maybe it could even be organized by the product lifecycle?
ACTION: KS will come back with an answer on this very soon.
KS presents the next steps and logistics – to get the interviews scheduled and start gathering pain points and concerns from our stakeholders.
ACTION: TG to develop the schedule and book conference rooms.
KS outlines the plan:
-
A kickoff meeting with representation from our 30 stakeholder groups to show what we have put together so far – for three hours, with lunch provided
-
The provision of additional information about the dependencies between the functional groups for each value stream
-
The use of design thinking to help formulate the direction of addressing the pain points identified
-
The conference rooms will handle four to six stakeholders for two-hour blocks for the interviews and other sessions
KS points out that a rough draft of the groupings will be drawn up but not finalized until a better understanding of the dependencies is available.
KS adds that the Stakeholder Map is very important to get right because it is what will be used to begin shaping the Architecture Vision and the Business Architecture.
ACTION: NR to take the leadership of completing the Architecture Vision to include the Stakeholder Map, Motivation diagrams, and the value stream capability assessments.
Deadline: KS sets a target of two weeks to complete this effort.
A.2 Results of the Stakeholder Interviews
Meeting: Architecture Team
Date: August 13, 8.00am
Present: Kathleen Stone (KS), Tony Gonzales (TG), Nick Ross (NR), Terri Nichols (TN), Rakesh Gupta (RG), Greg Morrison (GM), Philip Potter (PP)
KS welcomes and thanks everyone in recognition of the early scheduling of this meeting.
KS thanks NR for his efforts along with the other Business Architects (TN, RG, GM, and PP) in conducting the stakeholder meetings and completing the Stakeholder Map, with their concerns and the planned artifacts for each stakeholder, as well as creating the Motivation diagrams and solution concepts based on the feedback from the stakeholder meetings.
KS points out that while NR had initially requested to meet with her and the Business Architects to review progress and look at next steps, she has extended this important meeting to show the whole team the product/service lifecycle integrations she has been developing and testing out on a small scale. KS is now ready for more people to use the automated flow of work that her small DevOps team has created using the IT4IT Reference Architecture and existing tools in the application landscape.
NR also thanks the team for gathering the stakeholder information and translating it into the Architecture Vision, which will help the initiative stay on track and will be great input for the Business Architecture. He also mentions they have some good ideas for getting the Business Architecture done quickly, especially now that they have buy-in from the stakeholders and leadership.
NR presents the Stakeholder Map (Stakeholder Map) and explains the process the team used to gather the information.
A.3 Stakeholder Motivation – Drivers and Assessments
Presentation: NR and TG
NR displays a portion of a Motivation diagram identifying two of our stakeholder groups (the ArchiSurance Board of Directors and its current and potential customers) and their concerns, modeled as drivers. He points out that customer satisfaction is a shared concern of both groups; see Stakeholders and their Concerns.
Stakeholder satisfaction can be refined into more detailed concerns, like profitability. The drivers motivate the development of specific business goals for profitability, as shown in Drivers and Business Goals.
The two assessments show that the profitability of ArchiSurance is suffering from customers defecting to competitors with superior digital experiences or lower premium costs. ArchiSurance has a goal to raise its profit margin by 5% in the next fiscal year. Actions such as reduction of costs have a positive influence on this outcome. Cost reduction can be achieved by reducing both maintenance costs and personnel costs.
A.4 Goal-Based Principles that will Guide the Architecture
NR continues: Based on these business goals, a set of principles was defined to guide our architecture development. The ArchiMate modeling tool we are using [18] defines a principle as a realized, qualitative “statement of intent that should be met by the architecture”. Note that the systems here include, for example, organizations and organization units, not only IT systems. Principles, therefore, help realize business goals. The TOGAF Standard [19] also defines a principle as “a qualitative statement of intent that should be met by an architecture”, which should also have at least “a supporting rationale and a measure of importance”.
NR shows this modeled with the ArchiMate principles viewpoint (Business Goals and Principles), depicting principles, their dependencies, and the goals they realize.
From these principles, we have identified which requirements realize and/or influence them, which will be input for all development teams, helping us to understand the relationship between the work our stream-aligned teams are doing, and finally, the value it creates. The next slide shows the goal refinement for the Application Rationalization Strategy; see Goal Refinement View for Rationalization Strategy.
With this information, we can prevent requirements being implemented without a clear link to value – or worse, deliver a requirement and only then realize it is not what we needed.
In addition to the short-term need for rationalization, we have started defining the longer-term Digital Customer Intimacy strategy that combines Big Data and IoT. Our stakeholders want to be able to use more detailed customer data to improve customer interaction and satisfaction, and to customize insurance premiums based on insights into the customer’s behavior. We intend to capture this data with smart, connected devices such as personal fitness trackers, black boxes in vehicles, home automation gateways, fleet management systems, in-store RFID devices, or smart sensors in buildings.
The next slide shows a strategy viewpoint; Business Strategy.
TN takes over and presents her work on this viewpoint and the solution concept.
A.5 Courses of Action Chosen or Considered
TN explains how she modeled an overview of the courses of action chosen or considered by the enterprise, the capabilities, and resources supporting them, the envisaged outcomes, and how these contribute to the organization’s goals and drivers. Ultimately, this new strategy should contribute to the main drivers of the organization, as outlined in part in Stakeholder Map.
This strategy view (Business Strategy) was developed to show the relationships between strategy, capabilities, envisaged outcome, and stakeholder drivers. The Digital Customer Intimacy strategy requires ArchiSurance to develop a number of new capabilities and resources (shown here in yellow), including digital customer management, data acquisition, and data analysis.
A.6 High-Level Target Architecture
TN continues: An important element of the Architecture Vision is a high-level representation of the Target Architecture and how this provides a solution for the needs of the enterprise. It can really help explain the added value of the architecture effort to stakeholders. The TOGAF Solution Concept diagram can be created with the ArchiMate language for this purpose. Solution Concept Diagram highlights the most important aspects of the Target Architecture and how this will realize the expected outcomes, as shown in Business Strategy. Solution Concept Diagram also adds the requirements for both the Rationalization and the Digital Customer Intimacy strategies; as you can see in the new solution:
-
Enterprise-wide Customer Relationship Management (CRM) automation in the front office will replace individual CRM systems
-
Integrated back office automation will replace separate back office applications for the different lines of business
-
The outcome “Detailed Insights in Customer Behavior” will be supported by acquiring customer behavior data from external data sources, which will be fed into a solution for automated data analysis, which in turn will deliver customer profiles to the new back office solution
-
The business intelligence gained will be used in setting insurance premiums for individual customers as part of the claim management capability, and the development of new insurance products
-
This will also require the development of organizational competencies in data analysis
-
-
Various social media apps in combination with the requisite social media competencies of the organization will realize the envisaged excellent online customer interaction
A.7 Next Steps for Defining Value Stream Stages
TN outlines the next steps and presents a plan and timeline for the Business Architecture. We have identified an operational value stream that is called “Acquire Insurance Product” that we plan to build out with baseline and target models for each stage of the value stream. This would include a gap analysis and capability assessment for each value stream stage. The result will be a list of opportunities for each value stream that can be prioritized and placed on the roadmap. We estimate two to three weeks per value stream stage and the stages would be worked on simultaneously by our team of Business Architects. Each architect will be responsible for one value stream stage and a set of stakeholders. We also think it would help to assign a couple of Solution Architects who are well-versed in IoT and Big Data to work with us so we can get a head start on identifying solution alternatives.
KS thanks the team and says she is proud of the team’s progress and quality deliverables. She compliments Nick for showing leadership and initiative by going to the Vice-Presidents of the functional organizations for their buy-in and help with freeing up key resources to participate.
KS asks NR to work with TG to show continuous progress now that we have the buy-in.
ACTION: NR to work with TG to set up regular status meetings with key stakeholders and their leadership.
KS concludes the meeting by thanking the team again for all of their hard work stating that Business Architecture is key to the success of a Digital Transformation. With the Architecture Vision fully defined, it is time to start the Business Architecture.
KS asks for enough detail within the next two weeks to use it in the all-hands call Brad has organized, where she has been asked to present the vision that we have been building.