企业架构 - 涉众管理(Stakeholder Management)

简介:

  复杂系统的复杂不仅在与架构开发流程本身,还与是否获得大范围涉众的一致同意有关,涉众管理的好不能肯定企业架构一定做得好,但是涉众管理做得不好,企业架构肯定做不好。对于管理类型项目来说,客户的满意度有时就能体现出我们和客户一开始交流得够不够。在A阶段(架构愿景)中我们需要进行涉众管理,交付类似下图的Stakeholder Map Matrix。本篇介绍一下涉众管理。

好处

  1. 标识重要的涉众,能在早期更好的框定架构需求和范围
  2. 通过重要涉众的支持,可以获取更多的资源
  3. 早期频繁的和涉众沟通,可以确保更完整的理解架构流程

管理流程

  1. 获取涉众列表
    • 谁从项目中收益或遭受损失?
    • 谁控制项目?
    • 谁来设计系统?
    • 谁作出决策?
    • 谁获得IT系统并决定是否购买?
    • 谁控制资源?
    • 谁有项目要求的专业技能?
    • 谁对项目有影响力?
    • 问发起人或客户
    • 检查组织机构
    • 比较类似项目组
  2. 认识涉众的态度
    • 这个人是否准备好了从当前现状改变到目标架构上?如故事,准备怎么改变?
    • 这个人是否有能力作为一个企业架构发动人和推动者?如果是,他有什么能力?
    • 如何参与到企业架构活动中?只是感兴趣了解而已,还是需要详细了解?
    • 对企业架构的开发是否有合约性的承诺?

    涉众分组

    涉众

    推动力

    当前清楚改变

    需要清楚改变

    当前责任义务

    需要责任义务

    需要支持

    CIO

    张三

    CFO

    李四

  3. 知道关键涉众: Power/Interest
    • A 不关注他
    • B 让他知道
    • C 使他满意
    • D 与他协作
  4. 裁剪涉众相关交付视图(ViewPoint)

  不同项目中自行进行裁剪,在TOGAF文档中举了一个裁剪示例

涉众

参与

分类

相关视图

CxO
(Corporate Functions);
e.g., CEO, CFO, CIO, COO

This stakeholder group is interested in the high-level drivers, goals, and objectives of the organization, and howthese are translated into an effective process and IT architecture to advance the business.

KEEP SATISFIED

Business Footprint

Goal/Objective/ Service Model

Organization Chart

Program Management Office
(Corporate Functions);
e.g., Project Portfolio Managers

This stakeholder group is interested in prioritizing, funding, and aligning change activity. An understanding ofproject content and technical dependencies between projects adds a further dimension of richness to portfolio managementdecision-making.

KEEP SATISFIED

Roadmaps

Business Footprint

Application Communication

Functional Decomposition

Procurement
(Corporate Functions);
e.g., Acquirers

Major concerns for these stakeholders are understandingwhat building blocks of the architecture can be bought, andwhat constraints (or rules) exist that are relevant to the purchase.The acquirer will shop with multiple vendors looking for thebest cost solution while adhering to the constraints (or rules) appliedby the architecture, such as standards. The key concern isto make purchasing decisions that fit the architecture, and thereby toreduce the risk of added costs arising from non-compliantcomponents.

KEY PLAYERS

Cost View

Standards View

Human Resources (HR)
(Corporate Functions);
e.g., HR Managers, Training & Development Managers

Key features of the enterprise architecture are the roles and Actors that support the functions, applications, andtechnology of the organization. HR are important stakeholders in ensuring that the correct roles and actors are represented.

KEEP INFORMED

Organization Chart

Organization/Actor/ Location

Enterprise Security
(Corporate Functions);
e.g., Corporate Risk Management, Security Officers, IT Security Managers

Major concerns for this group are understanding how to ensure that the information, data, and systems of theorganization are available to only those that have permission, and how to protect the information, data, and systems fromunauthorized tampering.

KEY PLAYERS

Data Security View

Networked Computing Hardware View

Communications View

QA/Standards Group
(Corporate Functions);
e.g., Data Owners, Process Owners, Technical Standards Bodies

Major concerns for this group are ensuring the consistent governance of the organization's business, data,application, and technology assets.

KEY PLAYERS

Standards

Guidelines

Specifications

Standards View

Application Portfolio

Technology Portfolio

Technology Standards

Executive
(End User Organization);
e.g., Business Unit Directors, Business Unit CxOs, Business Unit Head of IT/Architecture

This stakeholder group is interested in the high-level drivers, goals, and objectives of the organization, and howthese are translated into an effective process and IT architecture to advance the business.

KEEP SATISFIED

Business Footprint

Goal/Objective/ Service Model

Organization Chart

Line Management
(End User Organization);
e.g., Senior Business Managers, Operations Regional Managers, IT Managers

This stakeholder is interested in the top-level functions and processes of the organization, and how the keyapplications of the IT estate support these processes.

KEY PLAYERS

Organization/Actor/ Location

Goal/Objective/ Service Model

Cost View

Application & User Location View

Business Domain Experts
(End User Organization);
e.g., Business Process Experts, Business/Process Analyst, Process Architect, Process Designer, Functional Managers, BusinessAnalyst

This stakeholder is interested in the functional aspects of processes and systems. This can cover the human actorsinvolved in the system, the user processes involved in the system, the functions required to support the processes, and theinformation required to flow in support of the processes.

KEY PLAYERS

Process Flow

Use-case

Service/Information Events

Functional Decomposition

Application - Application Communication View

Data Entity/Business Function Matrix

IT Service Management
(Systems Operations);
e.g., Service Delivery Manager

Major concerns for this group are ensuring that IT services provided to the organization meet the service levelsrequired by that organization to succeed in business.

KEEP INFORMED

Standards View

Enterprise Manageability View

IT Operations - Applications
(System Operations);
e.g., Application Architecture, System & Software Engineers

Major concerns for these stakeholders are: Development Approach, Software Modularity and Re-use, PortabilityMigration, and Interoperability.

KEY PLAYERS

Process - System Realization View

Application - Data View

Application Migration Cost View

Software Engineering View

Platform Decomposition View

Networked Computing - Hardware View

Software Distribution View

Data Entities to Application Systems View

IT Operations - Infrastructure
(System Operations);
e.g., Infrastructure Architect, Wintel support, Mid-range support, Operational DBA, Service Desk

Infrastructure stakeholders are typically concerned with location, modifiability, re-usability, and availability ofall components of the system. In general these stakeholders are concerned with ensuring that the appropriate components aredeveloped and deployed within the system in an optimal manner.

KEY PLAYERS

Platform Decomposition View

Standards View

Enterprise Manageability View

Networked Computing - Hardware View

Processing View

Environments & Locations View

IT Operations - Data/Voice Communications
(System Operations);
e.g., Network Management

Communications engineers are typically concerned with location, modifiability, re-usability, and availability ofcommunications and networking services. In general these stakeholders are concerned with ensuring that the appropriatecommunications and networking services are developed and deployed within the system in an optimal manner.

KEY PLAYERS

Communications View

Executive
(Project Organization);
e.g., Sponsor, Program Manager

This stakeholder group is interested in on-time, on-budget delivery of a change initiative that will realizeexpected benefits for the organization.

KEEP INFORMED

Architecture Requirements

Architecture Principles

Architecture Vision

Functional Decomposition

Application & User Location View

Line Management
(Project Organization);
e.g., Project Manager

This stakeholder group is responsible for operationally achieving on-time, on-budget delivery of a changeinitiative with an agreed scope.

KEEP INFORMED

Application - Application Communication View

Functional Decomposition

Environments & Locations View

Business Process/Functional Expert
(Project Organization);
e.g., Financials FICO Functional Consultant, HR Functional Consultant

This stakeholder group will elaborate the functional requirements of a change initiative based on experience andinteraction with business domain experts in the end-user organization.

KEY PLAYERS

Process Flow

Use-case

Service/Information Events

Functional Decomposition

Application - Application Communication View

Product Specialist
(Project Organization);
e.g., Portal Product Specialist

This stakeholder group is responsible for specifying technology product designs in order to meet projectrequirements and comply with the Architecture Vision of the solution.

In a packages and packaged services environment, product expertise can be used to identify product capabilities that can bereadily leveraged and can provide guidance on strategies for product customization.

KEY PLAYERS

Software Engineering View

Application - Data View

Technical Specialist
(Project Organization);
e.g., Application Architect

This stakeholder group is responsible for specifying technology product designs in order to meet projectrequirements and comply with the Architecture Vision of the solution.

KEY PLAYERS

Software Engineering View

Platform Decomposition View

Process System

Realization View

Application - Data View

Application Migration Cost View

Regulatory Bodies
(Outside Services);
e.g., Financial Regulator, Industry Regulator

The main concerns of this group are that they canreceive the information they need in order to regulate the clientorganization, and that their information requirements are beingunderstood and properly satisfied. They are specifically interestedin reporting processes, and the data and applications used to provideregulatory return information.

KEEP SATISFIED

Business Footprint

Application - Application Communication View

Suppliers
(Outside Services);
e.g., Alliance Partners, Key Suppliers

The main concerns of this group are that the information exchange requirements that they have are met in order thatagreed service contracts with the client organizations can be fulfilled.

KEEP SATISFIED

Business Footprint

Service-Information View

Application - Application Communication View

ArchiMate对ViewPoint的分类

ArchiMate架构语言从视图的目的抽象级别来对ViewPoint进行了如下分类:

Viewpoint Purpose


 

Typical Stakeholders

Purpose

Examples

Designing

architect, software developer, business process designer

navigate, design, support design decisions, compare alternatives

UML diagram, BPMN diagram, flowchart, ER diagram

Deciding

manager, CIO, CEO

decision-making

cross-reference table, landscape map, list, report

Informing

employee, customer, others

explain, convince, obtain commitment

animation, cartoon, process illustration, char

  Viewpoint Abstraction Levels










 本文转自 jingen_zhou 51CTO博客,原文链接:http://blog.51cto.com/zhoujg/518615,如需转载请自行联系原作者


相关文章
|
10月前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
223 13
|
6月前
|
人工智能 供应链 调度
|
7月前
|
人工智能 运维 监控
领先AI企业经验谈:探究AI分布式推理网络架构实践
当前,AI行业正处于快速发展的关键时期。继DeepSeek大放异彩之后,又一款备受瞩目的AI智能体产品Manus横空出世。Manus具备独立思考、规划和执行复杂任务的能力,其多智能体架构能够自主调用工具。在GAIA基准测试中,Manus的性能超越了OpenAI同层次的大模型,展现出卓越的技术实力。
|
7月前
|
监控 安全 Cloud Native
企业网络架构安全持续增强框架
企业网络架构安全评估与防护体系构建需采用分层防御、动态适应、主动治理的方法。通过系统化的实施框架,涵盖分层安全架构(核心、基础、边界、终端、治理层)和动态安全能力集成(持续监控、自动化响应、自适应防护)。关键步骤包括系统性风险评估、零信任网络重构、纵深防御技术选型及云原生安全集成。最终形成韧性安全架构,实现从被动防御到主动免疫的转变,确保安全投入与业务创新的平衡。
|
7月前
|
安全 容灾 网络安全
深度用云——释放企业潜能 | 网络先行——阿里云网络卓越架构白皮书正式发布
深度用云——释放企业潜能 | 网络先行——阿里云网络卓越架构白皮书正式发布
245 3
|
8月前
|
弹性计算 负载均衡 安全
【上云基础系列-02】企业推荐!必学必会的上云标准架构(弹性架构)
本文介绍上云标准弹性架构,针对企业业务发展需求,推荐使用多服务器的弹性架构而非单体架构。方案包含负载均衡、NAT网关、云服务器ECS、云数据库RDS等组件,确保业务的负载分担、冗余备份及平滑扩展。通过统一公网暴露面管理和VPC网络设计,保障架构的稳定性、安全性和可扩展性。该架构适用于中小企业上云,避免性能瓶颈和迭代升级困难,支持业务持续发展。更多内容可参考下方演进说明总览。
|
10月前
|
监控 数据可视化 架构师
为什么企业需要开展架构治理?
随着数字化转型加速,企业面临的技术和业务环境日益复杂,传统架构难以应对快速变化的需求。企业架构治理成为数字化转型的关键,通过确保技术与战略对接、优化资源利用、降低风险和复杂性,提升企业灵活性、效率和创新能力,支持快速响应市场变化,推动数字化转型成功。
431 7
为什么企业需要开展架构治理?
|
10月前
|
监控 数据可视化
如何通过建模工具实现企业架构治理全流程管理
企业架构治理工具通过构建统一的架构语言、可视化建模、流程管理、资源整合和多场景分析,实现企业架构的全生命周期管理。该工具赋能企业数字化转型,确保业务、平台、数据及技术相互耦合闭环,提供从规划到决策的一站式服务,助力提升业务运营、优化组织管理和加速数字化建设。
217 2
如何通过建模工具实现企业架构治理全流程管理
|
9月前
|
人工智能 运维 监控
云卓越架构:企业稳定性架构体系和AI业务场景探秘
本次分享由阿里云智能集团公共云技术服务部上海零售技术服务高级经理路志华主讲,主题为“云卓越架构:企业稳定性架构体系和AI业务场景探秘”。内容涵盖四个部分:1) 稳定性架构设计,强调高可用、可扩展性、安全性和可维护性;2) 稳定性保障体系和应急体系的建立,确保快速响应和恢复;3) 重大活动时的稳定重宝策略,如大促或新业务上线;4) AI在企业中的应用场景,包括智能编码、知识库问答、创意广告生成等。通过这些内容,帮助企业在云计算环境中构建更加稳定和高效的架构,并探索AI技术带来的创新机会。
|
9月前
|
监控 架构师 安全
企业架构(EA)项目开发综合指南
企业架构(EA)是一种全面的方法,用于对齐企业的业务目标与其 IT 战略和资源。EA 涵盖了企业的各个层面,包括业务流程、信息流、应用系统和技术基础设施。本指南将详细探讨 EA 项目开发的关键步骤、[EA](https://www.visual-paradigm.com/features/enterprise-architecture-diagram-tool/) 与 TOGAF、ArchiMate 以及其他建模图(如 BPMN 和 UML)之间的关系,以及推荐 Visual Paradigm 作为 EA 团队的最佳解决方案。
389 3

热门文章

最新文章