Introduction to Phase A
Architecture Vision: Set and confirm the expectations for an enterprise architecture project Preliminary
Goals:
• Develop Architecture Vision
The main goal of phase A is to set and confirm the expectations for an enterprise architecture project. You need to build consensus with the sponsoring organization and gain their approvals before you can continue to subsequent phases.
• Define Stakeholders
You need to identify the key stakeholders and their concerns, and define the key requirements to be addressed.
A
H
B
• Create Communications Plan Effective communication to the stakeholders at the right time is a critical success factor for enterprise architecture. Development of a Communications Plan for architecture allows for this communication to be carried out within a planned and managed process.
Requirements Management
G
C
• Perform Capability Assessment It’s valuable to understand the capabilities of a business, their level of maturity and the gap between the current and the desired level of maturity.
• Create the Statement of Architecture defines the scope and approach that will be used to complete an architecture development cycle. In the preliminary phase the Request for Architecture Work was issued from the Sponsoring Organization. In phase A, you have to submit a statement of architecture work and secure the approval.
D
F E
© Copyright 2017 Visual Paradigm | All Rights Reserved 1
Develop Architecture Vision
2
Phase A - Architecture Vision Vision
Mission
Strategy
Objectives
Capabilities
Principles & Policies
Functions
Processes
Technology
Information
Enterprise Architecture
Goals
• Architecture strategies deliver business-driven priorities which impact business processes, people and technology. • Architecture principles and practices guide enterprise through the business, information, process, and technology changes necessary to execute their strategies.
• Provides a fast-track process for planning, analysing, and executing the entire EA process to meet desired organizational objectives.
3
Identify Stakeholders in Architecture Development Find out the key stakeholders of the architecture activities as well as their key concerns:
• Typically, stakeholder are people who are affected by the architecture, who have influence or power over it, or have an interest in its successful or unsuccessful conclusion. • It might include senior executives, project organization roles, client organization roles, system developers, alliance partners, suppliers, IT operations, customers, etc.
CIO
Enterprise Architects
Business Architects
System Architects
Technology Architects
Domain Representatives
4
State their Concerns Stakeholder
Key Concerns
Class
Deliverables
• High-level business drivers, goals, and objectives. CIO
Enterprise Architects
5
Describe the Kind and Level of Involvement Stakeholder
Key Concerns
Class
• High-level business drivers, goals, and objectives.
Keep Informed
Keep Satisfied
Key Players
Minimal Effort
Keep Informed
Deliverables
CIO
Power
Enterprise Architects
Level of Interest Describe the kind and level of involvement for each stakeholder by specifying their classes: • Some of the stakeholders may have the power either to block or advance. Some may be interested in knowing what’s going on; others may not be so interested. • By stating the class, the team can easily see which stakeholders have the power and the authority to request changes or to stop any initiatives, and which stakeholders are likely to support the initiative. 6
State Stakeholders Interests Stakeholder
Key Concerns
Class
Deliverables
• High-level business drivers, goals, and objectives.
Keep Informed
Architecture Principles
CIO
Enterprise Architects
Select views for stakeholders: • Throughout the development cycle, different deliverables will be produced. You need to state the deliverables that the stakeholders are interested in.
7
List and Describe the Issues / Scenarios Once you’ve identified the stakeholders, let’s move on to ... Project Background
Issues to be addressed
Describe the project background
Describe the issues and scenarios to be addressed by the architecture activities
8
Project Background – An Example
ArchiSurance was formed to take advantage of numerous synergies between the three organizations. While the three pre-merger companies sold different types of insurance, they had similar business models. All three sold direct to consumers and businesses through the web, email, telephone, and postal mail channels. Although based in different cities, each was completely housed in a modern office complex in a major metropolitan area. Each had loyal customer bases and strong reputations for integrity, value, service, and financial stability. All three companies were privately held by interlocking groups of institutional and individual investors.
9
List of Issues – An Example
The lead investors of the three companies began merger talks after they noticed that lower-cost competitors were entering their markets, that there were new opportunities in high-growth regions, and that each company required significant new IT investments to remain competitive. They realized that only a larger, combined company could simultaneously control its costs, maintain its customer satisfaction, invest in new technology, and take advantage of emerging markets with high growth potential. The merger negotiations and regulatory approvals took 18 months, but two years ago the papers were signed and the merger was complete. The new company offers all the insurance products of the three pre-merger companies, and intends to frequently adjust its offerings in response to changing market conditions. Like its three predecessors, ArchiSurance sells directly to customers via web, email, telephone, and postal mail channels, and indirectly via intermediaries.
An important technique that may be used at various stages of the enterprise architecture, principally the Architecture Vision and the Business Architecture phase.
They are used to help identify and to understand business needs, and thereby to derive the business requirements that the architecture development has to address. 10
Discover the Driver of Changes
Improve Competitiveness
by deriving them from stakeholders
Board
Sales Target
Customer
Stakeholder Satisfaction
Customer Satisfaction
Profitability
Revenue
Product Portfolio
Price
Stakeholders Represent (groups of) persons or organizations that influence, guide, or constrain the enterprise. Costs
Drivers Represent internal or external factors which influence the plans and aims of an enterprise.
An understanding of strengths, weaknesses, opportunities, and threats in relation to these drivers will help the formation of plans and aims to appropriately address these issues.
Stakeholder Driver 11
Assess the Drivers to Identify the Challenges Improve Competitiveness
by deriving them from stakeholders
Profitability
Revenue
Costs
Profitability
Customers Choose our Competitors that Provide Digital Customer Experiences
High Personnel Costs Revenue
Costs
Customers Choose our Competitors with Lower Premium Costs
High Application Maintenance Costs
E.g., using a SWOT analysis, in order to respond in the best way.
Drivers Can originate from either inside or outside the enterprise. Internal drivers, also called concerns, are associated with stakeholders.
Assessment
Examples of such internal drivers are customer satisfaction, compliance to legislation, or profitability. It is common for enterprises to undertake an assessment of these drivers
Driver 12
Identify Goals based on the Result of Assessments Profitability Customers Choose our Competitors that Provide Digital Customer Experiences
High Personnel Costs Revenue
Costs
Customers Choose our Competitors with Lower Premium Costs
Improve Customer Retention
High Application Maintenance Costs Increase Revenue
Reduce Costs
Increase Market Share
Reduce Maintenance Costs
Improve Customer Retention
Improve Customer Retention
Goals can also be decomposed e.g., “increase profit” can be decomposed into the goals “reduce cost” and “increase sales”.
Reduce Personnel Costs
Introduce the Common Use of Applications Goals represent some desired result that a stakeholder wants to achieve e.g., increasing customer satisfaction by 10%. Goals are generally expressed using qualitative words e.g., “increase”, “improve”, or “easier”.
Driver Assessment
Improve Customer Interaction with Collected Data Goal 13
Identify High Level Requirements Profitability Customers Choose our Competitors that Provide Digital Customer Experiences
High Personnel Costs Revenue
Costs
Customers Choose our Competitors with Lower Premium Costs
Improve Customer Retention
High Application Maintenance Costs Increase Revenue
Reduce Costs
Increase Market Share
Reduce Maintenance Costs
Provide Competitive Premium Services
Reduce Personnel Costs
Introduce the Common Use of Applications
Requirement is defined as a statement of need that must be realized by capability, a system or application components.
Integrate with Smart Device
Improve Customer Interaction with Collected Data
Goal Support for Smart Device Integration
Utilize the Insights of Customer Behaviors
Digital Customer Management
Data Driven Insurance
Maintain CRM Data Centrally
Establish a Shared Back Office for All Products
Support for Policy Administration
Support for Financial Transactions
Requirement
Capability
Application Service
Business goal must be realized by a plan or concrete change goal, which may or may not require a new system or changes to an existing system.
CRC Data Access
General CRM System
Policy Administration Services
Financial Services
ArchiSurance Back Office Suite
Application Component
14
Examine the Goals
Ensure that they do align with the principles. (Update of principles is allowed)
Reduce Maintenance Costs
Reduce Personnel Costs
Introduce the Common Use of Applications
!
Single System of Record for Each Data Element
!
Common Use of Applications
• Principles are general rules and guidelines, intended to be enduring. Principles are strongly related to goals and requirements. • A principle is motivated by some goal. For example, the aforementioned principle may be motivated by the goal to maintain a good reputation and/or the goal to avoid penalties. • The principle provides a means to realize its motivating goal, which is generally formulated as a guideline. Goal Principles
!
15
Develop Communications Plan
16
Developing Communication Plan
Enterprise architectures contain large volumes of complex and inter-dependent information. Effective communication of targeted information to the right stakeholders at the right time is a critical success factor for enterprise architecture. Development of a Communications Plan for architecture allows for this communication to be carried out within a planned and managed process.
17
Identify Stakeholders grouped by communication requirements
Project Manager
Development of a Communications Plan is to ensure communication will be carried out within a planned and managed process.
Project Lead
Stakeholders
Enterprise architectures contain large volumes of complex and inter-dependent information.
Project Team
Project Sponsors
In order to develop an enterprise architecture with success, effective communication of targeted information, to the right stakeholders at the right time is very important.
First off, identify the stakeholders who will take part in information sharing. They are typically people or groups of people who initiates communications, be accountable, be informed or be consulted.
18
Describe each type of the Communication Type Type of Comm.
Purpose
Presenter
Audience
Time/Freqency
Documentation
Kickoff Meeting
Introduction of project team and project. Review the goal of iteration.
• Project Manager • Team Lead
Project Team
Start of iteration
Meeting minutes
1 2 3 4 5 6
List out and describe each of the communication type.
State the purpose of communication. In this case it’s to introduce
State the stakeholder who will present the information.
Communication need not to be a face to face conversation, or meeting. It can be a report of
And state who will receive the information.
status or progress. So in such case, documents like progress report, project log will be created.
Time and frequency. When will the communication take place?
Documentation, which is the deliverables of communication.
19
Identify the Responsibilities of Stakeholders
Once the types of communication are listed, state the responsibilities of the stakeholders.
Kickoff Meeting
R
Meeting Minutes Internal Project Status Meeting Meeting Minutes Notes of Keywork items
C
RA
R
Issue Log Issue Log
R
A
Project Status Reporting Meeting Minutes Project Status Report
I
I
C
I
R
I
I
C
I
R
Monthly Newsletter Newsletter
R - Responsible
A - Accountable
C - Consulted
I - Informed 20
Confirm Business Principles, Goals, and Drivers
21
Confirm the Principles, Goals, and Drivers
Business Principles
Business Goals
Business Drivers
In the Preliminary Phase you have identified a set of business principles, goals and drivers.
Now in phase A, you have a deeper understanding about the architecture activities to be performed, you may now revise and confirm the business principles, goals and drivers before continue.
22
Develop Capability Assessment
23
What is a ‘Capability’? TOGAF defines a capability as “An ability that an Organization, Person, or System Possesses.” Here are some examples of business capabilities.
Customer Care
Financial Management
Strategic Management
24
Strategic Planning In strategic planning it is valuable to understand the capabilities within the enterprise, especially the business and IT capabilities, because you want to know if any capabilities needs to strengthen or add to implement the strategic and operational changes envisages. Here are some examples of business and IT capabilities. • For business you may have business management as a capability, which can be split further into capabilities like the management of strategic, fiscal and accounting, risk and compliance, and performance. • From this example you can also see the difference between business functions and capabilities, which are often confused because something an organization deliver, must be something it’s capable to do. But as you can see, when considering capabilities we focus on the expertise and capacity, instead of describing pieces of works done by an organization. Let’s also take a look at some of the IT capabilities. We have applications and management, which involves application design and architecture, development, testing and quality assurance and change management. Again, capabilities are not any services or functions or development unit but the expertise it has in achieving certain strategic needs.
25
Business and IT Capabilities - Examples Business Capabilities Business Management
IT Capabilities Applications & Management
Strategic Management
Application Design & Architecture
Fiscal & Accounting Management
Application Development
Risk & Compliance Management
Testing & QA
Performance Management
Change Management
Product Management Product Definition
Data Management Storage & Backup Services
Product Engineering IT Planning & Service Delivery Marketing
Security & Risk Management
Market Development
Innovation Management
Campaign Management
Program & Project Management Training
26
Model Capabilities with ArchiMate Diagram Business Management
Strategic Management
Fiscal & Accounting Management
Risk & Compliance Management
Performance Management
Project Management
Martketing
Sales & Distrubtion
Customer Care
Product Definition
Market Development
Distribution Channel Management
Customer Service
Customer Relation Management
Product Engineering
Campaign Management
Sales Execution
Service Channel Management
Customer Data Management
Assest Management
Money Management
Customer Care
Investment Strategy Management
Investment Performance Management
Banking Management
Accounts Management
Contract Lifecycle Management
Claim Settlement
Investment Portfolio Management
Assest Inventory Maintenance
Cash Flow Management
Money Market Management
Contract Administration
Claim Administration
Business Support Organizational Development
HR Management
Process Management
Office Management
Facility Management
IT Management
This is the capability map viewpoint of ArchiMate. It allows business architect to create a structured overview of the capabilities of the enterprise. 27
Specify the Risks for Business Transformation For each capability, evaluate the following: • Business risk. Will there be any business issues arised causing by a target capability after the transformation? • IT and infrastructure risk. If it’s an IT capability, will there be any outstanding system or infrastructure issues caused by this capability after the transformation?
• Maturity. Is the capability mature enough to satisfy the proposed target? • Mitigation activities. What measures will be taken to mitigate the risks?
• Migration risk. Is there any risk during the transformation process?
Strategic Management
Business Risk:
High / Medium / Low
IT & Infrastructure Risk
High / Medium / Low
Migration Risk:
High / Medium / Low
Maturity:
High / Medium / Low
Migration Activities
28
Develop Statement of Architecture Work
29
Request for Architecture Work The Request for Architecture Work was issued from the Sponsoring Organization in the Preliminary Phase.
Request for Architecture Work
Sponsoring Organization
Architecture Organization
By the end of the preliminary phase, which is the previous phase, the sponsoring organization has issued the Request for Architecture Work that states the needs of architecture development. 30
Statement of Architecture Work In this phase, you need to submit a Statement of Architecture Work based on the Principles set by the Project Sponsors and the findings in this phase
Sponsoring Organization
Architecture Organization
Statement of Architecture Work
31
Approval of This Document
• As a response, you now need to submit a statement of architecture work based on the principles set by the project sponsors and the findings in this phase. • Review and agree the plans with the sponsors, and secure formal approval of the Statement of Architecture Work under the appropriate governance procedures • Gain sponsor's sign-off to proceed.
32
Statement of Architecture Work - Content
• Architecture project request and background • Architecture project description and scope • Stakeholders and their concerns • Communications plan
• Acceptance criteria and procedures
• Project plan and schedule • Approvals 33
A e s a h P f o t l Resu
34
Results Production of Deliverables: Print Architecture Vision
Business Principles Goal Drivers Confirmation
• Formal approval of the Statement of Architecture Work • Gained sponsor’s sign-off to proceed
Communication Plans
Capability Assessment
Statement for Architecture Work
35