IT是一门艺术,是产品/技术/过程/人员的交响曲

 

我们也许经常会遇到各种问题,比如:

        约好了客户讨论需求,但客户突然有事情要处理,使我们的计划被打乱;

        我们跟客户一起确定了某项功能,完成了实现并协调了其它模块的功能后,客户又否定了当时确定的功能,我们必须推翻重来;

        我们的某一个同事因为离职而他开发的功能模块别人很难接手;

        当我们使用了某一项新技术,看起来很美丽,却因为某一个没有预料到技术难点不能攻破而导致整个开发的滞后。

等等。问题会越来越多,挑战也越来越大,我们之前做过了很多系统,都必须要去维护,又必须开发新的系统和功能,由于之前的规划或者基础架构的不合理而导致了我们的总体费用中用于新系统开发的费用比例越来越少,意味着我们所能拥有的成本越来越低,能力要求越来越高。

        从自然的因素来看这些问题也许是必然存在的,因为我们的IT架构总是滞少后于我们的商业策略,我们数据模型/应用模型/基础架构又滞后于我们的IT架构。然后我们在期待和抱怨的时候,却没有发现一个固定的商业策略,他们只是一些愿望,期待着产量的提高,管理的成本降低,效率的增加等。意味着IT企业需要一个适应策略变化的IT架构,这里说的IT架构包括了人员/技术/管理/基础架构,也就是说我们需要一个高效的团队。

        谈到如何去建立和优化这样一个基础架构,我们也许会无从着手,迷茫,时常有种感觉就是看到了某篇文章描述了某个概念时眼前一亮伸手却抓不着,其实我们的周围不停的会出现各种设计模式的介绍、各种架构的思想(SOA等)、各种平台(J2EENET)等,也有人经常去探讨哪种架构更好,哪个开发工具更好,其实冷静的思考一下,这些东西很多脱离了一个事务的本质,当我们在大谈大道理、把客户的需求描述得很精彩的时候却忘了IT的本质,我们只是为了客户的愿望和公司的价值去服务,这才是我们的价值本质。

       在很多年前,我们面临的IT环境比现在单纯,那时我们的客户像听话的孩子,很容易被我们引导,开发人员可以单纯的追求成功的算法,而现在却是一个个性张扬的时代,我们客户的需求更加趋于个性化,客户去达到自己愿望的途径和思想指导也越来越多,需求对我们IT服务过程的指导作用越来越低。我们需要更多哲学的思想去指导我们IT基础架构的优化,同时需要探讨出一种价值驱动的思路去指导我们优化的过程。在这里抛砖引玉了。

一、现有基础架构的分析

       包括现有的资源分析、能力分析、差距分析等,进行这些分析就是所谓的知己。

       资源分析:主要包括人员结构、公司的组织结构模型、IT设备资源计算分布(有多少服务器,都在做什么计算,运行什么样的系统等)等。

       能力分析:就是知道我们现在的架构能做什么,能做好什么,跟客户打交道我们有了什么样的能力,售后服务我们有什么样的能力,开发新产品我们有什么样的能力等

       差距分析:我们欠缺什么能力,什么资源,我们要达到一个目的需要培养什么样的资源和能力等

 

二、服务过程的分析

        也就是需要对我们客户的需求进行一些抽象同时为IT企业的经营活动做一些归纳,我们需要分析我们的目标客户群的特征,包括他们的愿望,他们对IT的理解程度、文化背景、IT基础现状等,根据这些特征去归纳我们要对客户或者企业经营的一些活动,如方案、需求分析、设计、开发、实施、维护等。不同的客户特征或经营策略会对应不同的活动,比如某个销售软件产品的公司可以将他们的服务过程归纳为推广、售前、售中、售后等。这就是所谓的知彼。

 

三、优化基础架构

        做到了知己知彼,下面要做的就是怎样通过优化基础架构去提升价值。其实无论什么样的环境和架构,我们只有三个根本的需求就是降低成本、提高能力及安全性。在基础架构中可以分为四个维度:产品/技术/人员/过程。像四跟柱子支撑着我们基础架构,通过这四根柱子去满足这三个基本的需求。这个过程中需要一些活动的支持,包括典型错误的分析、风险管理、技术管理、架构设计、运维管理等。

       典型的错误分析:这是优化一个基础架构的必要,也是一个团队的成长的必要,开发、维护的过程中经常会遇到各种问题,发生各种错误,对这些问题和错误进行分析后,在解决问题的同时也知道了产生错误的原因,才能使后续的效率提高。假如在一个团队产生过的错误到另一个团队中还产生同样的错误,很难提高能力。

       风险管理:这是一个防范于未然的做法,根据我们的预算、产品特性、客户的需求、客户的特征及我们的资源、能力和差距去识别各种风险,然后分析如何去规避或应对这些风险,提升了风险的管理能力意味着提升了企业的经营能力。

       技术管理:是对于IT企业相当重要的一个环节,包括技术的标准化、技术的积累、团队技能的训练等。通过这些技术管理的活动去提高处理错误的能力和风险管理的能力。比如:我们的团队中做同一类型的系统开发和维护中有的用VB、有的用ASP、有点用JSP.NET,这样团队对于开发的软件的后续维护成本大大增加,它降低了资源的利用率;又比如我们在做一个系统的时候,某个子功能,在不同的模块中都有用到,但不同的人都有不同的实现,接口不统一,当子功能对应的业务规则发生变化时,每个地方都要去修改,一旦忘记了某个地方没有修改,大大的消耗了资源。因此我们的技术管理需要标准化、需要项目管理的方法是项目开发过程更加有效和高效、需要一些基本原则、需要一些公共的知识管理、需要一些制度去约束过于个性化的技术、需要一个空间去容纳技术人员对团队技术能力的贡献等等。

       架构设计:对于IT企业增加社会竞争力是非常重要的一个环节,我们的环境使需求对开发的指导效用越来越低,我们客户的机构中市场部和生产部门对我们系统中的一个功能完全会提出不同的需求来,我们必须有适应变化的架构设计去迅速满足客户的需求变化,也就是我们必须去抽象这些需求,对我们的目标客户的某一类系统需求的特征进行抽象,然后进行架构设计,架构设计中关注架构、接口及交互等,比如我们给我们的客户提供的管理类系统实现一个这样的架构,包括表示层、组织结构模型、权限、工作流、消息服务、报表、门户等,这样我们可以快速的去建立能适合各种需求或需求变化的架构。

       运维管理:特别是对提供IT服务的企业相当重要,合理的运维管理方法可以是运行维护的成本变得更加可控的同时,清晰了各种运维活动的成本和能力,并能清晰的知道改如何去改善,比如我们记录我们故障的发生现象、分配并能明确故障处理的责任、积累处理的知识、通过技术减少发现问题和自动维护的人工成本等等。无一不是降低成本和提高能力的做法。

 

四、持续改善基础架构

        一个优化的基础架构不可能一下子做得很好的,我们需要的是一个与能力俱进的优化架构,同时一个机制让我们可以持续改善,循环地去分析我们现有的资源、能力、差距和我们的目标与挑战,要达到这些目标,我们有哪些问题和风险是必须要处理和管理的,我们如何才能达到我们的目标。实际上每一次优化都可能为增加更多的资源,再利用这些资源再去对基础架构进行优化,循序渐进才能越来越好,我们的基础架构最关键的一点就是与能力俱进。盲目去追求一些理想的状况是非常不可取的,就象是一个飞机的发动机装在一个拖拉机上是有害而无利的。我们在买车的时候考虑了外观、性能、安全、舒适的时候却忘了我们不够那么多钱买不起。

             

 

结束语:

        曾经听到一个非常优秀的经理跟我们说过一句话:“口渴了去挑水喝的时候不要忘记架一根水管”,也许我们很多企业经常会碰到一些情况,问题发生过很多次了,还要重复发生、一些概念讲了很多遍了,还在讲,对于问题的本质没有什么改善,几年前到处找水喝,出了问题,到处抓壮丁,补漏洞。到了现在还没有去修好水管,问题越来越多。 也还有一些企业意识到了基础架构的重要性,但不与能力俱进,资源、能力都不能与目标匹配,资源没有分配到适当的地方,最终对经营造成影响。

        IT是一门艺术,是产品/技术/过程/人员的交响曲,少了任何一种音乐,它将不再美丽。在IT领域从事了14年的过程中突然发现了自己能力是越来越不足了,为了能成为这样一个指挥家去演奏一段非常优美的音乐,路还很长,4年前有一些隐约的感觉,于是潜心研究了工作流的技术,也研发了工作流的一个产品,但真正要把事情做好,还需要各个方面的结合。

posted @ 2009-04-08 11:09  赵思伟  阅读(1901)  评论(6编辑  收藏  举报