敏捷、分布式、ALM过程自动化、企业应用架构
posts - 14, comments - 0, trackbacks - 0, articles - 1
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

企业技术体系架构建设

Posted on 2012-03-29 16:27 一酌散千忧 阅读(1296) 评论(0)  编辑  收藏 所属分类: 企业架构

软件企业的技术体系架构包括对软件产品本身及生产过程、软件生产环境及生产者的管理和支持,此架构应当基于下列五项基础建设之上:

l 开发技术架构

l 开发环境架构

l 过程管理架构

l 企业产品架构

l 企业人件架构

下面详细介绍各项架构的内容及特点。

 

 

开发技术架构

开发技术架构作为一个软件企业的基石,包括可复用的架构组件、公用的基础代码库等。开发技术框架应当在一个良好的过程管理之下,严格的质量管理与实用性检查,并且鼓励普通技术人员的参与。

1.建立技术架构仓库标准体系与维护模式。建议使用MAVEN作为所有开发技术(包括架构预研与实际项目开发)的基础项目管理工具,实施严格的质量管理和持续集成。

2.选拔组建高素质的架构师队伍,并且鼓励技术人员参与到技术架构仓库的构建和维护。

3.加强技术架构实用性与适用性的检查与改造。

4.架构运营模式的考察,技术架构的改进与预研。技术架构的预研模式比较复杂,多个部门中多个项目可能都会要求进行多个同类框架的考察、比较、环境搭建等工作,若集中在独立架构组可能压力较大。可以考虑架构组内部划分为多个技术领域,如企业基础应用架构、消息中间件、动态化组件、分布式集群等。以技术部门的实施领域作为导向,进行技术架构的预研。

5.开放知识系统的构建(内部wiki,个人博客,视频分享)

根据企业行业背景,需要关注的技术领域包括:企业应用、ESB/SOA、大型分布式架构(在线/离线),自然语言处理。

 

开发环境架构

包含IDE,编译环境,远程支持,通讯支持与其他大量功能性支持软件,并可以根据不同的工作角色制定不同的环境,以便排除干扰,更加快速有效的进入工作状态。

项目的关键问题是沟通,个性化的工具妨碍——而不是促进沟通。开发和维护公共的通用编程/项目管理工具有很多的好处。

1.建立具有鲜明特色与强大实用性的自有开发环境,展示一个软件龙头企业在企业技术沉淀中的深厚功力和规范性。

2.建立行政流程以规范和约束开发环境管理。

3.划分相关职能以保持对开发环境的维护

4.建立多种培训机制以促进新员工能够迅速投入工作。如固定新员工开发环境熟悉培训机制,建立企业讲解&培训视频库,小组内互助&沟通。

 

过程管理架构

1.过程方法

对多家企业软件生命周期中使用的过程方法进行调查了解到,大部分优秀的软件企业对于过程方法十分重视,且存在针对不同项目合理运用不同的过程方法。项目经理对于过程方法的理解与运用常常关系到项目的成败。

目前核心的管理模型/过程方法主要分为三大类:CMMI,RUP,敏捷。

CMMI作为软件质量体系的标准,软件企业必须具备的资质,具有文档齐全,流程规范等优势,对于大型核心项目有较大优势,其劣势在于灵活度不足,无法很好的满足日益变化的需求。

RUP由Rational公司(被IBM收购,目前是IBM 软件集团旗下之第五大软件品牌)提出,采用迭代开发模式,四个阶段,九大核心工作流,明确的角色划分与文档规划,可裁剪配置的开发过程。目前被大量的软件厂商作为最核心的过程方法使用。

敏捷(Agile)为了满足队伍小型化和需求快速变化而产生的目前最流行的过程方法。XP(Extreme Programming)通过简单的四个核心价值(沟通(Communication)、简单(Simplicity)、反馈(Feedback)和勇气(Courage))与十二条最佳实践从研发的角度提出了最简单直接的开发方式。XP的形态特殊,从编程的角度描述方法与原则,加入了SCRUM之后,加强了从行政体制方面的支持,从而形成了完整的敏捷开发的过程方法体系。

 

过程方法一定不是万金油,针对不同的企业特点,甚至不同项目,都有必要对过程方法进行合理的裁剪与整合。对于目前公司的情况,大型核心项目可以使用CMMI,这些往往决定了企业的战略方向,稳健的过程方法最为合适。大部分中小型项目均可采用 RUP+敏捷 的过程方法,即遵守RUP的核心阶段和工作流,但是迭代周期和开发的基本原则根据敏捷,并挑战整合部分敏捷方法中的最佳实践。这样的策略用于面对市场需求的快速变化,同时也能很好的保障企业在软件生产中的产品价值保存和技术经验积累。

 

2.过程方法自动化支持

针对不同的过程方法,往往有若干的软件产品用以快速自动化的实施。如实施CMMI时所使用到的DEVSUITE产品。完整体系的支持产品往往在应用于某套固定方法有着良好的效果,但容易存在流程生硬,无法与开发环境更好结合形成了信息孤岛,改进困难等缺点。一套优秀的过程方法支持软件,需要和开发环境(如IDE等)良好结合,并且易于调整以应对过程方法的变化,同时没有复杂冗余的过多细节流程以便容易被开发人员学习和掌握。

产品涉及方面:项目计划、项目需求管理、软件配置管理、自动集成、自动产品发布、代码审核、代码质量管理等。

 

 

企业产品架构

1.产品/产品需求流程补充,产品立项时的立项报告中应当包含市场、竞争对手、对手产品、风险等分析。

2.领域模型与概念,在特定的行业中可以即使关注领域专家的动态,以便构建正确的领域模型,确定产品的发展方向和形态的正确性。

3.对于特定产品的领域概念及相关技术发展需要深入了解,如舆情分析系统,需要进行了一定的市场调查,跟进了当前领域专家的报告,参考国内外多项相关项目的设计理念和原则。对于目前市场状况、未来的方向、目前的技术实力等要有比较清晰的概念

4.坚持以市场为导向的原则,在商务部门与研发部门之间搭建积极的沟通桥梁,研发部门的计划根据实际市场需求进行调整。产品的发布配合市场的要求,达到利益最大化。

 

 

企业人件架构

企业自身环境除了常见的软件(Software),硬件(Hardware)以为,还应当加入人件(Peopleware)。之前的种种,如过程方法、技术架构积累、知识分享等均是为了将整个企业构建成为一部精密的机器,无论缺少什么重要零件均可以快速修复,但是人员流失所造成的损失是巨大的。目前公司有着良好的软硬件环境,技术部门作为发动机,若在针对技术性员工有特别的规划和关心,必然能够增强在整个市场中的竞争力,对企业自身的发展也是有良好的推进作用。

公司可以按照职位和员工自身的情况规划发展路线,明确技术目标。开发进化角色基本按照软考标准,程序员-高级程序员-软件设计师-系统分析师-系统架构师,程序员-高级程序员-项目经理。

在技术部门内部,可以定期组织交流心得、新技术等。(在SCRUM中实际上有一些比较好的行政手段可以借鉴参考)

由于软件技术部门的特殊性,一些应用于生产线的行政制度可能能够讨论出更好的实施方案,避免员工单方面的错误认识引发消极的工作态度。

由于有一定经验,而且公司技术架构建设的需要,能够很好的协助企业进行技术架构全方面的介绍和培训。而且我自身也很希望参与到企业文化的建设工作中去,鼓励技术人员之间的技术交流与沟通。

 


只有注册用户登录后才能发表评论。


网站导航: