业务架构的重要性

     我们在一个行业做项目实施有10年以上经历，比如银行业，我们会发现，银行核心系统每过三五年，就会有一次大调整，甚至推翻旧核心，重新做新的核心。这个核心更新周期，随着经济发展的速度起伏，做相应的调整。经济发展速度放缓，更新核心周期就相对长一些；经济发展速度如果加速，更新核心周期，就相对短一些。
    其它行业也有相同的更新核心的周期。
    往往我们在做新核心更新项目启动论证时，我们几乎都会有相同的结论：对旧核心布布丁丁已经到了不能实施的地步，旧的核心架构已经不能满足现有的，或将来可预见的业务需要，所以必须启动核心项目改造，用新的核心架构代替旧的核心架构。
    我们对旧核心进行分析时，我们就会发现旧核心的复杂层度已经大大超出我们能够理解接受的范围，就是说核心中的一大部分的功能点，存在重复，或部分重复功能点。如果，因为业务的需要，对一个功能点进行功能拆分，或多个已经存在的功能点进行合并，其结果，我们没有办法预见做了这个功能拆分，或合并，会对整个核心系统有什么影响？对这个风险，没有一个人敢拍着胸脯，敢承担。
    这种现象，对各行各业，对IT行业，无论是应用系统，或软件产品，都是一个结症，都有一个更新周期。圈内人对应用系统，或软件产品，已经固化了架构；圈外人有新的思想，想在找一个突破口，无论通过何种途径，有人际关系、架构、实施技术，等等。
    圈外人即使突破替代圈内人，或并列成为圈内人，过了三五年，可能被新的圈外人同样取代或并列。
    我们不禁要问，为什么会有这样的现象发生？然道在圈内的人比圈外的人智商低吗？或圈外人进入圈内后，智商被弱化了吗？
    我个人的看法，关键是有无一个能够梳理业务需求的业务架构。
    以往应用系统实施，或软件产品研发，几乎都没有一个能够梳理业务需求的业务架构。没有这个梳理业务需求的业务架构，和用这个架构梳理的过程，即使新的应用系统或软件产品“成功上线”，已经存在的大量的重复功能点，和运维期间不断积累的重复功能点，又会把应用系统，或软件产品推到一个死胡同；又把我们推到一个不得不进入的更新周期中。
      各行各业有的是比IT人员更专业的业务专家。业务专家从未梳理过多线条的业务流程功能点，特别是复杂交叉、有重复的功能点。基本上，业务专家与IT人员做业务需求分析，仅仅局限在业务流程的单线条罗列。业务专家与IT人员仅局限这样的共识，做好单线条业务流程罗列的业务需求，就可以开始实施项目了。每一个业务专家，由于部门分工不同，或者岗位不同，他们各自只对他们的一亩三分田业务比较熟悉。从而，他们从未考虑过业务功能点重叠会给IT项目实施带来难题。可悲的是，几乎所有IT人员，或IT实施团队，都没有考虑过这个难题。
        IT人员的优势，特别是架构师，他们会采用业务架构来梳理业务需求。但是，如果IT人员若没有意识到业务架构的重要性，势必会跟随业务专家的意识，被动地拖入到周期性的更新循环当中。
        我们做项目实施，为什么不用业务架构，把设计做在项目动手编码之前呢？