引子是公司会议领导提出的一个问题:
一个运行了7、8年甚至10年的企业应用系统,参与的开发人员走一波又来一波,如何让一个新员工对其感兴趣,学习业务,研读程序,还要进行维护改造?
答案是无能为力。为什么?
技术陈旧,架构过时,业务繁杂,代码粗糙,bug无数,上一代积攒遗留下无数的暗坑,等待着新人怀着愚公移山的精神去填埋,压力山大,这样的新人鲜有存活。
对于甲方用户来说,如果业务一成不变,十年如一日的重复着相同的工作,那么系统只要稳定不出错,机器不坏,数据不丢,性能不差,那就再好不过了,人人都可以做好撞钟和尚这个岗位。但是,时代在发展,改革在前进,看看周围,什么都在变化,业务要发展,系统也要变更,不变是不可能了。硬件、软件的改变,不仅仅是花钱,还要花费时间、花费更多的人力资源。
一个庞大复杂陈旧的应用系统,如何去适应新业务、新规则、新技术?修修补补,还是回炉重造?一个是短期阵痛,一个是伤筋动骨,怎么选择,这时就要看乙方了。甲乙双方长期关系融洽,乙方有足够能力,时间短,花费又不多,就能达到目的,领导又不想大干一场,修补是很好的选择。但如果系统是一个接近烂尾工程的标准,维护不力、改造费时费力又费钱,特别是如果碰到新官上任,那废弃重建就是一个必然的选择了。
对于乙方开发商企业来说,稳定的技术团队,懂技术懂业务的骨干能挑担,良好的客户关系,撑握几个重要的金主,才是企业的生存之道。所以一个长久可持续发展的应用软件系统,可以为甲方提供稳定长期的有偿服务,不断的改进系统,延长系统的生存能力,提高服务质量,才能使企业得到更好的发展。
相较欧美市场,我国企业信息化投入偏低,小微企业市场信息化覆盖率仅仅维持在6%左右,这也注定国内大多数软件企业严重依赖大客户。软件公司大部分都是非国有企业,软件公司的客户则是政府和大公司。国内大多软件公司的技术能力是很弱的,在面对客户的时候,它们毫无议价能力,基本上是干很低端的活,赚很辛苦的钱。很长一段时间生活在生与死之间,这也是中国软件行业发展这么多年没有很大公司的原因。
所以目前在僧多粥少,权势公司、关系户公司众多的市场环境下,作为一个应用软件企业,如何有底气的生存和发展?这个严峻的问题摆在各个企业面前。
在此,对应用软件系统架构进行一些有限的探讨(首先承认,能力经验有限,抛砖引玉),我觉得这可能是企业提高自身的一个方向。
公开发布的企业架构开发方法有很多,很多方法是基于相应的企业架构框架。比较著名的有下面几种企业架构开方法:TOGAF中的ADM(架构开发方法)、DoDAF的六步过程、基于Zachman框架的企业架构规划(EAP),以及联邦企业架构(FEA)实用指南中的架构开发过程。
众多的方法中,TOGAF还是比较适合理解的,ADM方法是一种用来获得特定组织企业架构的方法,特别为应对业务需求而设计。
TOGAF(The Open Group Architecture Framework, 开放组织体系结构框架),把企业架构分成四大架构领域:业务架构、数据架构、应用架构、技术架构。
这四种架构,每一种都可以好好的说道一下,但限于能力及立场,我仅站在应用软件开发企业这一乙方的角度来分解。
业务架构,在甲方看来,是商业策略,管理,组织和关键业务流程。但是对乙方而言,就是一个有组织、有内容、有流程的用户需求,开发出来的应用系统,最终是为实现业务架构服务。
数据架构,描述一个组织逻辑的和物理的数据资产和数据管理资源的结构。包含各种业务含义的数据信息点,通过一系列业务规则,进行结构性的联合、转变、分散,达到实现某种业务目标。
应用架构,各个数据信息好比各种车辆交通工具,而应用架构就好比是一张地图,车辆在地图上规划的道路行驶,到达某一目的地。架构好,畅通无比,架构不好,就象大城市里的堵车,天天添堵。
技术架构,应用架构的具体实现方式,一条路,铺点泥沙碎石也能行车,浇沥青柏油也行,双车道总比八车道开的慢吧,高速公路更快。
换个好理解点的方式,组合在一起就是一台电脑。我要看大片,我要打游戏,我要上网,我要QQ,我要写报告,我要......,这就是业务需求;网页、图片、文档、电影、游戏帐号等等就是数据,你能说1G的电影文件里没有结构,在电脑硬盘内存里跑来跑去的都是二进制数据串;win95还有人用吗,都win8.1了,linux、MAC...太多的操作系统了,各种浏览器,office,播放器,游戏软件,这些都是为达到业务目标而采用的应用,好象也与技术有关不是吗?这样想:为什么不在win95上跑64位软件,微软有office,金山有wps,windows不是还有写字板吗,用什么样的软件达到目的,这就是应用架构设计要达到的目标。最后的技术架构就更好解释了,键盘、鼠标有线的无线的,都要接到主板上,AMD和Intel的CPU主板不通用吧,windows与linux不一样吧,这就是用不同的技术实现达到最终的业务目标。
好了,作为一名应用软件开发IT人员,咱还是关注咱的应用架构和技术架构吧。
面对的业务行业不同,业务目标、业务架构是多种多样的。
关注于事务性、状态性,数据一致性、准确性的高敏感,象各种企业ERP、CRM、财务、各种MIS系统等。
关注于非事务性访问,海量用户,社交群体等,象各种网站、论坛等。
关注于数据实时性、信息同步的一致性,高性能,高可用等,象交易系统、定单系统等。
关注于流程性,协同性,象OA、行政审批等。
关注于数据挖掘,统计分析,象数据仓库、决策分析系统等。
关注于展示创意、效果,媒体加工等,象广告、影视、音乐、流媒体等。
关注于科学计算、桥梁建设等,象天气预报、地理勘探、建筑CAD等
还有更多,我这种分类也不见得准确。
但抽象概括一下就只有get与set,用户通过应用系统,将现实中的各种数据信息,变化信息,set给应用系统,经过种种计算处理,形成我们想要的数据,保存于某种物理介质上,再通过各种展示方式get给用户,或者通过某种get反馈给需要的其他系统或应用。在set与get之间,会遇到无数的环节和问题,这就要靠应用架构和技术架构合作来完成这条通路。
吐槽了这么多,不管对与不对,这只是我本人的一种思想,先写到这,有点虚,后续2再想点实际的。
虚心接受各网友的批评指教,但叫骂灌水的同学,请还是手下留情,博龄有点短,经不起轰炸:)
相关推荐
在企业级应用软件架构开发过程中,我们关注的不仅仅是技术实现,更重要的是如何设计出能够满足大规模、高并发、可扩展性、稳定性和安全性的系统。本篇内容将围绕这一主题,依据提供的章节名称,深入探讨企业级应用...
这要求企业应用软件架构设计不仅要高效、稳定,还要能够适应业务需求的变化。《企业EA - 应用软件架构设计规范》正是一份旨在指导企业如何设计出既符合当前需求又能适应未来变化的应用软件架构的文档。 首先,规范...
### 企业级应用软件架构开发过程与实践:深入解析 #### 软件与软件的特性:业务上下文视角 软件作为一种独特的制品,其特性显著区别于传统实物制品。最初,软件仅被视为科学计算的工具,但随着其功能的拓展,软件...
适读人群 :适合软件架构师和想成为软件架构师的人阅读 ... 本书着重介绍软件架构相关的内容,非常适合软件架构师和想成为软件架构师的人阅读,而且首席开发者和各种.NET应用程序的开发者也能从本书获益。
《企业级应用软件架构开发过程与实践》深入探讨了企业级软件开发的理论与实践,尤其聚焦于软件架构的关键作用。以下是对该书核心知识点的详细解析: ### 软件与软件特性 软件,作为一种独特的人造产品,拥有与传统...
企业应用软件总线(EASB,Enterprise Application Software Bus)是一种高级别的软件架构模式,旨在集成企业内的各个应用程序,通过标准化的接口实现不同系统之间的通信与数据交换。EASB建立在应用服务器之上,充分...
企业应用系统架构与设计模式,企业应用系统架构与设计模式
通过对胶凝砂砾石坝施工质量监控系统的需求分析和设计,我们选择了面向服务的、基于 SOA 的企业应用集成,实现了资源共享和系统间的互操作性,提高了系统的灵活性。 一、服务提供者 服务提供者主要完成服务的设计...
《Microsoft .NET 企业级应用架构设计》第二版是一本深度探讨.NET平台下企业级系统构建的权威著作。这本书详细阐述了如何运用先进的设计原则和模式来构建高效、可维护且易于扩展的软件系统。作者深入浅出地讲解了...
Microsoft+.NET企业级应用架构设计 一本好书,无需多言
Microsoft.NET企业级应用架构设计.pdf 软件架构师学习资料
1. 业务架构:关注企业的核心业务流程、组织结构、业务场景和信息流。它定义了公司的业务目标、职能分配、业务流程、活动和步骤,以确保业务流程的有效执行。 2. 应用架构:这部分关注如何通过软件系统来支持业务。...
该手册涵盖了企业架构的总体框架、业务架构、数据架构、技术架构、应用架构等方面,并对企业架构设计方法、企业架构管控方法、企业架构内容框架等进行了详细的解释。 企业架构总体框架是企业架构设计的核心,企业...