为什么无论是十万级还是百万级的解决方案,开发商对需求变更的响应速度都会越来越慢?

 

1在过去很长的一个阶段中,校园信息化建设中架构设计的目标仅仅只是为了满足当下已知的管理流程需求,一切均建立在“需求不会马上变更”这个大前提之下。2

因此,基于这个大前提而设计的系统架构,最典型的表现即为代码耦合度高。

代码耦合度很高的情况下,当需求变更时,复杂度扩散将难以控制。

维护代码时修改一个地方会牵连到其他很多地方,如果修改时没有理清这些耦合关系,那么带来的后果也将是灾难性的。

3

所谓牵一发而动全身,不外如是了。

改动一个模块,要做10个其他模块的回归测试,开发三天,测试10天。问题永远改不完,开发和测试都在各种问题之间奔波劳累,最后导致项目延期,成本增加,用户满意度降低。这也解释了为什么不管是十万级还是百万级的解决方案,项目越往后进行,开发商的支持响应都会显得越来越不积极。

因为随着项目的逐渐深入,老的架构会导致新需求变更时的投入越来越大,最终导致投入产出比失衡。

于是学校和厂商两败俱伤,要么重做,要么重做……

4
难道真的只能靠一次次推倒重做来实现项目的迭代?
5事实上,业界都非常清楚,

学校从信息化项目立项,

到与众多厂商沟通项目需求,

外出考察调研,

进行顶层设计、产品选型、个性化设计,

再到招投标、签署合同,

进行项目实施,

直到最后项目验收交付时,

时间几乎已经过去了一两年。

当初规划设计时那些自认为很酷炫的功能点

以及自认为很精妙的解决办法,

在一年多之后真正交付用户使用时,

已明显满足不了新的需求,

一波波的过时感令人猝不及防。

 

校园信息化建设日新月异,

管理与服务的需求不断变化甚至呈爆炸式增长,

将原来失败的项目推倒重做,

难道就能避免同样的宿命吗?

 

针对此问题,我们提出了基于微服务架构的智慧校园创新解决方案,倡导以动态发展的眼光来规划架构设计。不追求画大圈一次性涵盖所有需求,而是通过先画小圈,在过程中观察需求的变化,然后擦掉小圈,扩大范围,画更大的圈,通过不断的修正来逐渐逼近真实的需求,真正解决用户的问题。6

微服务架构通过“领域驱动模型”将原有的单体系统重新规划成一个个可独立运行的小服务,小服务之间通过轻量级的接口重新组织成一个整体的应用,对外提供服务。

这么做的好处有很多,其中最重要的变化就是极大降低了代码的耦合度。

当需求变更时,代码的维护和修改只会发生在局部,不会对其他模块造成任何影响。

比如基于微服务架构的教务系统,即使在选课时因并发量过大导致选课模块崩溃,也不会影响成绩录入、信息查询等其他模块功能的正常使用。

所以我们认为,好系统不是设计出来的,而是改出来的。

联奕微服务解决方案,就是要将需求变更的权利重新交给学校。

让学校可以不再因为担心系统大面积出错而放弃需求变更,强忍不便去适应并不好用的各种系统。

从今天开始,请大胆地进行需求变更,我们的目标是——不要凑合,要绝对适用~

7

双11,我们在广州长隆等你!

点击阅读原文立即报名吧

↓↓↓↓↓↓