当前位置:首页 > 经验学习 > 设计思想

业务架构、信息架构、技术架构三位一体

所属栏目:设计思想 时间:2013-12-26 来源: 作者:admin 点击:

客户天天打电话要修改产品功能,简单的一个需求可能要做一个月。产品越改越笨重,为了赶工期bug越来越多。头疼!
产品从初级版到现在已经四个年头,相关的程序员来去换了三批,在补丁上打补丁是常有的事,很多功能只是开了个头,换个项目经理就被遗忘。我们总是害怕客户在这个产品上提出新的需求,只要客户还用得过去,能不改就不改。即使到了非改不可的地步,也会容忍这些僵化的代码带来的种种限制。
昨天才刚上的功能,忽然又要去掉。客户在使用产品中的这些流程,难道事先就没有人考虑到么?现在说这个功能重要,又说要做各种的接口和延展,需求积压到这个程度,对不起!代码已经改不动了。
出来混,早晚是要还的。
在初期,我们的客户并不了解信息化可以为他带来什么、改变什么。随着时间的推移,企业信息化层层深入,甚至已经演变成企业在市场竞争中的利器,逆转的情况就出现了。企业客户的业务流程从之前的顺应软件,逐步的变为让软件去顺应该企业的发展。于是同一款软件的客户们提出了各种个性化的需求,加功能、改流程、维护优化等等。
那么,我们如何避免这些头疼的问题出现呢?
这些问题出现的根本原因是商业软件的设计与开发方式已经不符合企业信息化的发展要求。现在市面上大多数软件,是几个程序员凭自己对业务的理解,把各种功能拼凑起来成的,在初期这些软件因为弥补了空白,企业确实看到了收获,随着项目的推进和新需求源源不断的产生,系统的维护压力越来越大,而且软件中的业务流程与企业发展过程中的现实流程开始产生偏差,于是软件为了迎合企业信息化的要求不断的修改,最后软件越来越笨重,导致很多新的业务流程无法实现,代码已经改不动了,所以这套所谓企业信息化的系统能解决的大部分是固定程式的业务,企业信息化进入纠结期。
但是,企业已经尝到了信息化的甜头,在强大市场利益的驱动下,越来越多的软件厂商并不一味的纠结下去,开始推出所谓的“客户化”,即以客户为导向,收集客户的需求,搭建业务框架之后再开始编写代码。这种理念并没有被快速的模仿,因为所谓的“客户化”往往把软件厂商弄得筋疲力尽,软件业是个靠大量复制用户而生存的行业,要做到真正的个性化服务需要承担的成本将非常大。所以这种“客户化”的理念,还只是技术架构层面的范畴。
最近在“客户化”的基础上,提出了“业务基础架构平台软件”
按计世资讯的定义:业务架构平台软件是指以业务导向和驱动的、可快速构建应用软件的平台。其包括集成应用平台、开发体系两个部分。从技术角度分析,该平台软件为复杂应用软件系统的开发提供了一个基本框架,并有与之相应的、方便易用的开发与维护管理工具。这个框架给出了一些复杂应用软件的基本组成部分和实现方法,并且预置了很多供参考的软件模块。有了这样的准备,在业务基础架构平台软件之上开发管理软件就可以降低复杂性,省去很多基础性的研发工作,从而大大缩短研发周期,提高研发效率。
这种“业务架构平台软件”其实就是功能模块形式下的“客户化”。通过客户的业务基础框架,软件会有很多模块化的功能和可扩展接口,一方面客户可根据自身的业务特点从模块化的功能池子中选择需要的功能;另一方面,当池子中的功能还不能满足客户需求时,通过模块化的扩展接口,程序员可以在基础平台上迅速的开发新的功能。举个大家熟知的例子:WordPress这款博客软件正是这种“业务基础架构平台软件”的典型,一方面提供很多栏目模块和功能供博主选择,并且提供自定义;另一方面,因为这是一个开源的平台,所以会有各种各样的应用被迅速的兼容进来。我们的软件不需要向客户开源,不奢望客户参与开发,但是如果这个平台有良好的业务架构和技术架构,软件的项目团队在做功能增加和修改的时候只要模块化就行。于是,业务架构和技术架构被放到同一个高度上来,避免出现开发过程以技术架构为主,业务架构为辅,业务进行架构设计之前过早的进行大规模的代码编写。
以上一直在强调模块化,这是“业务架构平台软件”的关键所在,但是这个模块化,现今还处在摸索阶段,三百六十行,每一行的业务流程都不同,但是我们通过大量的流程对比,是能够发现一些规律的,这些规律的组合就形成了模块。《业务架构和应用架构》这篇文章的作者无处查找,但是其中有一段话对业务架构的模块化说明值得借鉴:“初看架构这个词容易理解为静态的事物,但是广义的业务架构一定是静态和动态分析的集成和融合,在分析过程中相互影响又相互促进。动态的信息即我们说的普通的价值链分析的思路,从企业端到端的一级流程到各个业务领域二级,三级等流程的分析。形成一级流程->子流程->活动->活动单元->任务->事件的主线;而对于静态信息则包括组织,人员,岗位,角色,业务对象和表单,规程,模板等各种信息。静态信息的重点是业务领域和业务对象,即形成业务领域->业务主题域->业务模块->业务单元->业务组件的静态数据逐层分解。静态信息+动态信息+交互点和接口分析后形成完整的业务架构。可以看到流程再细粒度分解后的活动单元的组合可能形成业务组件和业务模块,同时业务模块本身又存在更细粒度的流程和活动分解,业务组件本身又是多个流程的组成部分,因此静态和动态相互融合,形成交互,所以必须分析交互和接口。”

请站长喝杯咖啡?

站长一直坚持白天工作、晚上熬夜更新素材,付出了巨大的精力和时间,其中的辛酸难以言述。

坚持免积分、免登录、无任何限制下载!如果本站素材对你有用,不妨考虑请站长喝杯咖啡鼓励一下!

标签:

你应该也喜欢这些吧

共有 0 条评论

给个评价吧

验证码: