引子是公司会议领导提出的一个问题：
一个运行了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再想点实际的。
虚心接受各网友的批评指教，但叫骂灌水的同学，请还是手下留情，博龄有点短，经不起轰炸：）