管理软件架构的架构

来源:用户上传      作者:

　　世界上最伟大的架构师应该是李冰父子，都江堰在2000年后还是活的，还在发挥重要作用。管理软件的架构境界亦应以都江堰为榜样。
　　
　　关于系统架构，我们所了解的东西并不少，评价的标准也不少，一个知名软件公司的总架构师地位相当的高，可以很牛，可以让人高山仰止。事实上任何一款软件都依靠一定的技术与业务架构才能进入开发与应用，它渗透在软件产品的整个生命周期里面。平台软件自身已经有了一个架构，可以支持多种业务的实现方式，也就是支持多种业务架构的方式。也恰是因为如此，具有经典存见的人看到另类的业务架构时候，就会认为一定不规范，不合规矩。
　　最近在手头的几个项目合作中就发现了这样的情况，后来经过仔细考虑，也不觉得奇怪了。那么在互联网时代，到底有没有一个架构以上的架构呢?我认为是有的，而且还有一定的规律可循。这里说的第一个架构，是底层的结构，类似PC的操作系统，而第二个架构则是应用的结构，类似于办公软件，游戏软件以及专业绘图软件这样的应用。底层的是一个相对较慢的变量，应用面上的是一个相对较快的变量。企业管理本无定法，行业企业的差异比较大，不可能完全按照一个架构思想去实现，典型的就是BOM――MRP的业务与技术融合的一种结构。关于ERP软件僵化的结构可能引起它的没落已经有很多讨论，这里不多重复。有一个鲜明的情况是许多名义为ERP的管理软件，已经采用非BOM――MRP的应用逻辑了，之所以还叫做ERP，其实已经将它视同为管理软件的代称。从实际的应用架构方面很多人已经作出了新的探索，比如将时间理念引入的，将项目管理思想引入了，将复杂性科学的原理引入的，呈现出百花齐放的景象来。
　　架构之上的架构有一定的规律可循，是基于最近四五年笔者接触的几十个平台软件项目做的小结。业务的迭代性和需求的多变性，它们对管理软件的技术实现提出了非常苛刻的要求，虽然说代码的修改量多少不应该成为架构持续有效性的一个测量指标，但是确实系统的技术频繁变更一定不是优质架构的表现。那么如何做到技术最小量的变更响应业务的不确定性变化呢?这个规律就是从这个角度进行总结和认识的。这可以通过下面的业务应用架构要素分析表来观察。
　　基于这样的分析表，可以看出隐含着的一个重要架构元素――策略。在业务基础中可以组合或者定义的策略，业务过程中引用这些策略适应瞬变的业务需求，业务结果的分析方式也可以设计出多种策略模式，在业务需要的时候通过简单的配置就可以“造出”符合当下需要的业务模式来。
　　策略，在许多软件中有广泛的应用，但是在管理软件中一直被限制在配置和定义一定的属性的时候使用，其实在我们对业务进行抽象的过程中，发现它可以处理复杂需求环境下的能力与资源匹配难题，这样就支持了业务的可持续发展。所不同的是，这些策略需要与时俱进地进行升级，否则会产生刻舟求剑的效果，人们就看不到平台软件所带来的便利与灵活，而是僵化了。
转载注明来源:https://www.xzbu.com/8/view-8777519.htm