专家视角看IT与架构
软件产业目前的状态很混乱，开发成本越来越高，质量却越来越差。云计算所给出的承诺和具体实现还有相当大的差距： 最近，在Batler小组的讨论会中举行了一场题为“业务流程管理和面向服务的架构”的座谈，得出的结论认为，只有公有云才是真正能够节省成本的方法，但是它还不够透明，中型和大型企业暂时还无法考虑把它作为节省IT成本的解决方案。当前在行业中有很多这样的宣传性的说法，但是它们能够解决真正的问题吗？ 真正的问题又是什么呢？
对于意识到软件开发生产力缺乏的开发者，以及当前各家公司雇佣的大量技能较差的开发者，业界已经为他们发明了各种各样的方法和工具，这使得业界的大环境中充满了有很多需要学习的零散知识。人们真正想要得到什么呢？ 系统只是一种工具，用来帮助业务完成必须完成的任务吗？ 或者系统不仅仅是工具？ 想要达到软件的“天堂”，我们只需要选择正确的工具和正确的方法吗？ 为什么软件开发看起来这么困难呢？
Bruce Laidlaw和Michael Poulin是两位拥有超过30年经验的IT专家，他们对IT的过去和现在做了比较，做出相关的结论，目的是要确定我们要做些什么才能继续前进。Bruce曾经有过使用行业中几乎所有方法和技术的经历，并在各个级别上参与过，他所参与过的项目从开发费用几千美元到三亿美元的都有，甚至还有初始阶段就耗费了20亿美元的。他的经验涵盖了小家电公司、私营公司、英国政府、美国国家级、省级、地方级的机构，并且涉及到各个行业领域。Michael主要在大型软件开发公司工作，另外还在大西洋两岸的几家主要财政机构的IT部门工作过。他专注于在跨功能和企业的层级上架设业务和和技术之间的桥梁，并为几家全球性的标准制定机构工作。他的行业背景很丰富，包括多年数学算法开发、高级软件设计和测试、分布式计算、面向服务以及开发治理等等。
Bruce和Michael在以下几个方面对他们的经验进行了提炼：
- 软件产业的状态
- 业务需求
- 架构师是业务和技术的粘合剂
- 在IT中我们如何做事
- 架构是保证交付的敏捷工具
他们从各自的角度对这些观点进行了讨论，目的是要明确做我们这行所要知道的知识，以及为了推动IT发展所要做的工作。
软件产业的状态
想要知道如何推动软件产业，我们需要知道它当前的状态，以及曾经的历史。
Bruce
自从有了软件产业，不管使用的方法和工具如何，我们都能够创造出设计良好、构建合理的软件。然而，同时也存在很多编写得很糟糕的软件，即便现在也是一样。不幸的是，从过去到现在，大多数软件系统都可以被归到设计糟糕、编写糟糕的那一类中。并且，我们不得不承认，当前开发的一些软件也可以归为糟糕的那类。
想要得出更客观的观点，我们需要跳出局外，并提出这样的问题： 和30年前相比，企业使用购买或者构建的软件，得到了什么好处吗？ 我认为总体上的回答是没有得到什么好处。以下是我所看到的当前软件产业的特征：
- 高成本： 多年前只会耗费几万元的项目，现在要耗费几百万元。即便以现在的货币价值衡量，之前那些项目的成本也只是现在的一小部分。
- 低质量： 现在的软件质量显然并不比多年前好到哪去，尽管测试和“方法论”方面的“进展”试图改变这种情况。
- 耐久性： 有一种说法认为，软件系统只会持续五到六年，然后就会被替换掉，然而那只是一种神话，大多数企业仍然在使用二、三十年前开发的软件。
- 技术： 在业界有人认为，和30年前相比，技术上已经有了很大进展。如果说的是硬件，那是毋庸置疑的，计算机越来越小、越来越快；然而对于软件来说，肯定不是那样。事实上，我们会看到，在总体上生产力正在下降。一些针对业务的革命性方法让工作可以同时进行，从而减轻了这种情况。但是软件并不是艺术品，只是工具，尽管有些不同的特点，但还是工具。
Michael
在过去的几十年间，软件在各个方面都有了发展： 从核电站的应用到影响了商业的社交化用户论坛。比方说，30年前，我们需要为后花园制定蓝图而编写程序吗？ 我看没人会那么做，也没有什么必要，因为我们不认为那是软件技术的职责所在——园艺这样的工作没那么严肃，不需要考虑在上面使用昂贵的计算机资源。现在，软件无处不在，完成了各种不同的工作，任何单独的例子都无法完整地描述它。
尽管如此，如果我们比较一下就会发现，以对财务行业建模为例，有了软件系统之后，管理成本大大增加，同样还消耗了更多资金。有些人把问题的原因归于架构/设计和对管理结构，我们正是使用这些方法来管理各种各样的软件开发项目的。然而，这些结构中的大多数都应该会提高软件产品的质量。那么，在这样的情况下，为什么我们看到的结果却恰恰相反呢？ 我相信对此会有多种不同的解释，而我也不想自称能够涵盖主要的内容。我只是会指出一些我所能够想到的方面：
- 一般软件项目的规模和复杂度已经超出了软件开发者的平均技能水平。例如，和多年前一样，人们仍然对软件项目持有两种观点： a) 我们需要交付能够工作的东西； b) 我们尽自己最大的努力交付。然而，在很多情况下，“能够工作的东西”和“最大的努力”并不是业务所需要的。IT项目需要更加专业化、为成功而付出的努力，这样，就需要架构设计工作和对业务的分析工作能够更好地弥补需求和技能之间的差距。
- 对简单性提出的建议让解决方案过于简单了，而资源的限制则是主要的驱动因素。任何要做出的进一步改变都会导致原始的、杂乱的、意大利面式的代码，他们把所有一切都耦合在一起，并导致接下来的项目成本居高不下。
- 能够编写程序的软件工程师被批量地生产出来，他们知道如何编写代码，但是缺乏对企业中IT角色的总体概念，另外，对于为什么要编写被要求编写的内容也缺乏理解。
- 和批量生产程序员相关，人们还尝试以制造业或者生产线的方式来管理他们的工作。然而，即便是最简单的编程工作也要比生产线上的操作要复杂得多，但是人们依然故我。这种说法看起来与流行的精益开发和管理方法背道而驰，那是一种在IT领域实行的方法，而起源于日本的制造业。事实上，在软件行业采用精益思想已经改变了最初的精益生产的概念，而且应用这些原则所能够得到的好处还有待验证。
- 软件开发方法之前的目的是要满足各位利益相关者的利益，而现在是要符合企业的需求。在很多情况下，人们会使用敏捷方法来安抚失望的利益相关者，另外，他还让业务人员用愿望来代替业务需求。
- 在某种程度上，先进的代码编写工具也导致了软件质量的下降。好工具值很多钱，如果你不是一个完美主义者，那么你会向CFO演示之前失败的情况，只是为了证明需要花费这笔钱。同时，便宜一些的工具更原始，这让程序员更可能只编写简单的代码。简单的代码不总是正确的代码（尽管正确的代码总是很简单），但是它非常适合交付“可以工作的东西”。也就是说，这样的工具让人们认为低质量的开发是“标准方法”。
- 海外外包也让软件的质量倒退了十年。为了盲目地追求海外外包的“经济效益”，业务和IT的决策者把IT转移到技术文化不成熟、对业务价值和IT在公司中的角色有不同理解（业务环境中文化也不同）的地区。尽管情况慢慢地在改善，但是本地开发者需要对海外团队提交的交付物进行“改进”，这使得外包的成本大大增加。
- “我们会在明天把今天搞砸的部分修复。” 这种退化的项目管理哲学为人们在一些开发方法学中找到理论上的借口，他们坚持只实现给定的需求，而不关心将来的变更。如果业务部门允许自己被这种“低成本”的项目愚弄，那么他们就需要为拥有这样的项目而付出沉重的代价（通常更高）。
理解自己企业中的业务
如果你在任意规模的一家公司的IT部门工作，那么你就需要定期问自己以下两个问题： ““我在做什么？”和“为什么我要做这些工作？” 你的答案可能类似于“我做这些是为了我的薪水，所以我会做能够让公司支付薪水的工作。”，这么说没什么不对，也没有人会质疑你。尽管公司需要热心人，但并非所有人都会是那样。然而，如果你为一位雇主工作，且答案是“我想要创造出最棒的解决方案或者最整洁的代码”，那么我们就需要谈论一下了，因为这种动机通常会产生浪费。理想的方法应该这样： “我想要创造出对业务有意义的代码，并且能够在不重写代码的前提下支持业务增长。“ 如果开发系统的人们不理解业务，也不努力去学习，那么你可能无法实现系统，也可能实现的系统会阻碍业务的发展。
Bruce
谁最了解你的业务？
大多数情况下，最了解业务的总体作用和愿景的是那些高级经理。那种愿景不会经常表现在企业的低级架构中。低级别的人员能够更好地把握业务的过程以及目前业务是如何组织来完成它的愿景，但是他们无法理解为什么过程是那样，或者什么时候应该对其做出改变。和小型企业相比，大型企业中尤其是这样，但是，试图理解业务是一项持久的挑战。
有些方法学首先要让业务分析师了解“当前的系统”，那可能是手工的过程，也可能是自动的，或者是二者混合的形式。诚然，通过了解当前系统，业务分析师能够获得一些关于业务的信息，但是更可能无法获得，他们所能够获得的是你的业务当前的运作方式，那和它应该如何运作可能没有任何联系。一旦我们知道新系统的样子，并且需要对变换做个计划，这种映射当前系统的活动的作用就体现出来了，但是为了达到分析和需求的目的，这还有很多缺陷，并且可能会浪费大量的时间和金钱，并且从开始就可能为项目设定了错误的方向。
谁能担当业务分析师的角色，捕获业务知识呢？ 他们需要接受什么样的培训呢？ 想要有效地完成这项工作，他们需要拥有什么样的技能呢？ 为了把工作做好，他们需要是行业领域的专家吗？
在“过去”的日子里，新的IT从业者会经历一系列的成长步骤，比方说像下面这样：
- 初级程序员
- 程序员
- 高级程序员
- 程序员分析师
- 分析师程序员
- 分析师
- 业务分析师
我们知道，新的从业者可能已经拥有一些技术方面的技能： 某种喜欢的语言或者数据库技术等等，但是在有效地应用这些技能方面，他们的能力还很“初级”。培训中能够让他们提升级别的部分就在于，让他们开始看模式，并了解业务人员是如何工作的。什么是总账？ 什么是库存系统？ 这两个系统如何交互？ 通过这种在指导下的成长，他的计算机技能会得到锻炼，对业务的理解会更敏锐，知识也会不断增长。当一个人达到业务分析师阶段时，他们不仅能够完全理解一般的业务工作，而且能够理解技术和系统如何为这些业务提供支持。
然而，在软件中没有“过去的美好时光”。曾经有很多问题，现在仍然会有同样的问题。并非所有公司都有前瞻力和耐心，能够管理他们的IT员工的成长过程，并且所有正常的人性弱点都会阻碍让正确的人做正确的工作。
然而，当他们那么做时，就会起到非常好的作用。
现在，上面的七个级别只剩下两个了，两个相互没有关联、规则不同的级别，也就是“程序员”和“业务分析师”，各种“程序员”之间已经没有区别，不管拥有一年经验还是二十年经验。对于“业务分析师”也一样，你或者是，或者不是，与经验无关。这样的缺点在于，经常会由一些初级的人员负责控制昂贵项目的产出。
另外还有一个事实，尽管能够胜任的架构师对于组件是必要的，但分析师却并非充分条件。有些人拥有二十年的经验，但看起来却像是只有一年经验。（我认为，在项目最初的阶段中，合格的架构师会起到业务分析师的作用，然而业界已经把“业务分析师”从架构师小组中剔除，也不需要他们拥有做架构师所需要的经验和深度。因此，我宁愿把他们称之为“主管业务分析师”，这里的主管意味着他们本质上也是架构师。）
那么，好的业务分析师或者架构师有哪些特征呢？ 以下是我的观点：
- 他们已经做过很多行业领域的项目
- 他们确实亲自构建和成功地实现了系统
- 他们能够对概念进行思考，能够快速识别一种业务与其他业务之间的相似点和模式。
- 他们都能够快速地学习，并且能够与人清晰地沟通，在很短时间内了解你的业务是什么；可能比你的员工还要好。
- 当你解释业务是什么、需要什么的时候，他们能够很快把握重点。
最后，我要提出一个问题： 谁知道你的业务需求？ 是客户、业务用户或者拥有者，还是应该准确表达系统需求的人？ 他们都经过系统架构师或者分析师的培训吗？ 不。业务用户最擅长描述业务是什么样的，以及想要获得某些信息，他应该做些什么。他们甚至能够表达他们认为一切是如何运转的，但是那只是从建议的角度提出的需求。其实是（也应该是）业务分析师/架构师才能够最好地把针对业务用户的业务需求“系统化”。
当前很多方法学都在这里出了问题，导致很多系统最终失败了。我不止一次听到构建系统的程序员们抱怨，客户没有准确地表述他们的需求。很遗憾，伙计们，客户的工作不是要产出需求，那是你的工作，我的分析师朋友们。分析师必须拥有这样的技能：倾听业务的讲述，然后从那些谈话中挖掘真正的需求。在没有真正分析，而且信任关系是通过管理手段构建的情况下，如果分析师说他“明白”的时候，业务人员就会强迫分析师接受自己的看法。不幸的是，这样做的风险非常大。他们能够得到所要求的，但是并不是所需要的。
Michael
多年以来，IT始终没有确定或者说是在忽略业务的角色。IT人创建了一种信念，他们更知道应该为业务做什么和怎么做。即便是在集中的IT中，开发者也只把眼光放在眼前的项目上，比方说，他们的同事做了什么，而一些软件开发方法把关注点只放在交付某些功能。当业务和技术之间的桥梁几近崩塌，IT就会开始谈论灵活性，说业务对问题一点都不理解。
我是经过了过去十年间参与面向服务的解决方案的工作，才发现了这个问题。我看到，尽管我告诉很多公司SOA具有强大的交付灵活性，但是他们还是在刚刚起步就失败了。我知道他们之所以失败，其中主要的原因不仅仅是IT对SOA产生了误解，而且在于IT在提供以服务为中心的解决方案时，试图让业务以过程为中心。换句话说，IT对业务如何运转做出响应，而不是对业务应该如何运转做出响应。
在很多行业中，IT已经从工具开发者的角色转换为解决方案开发者，那其中会包含业务解决方案的开发。然而，为了产出正确的解决方案，IT需要知道正确的业务任务或者业务需求。当处理主要由低级别的运营业务团队提出的问题时，IT会锁定这个级别业务人员的问题（大多数情况是那样），然而，这个级别的人员反应的都是过去的业务需求。事实上，低级别的运营业务过程只不过是对功能的业务实现，并且，随着时间的推移，这些过程会与当前的需求以及公司的目标脱节。
想要达到业务敏捷，IT需要知道业务的发展方向，还要知道业务计划在将来如何发展，然后再相应地对软件开发做出调整。在IT中对业务变更做出调整会比在业务中花费更长的时间，因为在代码中存在很多隐藏和缺少文档描述的依赖关系，并且还有在不关联的应用程序之间共享的重要程序库，一项变更可能会产生很广泛的影响，这样，在业务用户可以重新使用之前，都必须对程序进行重新平衡，让它变得足够稳定才行。这意味着IT需要比中层和底层业务运营单位更了解业务所期望的改变。过去十年中的经济动荡使得IT无法培养出理解业务的软件专家。这意味着IT再也无法依赖于在技术团队中所能够正常学习到的业务知识；IT需要有一些专注的人员，他们不得不与业务一起工作。这些人员兼任了架构师和业务/系统分析师的角色。
所以，IT架构师和业务/系统分析师需要和中层到高层的业务人员紧密合作，以了解他们的意图和方向，一方面要为现存的业务提供指引，另一方面要提供新的技术能力。这项工作无法在一个项目接一个项目的情况下完成；它或者要作为完整工作职责的部分完成，或者是在全局项目的范围内完成。也就是说，IT需要跨当前和将来的项目，拥有一个由架构师和业务/系统分析师组成的组织。在外包或者经常有临时工的情况下，架构师和业务/系统分析师才是企业中最重要的IT财富，而不是经理。如果你让IT中的业务知识减少了，那么就是对IT的大脑做了损害。那样的话，你需要和没有大脑的IT一起工作了……
遵循这种逻辑，让我再向业务更进一步。显然，中层和高层的业务人员没有时间（或者没有意愿）帮助IT解决问题。理解这样的事实，会让我们做出把业务架构师的机构和业务合并的决定。业务分析师实际上会负责对实现战术上和战略上的业务任务进行管理，业务架构师会和他们一起处理最高级别的业务计划，识别业务需求，构建业务架构，并为了实现业务任务对其进行描述。业务架构师还会与IT管理者和技术架构师交互。这意味着业务部门中的业务架构师和业务分析师会负责构思核心业务需求。最终，这些需求会在业务单位和IT之间切分。
根据我的经验，以及我的同事们的实践，我知道在某些情况下，业务需求是从不同的低级业务过程的主观需求中提取出来的，并且陷于其中无法自拔，最终这些业务需求会耗费掉IT所有的资源。我认为对于这种问题只有一种缓和的解决方案，所有想要传递给IT的业务需求需要经过某种形式的业务验证，根据业务策略和部门的计划来检验，并且进行验证的人员应该是业务部门中的业务架构师和业务分析师。我见证了这种方法，它很有效，当IT推动了对业务需求的业务验证，他们也会得到越来越多的尊重。
现代企业中架构师的角色
在过去的几年间，人们普遍认为，在争论之前要在语义上达成统一。因此，对于这个讨论，我们都认为架构（软件、业务、技术、硬件等）都是依据IEEE 1471标准定义（而不是描述）的。我们只能向IEEE 1471标准中添加组成架构的元素
- 它们必须是基本的、能够自给自足且连贯的
- 它们能够不依赖其他元素存在（例如，不能是从其他元素衍生的）
- 它们应该提供架构元素视图（从内向外），而不是由视图来提供架构元素（由外向内）。
我需要对最后一句话加以解释。不管是谁在看，也不管是从哪里看（查看的角度如何），事物的所有视图都会有误解的风险，无法真实反映该事物，因为 1)它是主观的 2) 它不知道事物的边界，也无法把环境的一部分作为事物的一部分来考虑。相反，对事物的视图是基于实际的知识获得，那些知识是与所有外部利益相关者的兴趣相关，并且会考虑如何才能够生成持久的视图。
尽管架构的概念相对清晰，但我们还是无法认为架构师的角色也同样清晰。在业界中还没有一种标准来定义架构师的特征，两种主要阵营之间的意见截然不同。一种认为架构师是超级技工，他能够熟练地掌握一些或者所有最新的技术。这样的架构师被称为.Net架构师或者JEE架构师，等等。
另一个阵营认为，架构师的技术性要差一些，他应该更关心“系统科学”和方法，那与自动化本身没有任何关联。这场讨论的结果认为架构师应该是后者的样子，但是因为有多年的技术经验，他也应该是很不错的技术专家。我们在上面提到“技术性稍差”，意味着架构师是知道为什么（why），何处（where）和何时（when）的人，例如，需要在解决方案中使用消息机制；从架构角度来说，不管是厂商开发的消息机制还是自己开发的消息机制，都不重要（尽管从实现和管理的角度，那是非常重要的）。这种架构师不会是前卫的技术专家，但是他能够胜任沟通业务和技术两伙人的工作。在这种情况下，超级技工指的是软件工程师或者技术主管，而不是架构师。
Bruce
现在各种职位的称谓已经被滥用了，所以我在犹豫是否可以说最好的业务分析师就是系统架构师，但是如果那些人是通过经验和技能获得他们的技艺，那么架构师通常是拥有经验和洞察力的人。在那种情况下，业务分析师的角色是由架构师担任的，那比创建架构的优先级高。在两种情况下，负责业务分析工作的人都应该符合已经列出的条件。
当业务需求已经表述清楚时，业务团队中所有阅读需求的人都应该对其很清楚，而且那就是所要求的内容。需求不会说明如何设计，尽管需求能够强调设计中的一些方向以供考虑。例如： 如果管理的愿景是为客户提供自我服务的门户，那么需求这样描述就很合适了。然而，指定用户号是20位数字和字符，其中带有分隔符，这就不是一个业务需求，这只是某人的主意，从而可以更好地追踪客户，最好能够根据经验来设置这些内容。
如果一家企业的IT部门能够理解一致战略的的需求，从而符合业务的需求，那么它就会投资创建包含有业务活动模型和业务信息模型的业务架构。这些模型与自动操作无关，而是会根据业务需要做什么、业务需要什么样的信息来捕获业务的本质。如果存在这些模型，那么所有系统项目就有了坚定地基础，并在总体的战略中拥有属于自己的位置。
如果没有这种战略，也没有这些模型，那么系统项目就不得不在时间和预算允许的范围内做最大的努力。如果员工能够了解企业的愿景，那么这种方法会生效，使得企业业务架构会慢慢增长。不幸的是，这种情况很少发生。这种情况下所能够期望达到的最好结果就是，对系统和标准来说冗余的部分之间不会有太多冲突，或者需要设置昂贵的数据整合过程来修补数据和过程之间的脱节。
总之，只有当合格的业务分析师和架构师能够与企业中理解业务的远景和方向的人紧密合作，才能够透彻地理解业务需求。通过这种合作，我们会得到连贯且有用的需求文档，它会为你的业务服务，不仅仅是为当前的系统项目，也会对将来所计划的业务需求起到作用。
Michael
近来对架构师的地位和角色的讨论逐渐升温。一些企业中的经理还是无法接受，在项目中架构师的地位要比业务分析师高。同时，企业架构机构和相关的架构师越来越多地占领了传统的业务领域。
技术架构师已经把结构合理性和规范的逻辑引入到业务操作中，它是构建在个性化很强的人与人的交互和关系上的。这可能对于某些业务活动很好，但并非对于所有都是那样。自动化和形式化的机械应用程序对有形的价值链方法学肯定有效，但人不是机器。忽略了价值网络中无形的、面向交互的价值，使得业务和技术更难以实现革新，从而革新会更慢，成本会更高。
然而，与业务架构师紧密合作，不仅对IT架构师有利，而且对企业本身也有利。这样的合作在业务和IT的边界上生产力并不高，因此需要新的组织形式。业务和技术企业架构都有责任保护整个企业，那意味着唯一符合该任务的组织形式就是跨功能、跨部门的团队，其中业务和技术企业架构师能够协同工作。和单独的业务和IT部门以及海外企业级别的项目中的权威相比，这种团队的权威与之同级或者更高一些。
企业架构位于组织中架构功能层级机构的顶端，该结构中会依次把所有单位和部门（业务和技术部门）都包含到每个开发项目中。依照协作的业务战略计划，架构师会定义在组织的各个层级所需要完成的任务。然后，公司的管理层会负责如何根据自身的情况来实现架构上的决定和解决方案。这意味着，当项目经理设定项目的时候，相关的架构师会确认他们合适地设置了并解释了项目的目标和方法。
技术、业务和系统分析师都会完成自己与业务相关的工作，这是通过找到需求细节和依赖关系，并编写相关文档来完成的。技术、业务和系统分析师并不是“拥有企业洞察力的员工”，而只是专注于特定的项目需求。其他项目所做的工作，以及它们（在实现上）是否重叠通常不在他们的考虑范围之内。这样，他们经常会依赖于业务需求，那只是由技术、业务和系统分析师搜集获得；IT有很大的风险，可能会转向错误的方向，因为他们很容易就会忽略重要的依赖关系。不幸的是，我们看到这种情况经常会发生。
我坚信所有业务想法、建议、明确表述的需求和任务都是需要IT来实现的，而支持和集成工作在引入到IT之前，需要业务对其进行检验和验证。业务架构师和业务部门中的业务分析师需要共同组成一个管道，对进入到技术部门的需求进行控制。技术架构师会把业务需求转换为架构解决方案，并把它们传递给技术、业务和系统分析师来丰富细节。
因此，这个管道会以如下的方式运作：
- 业务请求者对业务需求进行表述
- 业务架构师和分析师审核需求，看它是否符合策略性业务计划和公司的目标。
- 业务架构师和分析师会分析实现这个需求对周围的业务执行环境的影响和反作用。
- 如果所有人都批准，那么需求会被传递给IT架构师，他会根据需求来考虑IT的能力，并向业务反馈解决方案的概要。
- 如果IT解决方案在某种程度上影响了业务需求（例如，做了某种程度上的优化），那么就会通过迭代的过程达到最终的意见。
- 大家达成共识的需求会被明确表述为核心业务需求，并传递给IT部门。
- IT架构师和系统分析师会分析其中的细节，并产生出业务和技术上的需求，以便在IT部门中进行细节的设计和实现。
这是一种普遍的业务需求构建过程，可以应用在所有行业和企业中。这个过程非常适合业务和IT的治理，以及相关的质量控制。我认为，在所有营销高峰中，实现得不合适的IT产品会造成很大的利益损失，这凸显出用来定义真正的业务需求所付出的努力和时间是值得的。
构建“好”/“坏”系统的过程
Bruce
假设我们已经找到了合适的人，上述的需求也已经获取完毕，我们就能够保证拥有更好的系统吗？ 有可能会，也可能不会。
如果已经获取了良好的需求，那么和没有获取良好的需求的情况相比，我们更有机会创造出好系统，所以从那个角度来看，情况要好一些。但是，还是有很大的可能会失败。
Dr. Paul Dorsey的一份报告强调了保证项目成功最主要的三种要素：
- 高级管理层的支持
- 合理可靠的方法
- 由已经成功完成类似项目的人所领导的技术
很有趣的是，这与“过程”是什么样的无关——换句话说，开发的风格并不是问题。那么这种管理承诺的失败在何处明显体现了呢？
看起来，当项目开始的时候，管理层通常会缺乏分析的耐心。现在有种流行词叫做“分析麻痹症”，并且经常会为了得到“产出结果”而牺牲分析的时间，似乎设计根本就是在浪费时间。我曾经和技术能力很强的团队一起工作，他们最终没能成功交付项目，只是因为管理层没有让他们做该做的工作。不幸的是，IT业界让初级的员工来做超出他们经验的工作，从而造成了这种形势。作为响应，很多方法认为规避问题的方法就只是不做分析。问题就解决了！ 可能是吧。
在讨论的最初阶段，有人声明，不管是在成功还是失败的项目中，使用的方法都不是决定性因素。如果坚持这种看法，那么 极限编程、敏捷、Rational统一过程等方法本身都不会让事情走上正轨。这些方法所做的就是，试图调节被破坏的过程，在坏形势下获得最好的结果： 并且，这些方法的确使得情况有了一定程度的改善。不幸的是，如果通过合格的设计沟通出业务需求，开发者又能开发出什么呢？ 这些方法把业务人员放在开发者中间，期望随着他们一起工作来构建系统，需求就会逐渐显现出来。如果业务人员非常了解企业和它的愿景，那么这会很有效，但如果不是那样的话，就不那么有效了。人们必须了解总体上系统会变成什么样子。那并不是说要在做任何工作之前把整个愿景描述清楚，愿景可以慢慢改进，只要负责愿景的人（架构师）能够胜任这项工作，并且知道他的设计是要做什么。
问题是，什么因素让系统对业务来说“好”或者“坏”呢？ 谁来判断好坏，这是一种黑白分明的判断吗？
事实上，不管一个系统的构想有多糟糕，至少都会完成一部分它想要做的事情。和最初就计划好目标相比，这可能需要更多的资金和时间，但是大多数系统都以某种方式达到了目的。不幸的是，构想很差的系统无法确保业务能够增长，也无法随着时间的推移满足业务的需求。
在此，我把“好”系统定义为能够满足业务需求的系统，它让业务能够随着时间的变化灵活地改变，并且用户会认为系统能够很好地支持业务。
相反，我对“坏”系统的定义是在某种程度上完成某些或者所有业务需求的系统，但是完成的方式会阻碍业务在将来的改变和发展。
Michael
我对“好的”技术系统的解释与运行环境（业务和技术）紧密相关。我发现，在繁荣的时期，在外部业务环境中发生的业务变化要比萧条的时期少。据此我们可以认为，业务会为相同的技术系统设置不同的期望和需求。例如，在90年代末，在美国，系统的可伸缩性和性能是主要目标；而现在，优先级最高的是系统的灵活性/可扩展性和安全性。
现在业务的灵活性需要技术解决方案足够灵活，我们只需要对系统变更做最小的投资，对周围系统调整作最小的投资，就能够适应业务的变化，并且所有工作都应该在最短的时间内完成（这就是我所定义的系统灵活性）。这与过去“实用的”实践形成了鲜明的对比，那种实践宣扬给定的需求必须明确地发布，不要给修改和替换留余地，好像将来不会有任何变更。
在IT部门实现业务需求的正常流程经常会被破坏，而那并不一定是IT的过错。IT创建并且继承了很多旧的遗留系统，其中有大量不定和“意大利面式”代码。如果业务想要快速推进，那么就需要修复IT资产，使得它们更灵活。这项工作需要大量时间和资金，但这两样往往都很缺乏。云计算和外包对此不会有什么帮助，因为IT中旧的遗留系统中有很多公司财富——知识、逻辑和数据，并不适合外包。
引用Forrester研究公司的话，我们可以说“你的业务只能和你的技术以同样的速度变化”。因此，“好”系统就是灵活的系统，当前很有用，并且考虑到了将来的扩展性。在“敏捷说法”中，“好”系统会满足每天活动的业务需求，并且根据业务策略计划平滑地转换。
IT发明了一种又一种敏捷方法，目的就是为了构建出好的系统。敏捷方法的主要部分都是基于这样的假设：业务不能也不会以与今天不同的方式工作；这些方法不敢挑战业务的工作方式，即便这种方式对于企业来说会降低生产力。这会导致这样的趋势：敏捷开发者主张简单的设计，其中很少涉及未来的架构和设计，或者根本不涉及。 实际上，开发团队负责依据业务需求交付软件，而软件的业务价值与团队是无关的： “如果业务想要这种方式，那么他们应该知道那是什么，也知道为什么要那么做。”
我们经常会遇到这样的情况，敏捷团队承诺稍后会添加错误处理机制、调整、通知/警告、补偿逻辑、事务完整性、安全性以及操作稳定性等等，并把它们放在接下来的“时间表”中。然而，所有这些技术功能都是IT所关心的；它们是业务部门期望从技术部门立刻得到的服务质量（QoS）特性，而不是要拖延到下次。业务逻辑很简单： “如果软件已经有效地运行，（哦，真的吗？）为什么要等待更长时间才能得到最终的发布版本，并投入更多资金呢？ 相反，既然IT已经做得很好了，那么让他们做其他任务吧。”
让我们回到精益方法学，在此重新回顾一下大野耐一所描述的真正的精益生产原则，这非常重要：
- 只构建我们需要的
- 如果出问题了就停下来
- 去除所有不产生价值的工作
不可否认，这些原则都非常合理，可以很容易地在生产环境中对其加以解释，在那种环境中我们可以完整地定义和指定最终的结果。然而，当Mary Poppendieck和Tom Poppendieck描述精益项目管理方法的七项原则时，他们在很多地方已经脱离了精益生产的本意。
比方说，让我们来看一下精益方法在面向服务的情况下如何起作用，在其中精益团队会构建一项SOA服务。因为人们集中关注于精益原则“消除浪费”，因此那成为团队的首要任务。顺便说一下，消除软件开发中的浪费是一项非常有挑战的任务，要比生产行业中难得多，因为在所有的业务需求中都会有很多不确定的因素，而架构的愿景无法在其中反映出来。那么，如果我们讨厌并且忽略了将来的架构设计，我们如何才能判断出什么是浪费，什么不是浪费呢？
在SOA中，所有服务都可能被用户使用到，而最初请求服务的人（构建服务也是基于他的需求）可能很快就会被大家忘掉。SOA服务必须为未知的用户（或者使用精益术语，客户）服务。每个客户都能够在服务中找到属于自己的价值，而这个价值与开发团队所要达到的目标可能会截然不同。这是说生产行业中定义的浪费无法适用于面向服务的开发吗？ 或者说，没有健壮的架构设计，它可能无法适用于所有软件开发中……
另一项精益原则——“延迟交付”，这在概念上与“消除浪费”是相互矛盾的。我们可能会延迟交付。比方说，延迟完成对产品的实现，因为我们认为我们的任务中某些业务会发生变化。如果我们认为会发生变化，但是又不知道会发生什么样的变化，那么如何才能够识别出浪费呢？对于即将发生的变更来说，一项工作可能是浪费，而另一项可能会是非常有用的特性。我想那就是面向服务的规则——“为变更而设计”——那会比延迟交付更有效。
还有两项原则：“内建质量”和“整体优化”，这可能与“为团队授权”原则矛盾。我们认为精益团队应该专注于特定的任务，那样就很难发现“整体”。并且，创建于IT中其它不在项目范围内元素的完整性就更难了。这两项原则都应该属于跨团队的架构职能，而不是属于开发团队；应该是有了架构之后才能够定义浪费。
最后，我觉得“为团队授权”这条原则很有意思（而不是为管理层授权），它被添加到IT精益方法中，而最根本的原则“如果出问题就停止”却被排除在外。这意味着在开发中只有“大晴天”，所有的执行情况都是可以预料的吗？ 没有停止原则，为团队授权之后，精益项目经理就缺少后退的机制。也就是说，他们会持续交付所有可以提供的内容，包括浪费。这样，结论只能是以下两种之一： 或者IT精益方法的基础还不成熟，或者说它又是一种错误的方法。
我们能做得更好吗？
Bruce
在本次讨论中我们说的是：
- 方法不是成功的决定因素
- 业务需要一种业务架构
- 业务应该指定需求，架构师/分析师应该指定需求的系统化实现。
- 管理层需要选定一种方法并为其提供持续的支持
- 我们可以根据系统支持业务的能力来评定它的好坏
我们怎样才能达到这样的目标呢？ IT业界历史上残酷的现实是，你不可能总是可以找到最好的人，所以需要让缺少经验和能力的人来完成工作。我们还有希望实现产出好系统的梦想吗？ 我相信有。
如果有清晰表述的良好业务架构，那么对于获取需求就有了坚实的基础。如果有构建在那种业务架构上的坚实的应用程序架构，那么项目的规范就能够以可控和渐进的方式完成。
如果创建了合理的架构实践和指南，并且明确表述了高级管理层支持的企业愿景，那么其他的事情就会落到实处，并且不会过分依赖于项目团队的经验和技能，这只是因为已经定义了坚实的框架，他们可以在其中工作。这并非是完美的方法，但这是我们所面对的现实情况。
我们可以提供这些“可能的”部分，而不需要花费多年时间吗？
如果我们能够找到正确的人来为业务建模，那么他就会很快把模型建立起来。不管是什么样的业务部门（政府、制造业、军队等等），由两位建模人员组成的团队共同协作，就能够很快地捕获到活动和信息的模型。在中型和大型企业的环境中，六个月的项目就应该足以满足需求。
根据高级管理层的愿景和方向的不同，对应用程序架构的调查可能还需要两到三个月。所需要的时间期限是主观的，并且严重依赖于组织的文化以及企业忙于处理遗留应用程序的程度。
意识到上述讨论的问题，可以让我们获得更好的、更具有持续性的开发项目。另外，还有一种好处就是可以把业务从多年来实现得很差、冗余的系统中解放出来。
上述的应用程序架构包含了所有当前在企业中使用的应用程序，还有这些应用程序如何帮助或者阻碍业务的真实需求的评估。当检查这些系统时，如果能够更关注于业务需求，那么我们就有更大的机会基于功能和数据对其进行整合。减少应用程序的数量，不仅能够降低运营成本，而且通过提供更可靠和及时的数据，会为企业带来更大的好处，并且开发环境的响应更及时，从而满足业务变更所带来的挑战。
Michael
我关于这个问题的回答是“是的，IT能做得更好，但是光凭IT自身不行”。IT需要在以下方面把业务部门涉及进来：
- 做所有与技术解决方案相关的决定
- 根据业务策略检查自身的能力
- 合并开发和运维的费用
- 评价生产出来的技术系统
这样的动作能够让业务对他们的需求和选择负责。
当技术架构师提出一些可选的要实现解决方案的建议时，客户和利益相关者需要知道，如果他们选择了费用最低但是没有考虑到将来的解决方案，那么他们就需要对这个决定负责，而不是由IT来负责。我已经看到过很多这样的情况，在开发时费用最低的解决方案，在维护时会耗费大量的金钱。我们应该如何来平衡呢？ 很容易，业务和IT需要把成本作为选择技术解决方案的目标。而不能由某个部门单独来决定项目或者开发成本的目标。
当IT检查技术能力的时候，经常会发现平台陈旧，如果不报废的话，可能再也得不到厂商的支持。这样的平台能够对业务策略目标和目的起到应有的作用吗？ 答案是，很可能不会。那么，IT需要公开说明，现在的系统已经无法支持策略性的业务需求，我们可以说明一下，拥有现存的解决方案需要付出大量的维护成本，那已经占据了IT预算的主要部分，而没给策略性开发留下多少。
当开发出新的解决方案、产品或者系统时，它需要经过将来使用它的业务用户的审查。传统的用户接受测试只会检查业务功能。与之相比，业务审查需要检查IT产品在所有异常或者非标准的业务情况下的响应，比方说，可伸缩性需要在真实的环境中演示，而不是在专门的测试系统中。如果系统通过了审查，它会存活得很好；如果没有，可能就要对一些业务需求进行修订。在任意情况下，IT都需要和业务部门一起重新设置业务的期望，并以合作和积极的方式来确定改进的方向，而不是忙于正式环境中的报告和缺陷。
IT能够如何更多地让业务参与进来呢？ 可能我并不是最早这么说的： a) 支持和改进业务中业务架构师所提出的想法， b) 支持和改进跨业务和技术的企业架构、由业务和技术架构师共同制定的想法，c) 设置定期的会议，可以让在相同业务领域中工作的业务和技术团队的业务架构师来交换意见，d) 在IT部门中创建总监级别的结构，它会直接与业务管理层协同工作，作为了解所有想要让IT做的业务需求的管道，e) 创建跨项目的分析小组，他的责任是要分析低级和中级的业务运营过程，并基于技术能力得出优化建议，也就是让IT更积极。
我发现，在技术治理中还有一种IT可以改进的方面。我实际上指的是，技术治理包括所有架构、开发、数据/信息和管理的治理领域。这种治理不仅仅是关于什么是什么，而且还涉及到在开发和测试中所能够使用的技术。这种治理涉及到的方面包括对开发在架构上和设计上的控制，开发和测试的工具和方法论，项目管理方法，以及现存和“正在开发”的系统、产品和解决方案之间的协作。治理手段需要覆盖IT在端到端业务开发所涉及的内容，确定解决方案所有权的目的，以及在IT和业务之间的SLA中所定义的责任。治理无法用管理来替代。治理要说的是，当管理层要执行治理策略时，应该做什么事情，以及事情应该怎样做。如果治理策略是由IT管理层来维护的，那么让具有独特权力的治理人员来指导IT整体上的功能，就有可能获得针对业务合理的灵活性。
查看英文原文：IT And Architecture: Inside-Out Perspectives