在《一家典型的互联网创业公司内部架构的演进过程》中我讲述了一个虚拟企业的架构演进历程:
虽然架构的演进看起来顺利成章,但是从烟囱式架构到服务化架构演进, 以及从服务化架构到平台服务架构演进, 大多数公司的实施都会异常艰辛. 除了业务边界难确定外, 业务系统对基础服务和平台服务的质疑也总是彼起此伏. 导致我们的服务化经常处于一个不完整的阶段:
服务接入业务线面临的挑战
- 业务线研发团队不认可基础服务与平台服务的边界: 业务线接入服务后, 业务边界必然会缩小, 由此造成的人员缩减会使业务线团队产生本能的抵触. 同时业务线研发团队的迭代速度很可能高于服务团队的迭代速度, 通用逻辑与特定逻辑的判定决定了服务的边界, 业务的易变性与通用性在业务线研发团队和服务研发团队往往存在较大的分歧.
- 业务线研发团队不认可服务的功能完整性: 业务线研发团队认为服务提供的业务功能无法满足业务团队的需要.
- 业务线研发团队不认可服务的可用性: 业务线研发团队认为服务提供的接口性能无法满足业务团队的需要.
- 业务线研发团队不认可接入服务的工作量: 业务线研发团队认为接入服务的改造工期太大, 影响其对业务需求的支持.
面对业务线研发团队的种种质疑, 服务研发团队必须给出合理的解释才能让业务线研发团队心服口服的接入.而"服务成熟度模型"的理论给服务团队指明了方向.
服务成熟度模型的理论
服务成熟度是衡量业务线系统接入服务风险的一个指标.
计算服务成熟度的前提:
- 业务线系统与服务确定了业务边界
- 测试出具了服务接口的性能测试报告
- 业务线系统根据服务方案与接口预估出了业务线系统改造工作量
计算因子:
- 服务功能完善度
- 接口性能认可度
- 改造工作接受度
服务功能完善度 = 服务已提供的业务线系统接入接口数量 / 业务线系统接入的需求接口数量
接口性能认可度 = 业务线系统认可性能的服务接口数量 / 服务已提供的业务线系统接入接口数量
改造工作接受度 = 业务线系统当前可用人力资源 / 业务线系统对于业务线系统改造投入的人力资源 (不高于1.0)
服务成熟度得分 = 服务功能完善度 0.4 + 接口性能认可度 0.4 + 改造工作接受度 * 0.2
服务成熟度等级:
服务成熟度得分 | 成熟度等级 | 风险含义 |
---|---|---|
0.80~1.00 | M1 | 服务提供了成熟的接入方案, 业务线系统接入风险较小 |
0.60~0.79 | M2 | 服务提供了基本的接入方案, 但细节考虑不全, 业务线系统此时接入有一定风险 |
0~0.59 | M3 | 服务提供了不成熟的接入方案, 业务线系统接入风险较高, 不能接入 |
业务线系统接入服务判断标准:
所有服务均需要达到S1成熟度, 才能接入业务线系统.
服务成熟度模型的实施
服务成熟度报告模板应包含以下元素:
- 业务系统接入的需求接口清单
- 服务已提供的业务系统接入接口清单
- 业务系统对服务接口的最低性能要求清单
- 服务的性能测试报告
- 业务系统对于接入服务的人员工时预估
- 业务系统当前可提供投入支持接入服务的人员工时预估.
根据以上元素和服务成熟度模型, 计算得到服务成熟度等级. 作为业务系统和服务方参考依据.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。