写点什么

2011 企业信息架构设计:换位思考的一年

  • 2012-01-15
  • 本文字数:1797 字

    阅读完需:约 6 分钟

如果直接谈“企业架构”,也许很多圈外人会把它扩大化,毕竟对于一个企业的“顶层设计”而言,企业架构主要是组织架构、生产架构,行政架构等,而我们圈里人谈的“企业架构”其实主要指的是“企业信息架构”。

作为我国企业信息架构风向标的“金”字头项目,他们在 2011 年体现最明显的不是云计算、大数据、列存储等技术的引入,关键在于切入点的转变。

我们知道,一般信息系统建设都是从以业务需求收集和分析入手、从企业高层的战略目标入手,CIO 需要解决的问题基本上是业务高层的谈到的一系列“我们要”、“我们决定”、“我们希望”,但在 2011 年光凭这个切入点似乎不足以成为大型“金”字头项目立项的基础,因为这些指标它无法体现作为大型企业、超大型企业信息系统如何满足“社会关切”的问题。

下面看一个简单的例子

以往:

1、 在人力基本不变的情况下,我们需要借助该系统实现每年多查获 100 万件食品安全事件,多受理 5 万件相关案件。

2、 系统升级后,每年网站订票数量增加 400 万、电话订票数量增加 200 万。

现在:

1、 在人力基本不变的情况下,我们需要借助该系统将食品安全事件的受理时限从 1 天缩短为 15 分钟,通过食品供应链透明化每年食品安全事件发生率降低 10%。

2、 系统升级后,用户单次在线订票成功率提高到 60%、五年内提高到 80%,电话订票平均处理时间降低到 5 分钟 / 呼叫、五年内降低到 2.5 分钟 / 呼叫。

不知你是否发现两者最大的区别?

  • 以往,企业信息架构往往是在自己找需求,然后自己给出技术解答。
  • 现在对这些大型、超大型企业信息架构的要求变了,目标和需求是来站在服务对象角度发掘的,即为什么投资这些系统,不是承办主体“我们要”怎样,而是因为你能为“服务对象”怎样,权衡投入产出之后再考虑是否建设。
  • 相应的架构流程有了一些变化(以经典的 Zachman 框架为例):

其中,标准流程位于“Zachman Framework Enterprise Architecture”部分,但现在必须外延到“服务对象关切”部分,尽管传统的“上下文”部分本应该包括这些内容,但在实际操作中往往会“走样”成“我们要”的情况。架构其他规模、其他类型的企业信息系统时这个思路同样适用。

进一步,可以将上述过程与领域设计分析结合,根据分析内容与业务的相对“距离”渐次展开:

以上面的业务关切为例:

电话订票平均处理时间降低到5分钟**/呼叫、五年内降低到2.5分钟/**呼叫

先做外部领域的企业架构分析:

What:电话订票

Why:原因比较明显,谁愿意花费几十分钟甚至几个小时订票?

How:降低订票手续的繁琐程度,减少等待时间、咨询时间、选票时间

Who:乘客、接线员

Where:手机、固定电话

When:全年服务时间

最终需要围绕“电话订票平均处理时间降低到 5 分钟 / 呼叫、五年内降低到 2.5 分钟 / 呼叫”这个既定的量化目标分析,为了满足这些要求外部应该满足什么条件,相应的对企业内部信息环境要求是什么。

以 5 分钟完成电话订票的“关切内容”为例,如果通过分析必须将“等待时间”限制在 0-1 分钟、“咨询时间”限制在 0-1.5 分钟,“选票时间”限制在 0-4 分钟,相当于我们就必须对企业内部各相关应用、数据、网络的架构设计提出明确量化要求,同时对于各关联系统的处理效率、数据 OLTP 响应时间、网络往复时间提出明确要求,然后这些要求转化为传统的企业架构设计中“战略”、“业务”设计要求时就更具目的性,这个过程就好像常说的“换位思考”。

2011 年由于项目立项申请方式的转变,一些“金”字头的企业信息系统架构开始走“先换位思考,再设计企业信息架构”的过程,这个过程的积极意义如下:

  • 首先,提高企业信息架构的目的性,明确投入 / 产出关系
  • 其次,通过增加“外部领域分析”过程,可以对用户的期望和需求做先手布局,以往我们总是说“唯一不变的是变化本身”、“客户的需求千差万别、随时变化”,但现在我们应该反过来考虑,是不是我们最初没有站在他们的角度考虑这些问题,而是“一厢情愿”的“自说自话”出一些所谓的企业信息架构“战略”、“业务需求”
  • 接着,尽管用户关切的内容可能会用“更快”、“更方便”这些模糊的表述,但通过“外部领域分析”,我们可以将这些关切标准量化并分阶段实现,通过量化指标推动企业信息架构建设工作

不过,空谈“换位思考”比较容易,但做到很难,实践中较为现实的方式除了直接面向用户进行调研外,考察服务对象的“对口系统”也是不错的方式,以往我们常说团队需要沟通,其实具有互联关系的内、外部企业信息架构之间又何尝不是呢?

2012-01-15 06:232826
用户头像

发布了 61 篇内容, 共 10.7 次阅读, 收获喜欢 0 次。

关注

评论

发布
暂无评论
发现更多内容

深入理解Flutter相机插件【Flutter专题22】

坚果

flutter 28天写作 签约计划第二季 12月日更

netty系列之:小白福利!手把手教你做一个简单的代理服务器

程序那些事

Java Netty 代理 程序那些事 12月日更

React进阶(五):导航守卫

No Silver Bullet

React 路由 12月日更

吃透负载均衡

高性能架构探索

负载均衡 架构 分布式 微服务 签约计划第二季

Flyway让数据库版本管理更简单

恒生LIGHT云社区

数据库 sql SqlServer

用户文章转载:一图看懂 | 我用这张图,看懂了 P4 Reconcile

龙智—DevSecOps解决方案

perforce 一图看懂 P4 Reconcile

Game On Serverless:SAE 助力广州小迈提升微服务研发效能

阿里巴巴云原生

阿里云 Serverless 云原生 SAE 合作

react源码解析11.生命周期调用顺序

buchila11

React

JerryScript:物联网开发者的得力工具

华为云开发者联盟

物联网 LiteOS JerryScript 引擎 物联网应用

欢迎举报Perforce Helix Core盗版行为

龙智—DevSecOps解决方案

盗版软件 perforce盗版 打击盗版

给弟弟的信第13封|一个北京姑娘的艰辛生活

大菠萝

28天写作

有了代码变更分解提交工具SmartCommit,再也不担心复合提交了

华为云开发者联盟

代码 复合提交 SmartCommit 代码提交 代码提交原子性

面试官:react中的setState是同步的还是异步的

全栈潇晨

React

C++ 开发笔记

行者孙

内容合集 签约计划第二季

阿里云田涛涛解读未来自动化运维新思路:CloudOps

阿里云弹性计算

CloudOps 云上运维

流量控制-从原理到实现

高性能架构探索

架构 分布式 微服务 签约计划第二季

实用机器学习笔记十四:多层感知机

打工人!

人工智能 机器学习 算法 学习笔记 12月日更

彻底搞通服务发现的原理和实现

高性能架构探索

架构 分布式 微服务 服务发现 签约计划第二季

技术实力过硬,旺链科技斩获“年度区块链技术突破奖”!

旺链科技

区块链 区块链技术 产业区块链

【LeetCode】寻找旋转排序数组中的最小值Java题解

Albert

算法 LeetCode 12月日更

亿级流量实验平台设计与实现

高性能架构探索

架构 分布式 微服务 签约计划第二季 实验平台

Linux中国对话龙蜥社区4位理事:龙蜥操作系统捐赠的背后,是谁在推动?

OpenAnolis小助手

Linux 国产操作系统 龙蜥社区

面试官:useLayoutEffect和useEffect的区别

全栈潇晨

React

前端架构师修炼指南精选

杨成功

前端 架构师 内容合集 签约计划第二季

智能运维之时间序列预测中的经典时序模型

云智慧AIOps社区

机器学习 算法 智能运维 云智慧 指标预测

react源码解析12.状态更新流程

buchila11

React

Scrapy Spider中间件,你学会了吗?本篇博客有一案例

梦想橡皮擦

12月日更

面试官:如何实现 List 集合去重?

王磊

java面试

带波浪效果的CollapsingToolbarLayout + RecycleView

阿策小和尚

28天写作 Android 小菜鸟 12月日更

lock-free在召回引擎中的实现

高性能架构探索

架构 分布式 微服务 签约计划第二季

一文带你熟知ForkJoin

华为云开发者联盟

jdk 并发编程 并发 forkjoin 多线程并发

2011企业信息架构设计:换位思考的一年_SOA_王翔_InfoQ精选文章