资讯专栏INFORMATION COLUMN

关于公司架构管控的思考

didikee / 2464人阅读

摘要:由此提出架构审批流程不代表架构设计架构规划部门要加强架构管控。开发团队对科技公共平台的不熟悉强制使用业务数据模型混乱新需求控制创新三形成架构管控目标控制新增外购系统的架构方案的合理性梳理既存外购系统的架构提升开发效率。

假想背景:
现状是,各子系统的新建及重大迭代都会形式化地走架构审批流程,但应用架构是否设计以及是否合理,信息技术部门不能掌握。而架构规划部门的架构师人屈指可数,面对总人数达数百人的开发团队所负责的几十子系统、每个月数十个迭代特性,无法做到直接帮助开发团队详尽的进行架构设计。由此提出:架构审批流程不代表架构设计、架构规划部门要加强架构管控。

要做好架构管控,需要能够回答几个问题:架构管控的目的是什么?架构管控的目标是什么?架构管控需要管控什么内容?如何进行管控?

一、目的

一个稳定发展、创新发展的企业,支援业务发展的信息系统的稳定与效率同等重要。架构管控的目的,要指导各团队技术负责人设计出合理的系统,能够满足稳定与开发效率的要求,能够满足功能与非功能的需求,能够考虑到各级相关者的意见;并且还要有考察开发过程及运营过程的机制,以确定最终交付的软件系统复合架构设计及开展架构设计的持续改善工作。

二、制定目标

为了达到这些我们架构管控的目标又是什么呢?发布一份指导意见?发布一份制度说明?发布一份评分表?
我认为这些应该归属于如何进行管控,而不是目标。
我们需要梳理现状,找出主要矛盾,量化主要矛盾,形成目标(SMART原则别忘记~~)

(一)、主要生产问题、客户投诉及分类

从客户反馈中可以抓住主要矛盾。

(二)、信息技术方面的主要矛盾

外购产品 vs 二次改造
早期从外部采购的产品一般会使用比较老旧的开发框架,进行二次改造困难,常带来较多故障,并且开发效率低下。

系统解耦 vs 互相影响
分布式带来较好的伸缩性等非功能特性的同时,也带来了复杂度 —— 系统间相互影响较难控制,给设计和开发增大了难度。

开发团队对科技公共平台的不熟悉 vs 强制使用

业务数据模型混乱 vs 新需求

5、控制 vs 创新 (三)、形成架构管控目标

控制新增外购系统的架构方案的合理性、梳理既存外购系统的架构、提升开发效率。

降低分布式系统的开发难度、提升分布式系统的交付质量。

降低科技公共平台的使用难度。

引导、规范新技术的引入。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/11968.html

相关文章

  • 2017双11技术揭秘—阿里数据库进入全网秒级实时监控时代

    摘要:每秒实时处理超过万项监控指标,让异常无所遁形。此外,对于复杂数据库故障事后排查故障根源现场还原历史事件追踪也迫使我们建设一个覆盖线上所有环境数据库实例事件的监控系统,做到覆盖阿里全球子公司所有机房。所有性能指标做到秒级连续不间断监控。 摘要: 2017双11再次创下了32.5万笔/秒交易创建的纪录,在这个数字后面,更是每秒多达几千万次的数据库写入,如何大规模进行自动化操作、保证数据库的...

    jk_v1 评论0 收藏0
  • 将军令:数据安全平台建设实践

    摘要:解决方案如图所示,将军令分块,数据内容权限平台审批流平台审计日志平台提供各种灵活可插拔的服务,支持在通用服务的基础基础上进行定制开发。 背景 在大数据时代,数据已经成为公司的核心竞争力。此前,我们介绍了美团酒旅起源数据治理平台的建设与实践,主要是通过各种数据分析挖掘手段,为公司发展决策和业务开展提供数据支持。 近期,业内数据安全事件频发,给相关企业造成了无可挽回的损失,更为数据安全防护...

    vpants 评论0 收藏0

发表评论

0条评论

didikee

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<