菲利普.玛格尼的博客：洞悉

各位，你们好！我是菲利普·玛格尼，ARCAD软件开发有限公司的CEO。ARCAD软件开发有限公司是专注于ALM（应用生命周期管理）行业的独立软件开发商。我今年50岁，我感觉到有一种不可抗拒的需要，想与你们一起分享我在ALM市场27年来丰富的专业化经验。我认为我能很好地预测趋势，也很想获悉你们每一个人所遇到的独特的情况，我更高兴与你们更多地分享这些经验。

我有着极好的机会到世界各地旅游，并与不同文化背景的人见面和分享信息。我热爱这种文化多样性。看到来自不同地方和文化的人们在一起有效地工作是我感到最为欣慰的一件事。或许因为我是法国人，而且...... 不像其他许多法国人一样，我为此而感到骄傲。

                                                                                                                                                                                    菲利普·玛格尼
 

  

   是进化，不是革命

   2015年3月，亚洲
   
   

从亚洲不同的国家旅行回来之后，我清楚地看到IBM的市场情况和欧洲及北美有很大的不同。当然日本除外，因为它和欧洲及北美两大区域显然有很多相似的地方。一个主要而且显而易见的区别就是亚洲的生态系统远远没有得到开发。没有本地的用户群体，也很少有活跃的独立软件开发商和营销事件。因此，很多公司除了远离平台之外，别无选择。

但是，与此同时，我在新加坡会见了一位 IT经理，他告诉我：“每一样东西都很完美，我为什么要做出改变？”。的确，任何人都想知道，为什么他们要冒着风险改变某些能正常工作的东西。答案是 -- 就我看来 -- 最好能进行一套小而常规的变革，而不是一场革命。 由于世界本身变革得如此之快，因此，一套系统如果不能变革，将迟早导致一场革命。

革命不一定都是坏事。有些时候，当有太多阻碍顺利转变的障碍时，它可能是唯一的途径。但是，有一件事是确定的，它一定也是一条最冒险的途径。对于革命，我们能够知道它何时发生，但是没人能够预料它将何时停止。

这把我们带入一个可怕的矛盾之中：有些公司因为害怕打破某些现在能正常工作的东西（顺便说下，它们也属于关键业务的东西），就不想对他们的系统进行“现代化”。然而，与此同时，他们也会毫不犹豫地创造一场革命：升级到一个全新的系统，改变硬件，软件和他们公司的整个组织。这难道不自相矛盾吗？

所以，为什么不进行“现代化”呢？它看起来是风险更小（代价也更小）的一个选择。答案总是相同的：人们总是不相信它是切实可行的。幸运的是，对于我们居住的房子，我们不会有相同类型的反应。如果真是这样的话，我留给你们去想象我们的情况会怎么样……当然，“现代化”是切实可行的。它只是不会在同一时间做所有的事情，而是有着正确的工具和方法论。

它毫无疑问是这样一个地方：在这里，各个公司之间很不平等。穿越整个世界，我们看到同样的一幅场景：那些对他们的系统进行了“现代化”的公司，都是那些有着才华横溢和激情奔放的技术人员的公司。这里，我没有谈论那些为了他们自己的荣誉和骄傲而做着聪明事情的那一类人，我是在谈论这样的一类人：它们很好奇，也很务实，它们能够判断一项技术是否已经成熟，而且能够对这种技术进行测试，以确定它是否符合公司自己的需要，并且能够将这些知识在公司内扩散和传播。不幸的是，这些人在整个地球上都凤毛鳞角。

所以，我们的使命就是维护一个有利的生态系统，这里面有几个积极的行动，包括：iManifest，RPG （报表程序生成器）语言，AS 400专家。所以，现在是和年轻一代对话的时间了。在下一篇文章中，我将让你们知道我是如何进行的……

   IBM i 趋势：管理应用参数

    一种强烈的趋势正在形成， 并将持续下去。越来越多的标准软件包（通常是云里面的）正在被企业采纳到它们的信息系统中。今天这个时期的主要技术变化促进了这种趋势的形成。然而，如果你们考虑软件包的话，那你们也必须考虑参数—或配置数据—而且是各种各样的。的确，区分软件包供应商的是他们所支持的定制化服务程度，允许最好的供应商进一步开拓市场。但是，这种定制化服务对客户来说有一种不可忽略的成本。这一点不仅在实施阶段是显而易见的，而且在生命周期的后部分也是如此。因为客户必须持续地调节他们的参数, 使之适用软件包升级，以及他们自己组织变化的需要。过去，对于内部开发，公司要求开发人员进行必要的升级；而现在，参数变更是由项目拥有者完成的。这意味着，变更管理由管理源代码阶段自然进化到管理参数阶段。       
    这些关键性的适应过程不仅包含成本，而且，它们必须在高度安全的条件下才能完成。一个简单的参数错误可能给公司数据带来致命性的后果。所以，公司为了防范这种风险，被强制要求巩固和加强变更管理模型。
    这种严格的组织机构需要的技术实际上等同于维护代码。刚开始时，他们创建独立的测试环境；然后，用户对新的变化进行广泛的测试，以保证结果是符合要求的。从生产环境中拷贝过来的部分或全部数据是非常有用的，它们可以尽可能地创造真实和准确反应现存参数的条件。在这个阶段，应该就下面几个问题提出疑问：

• 在持续部署到不断增多的不同环境时，怎样使磁盘空间需求更小？

• 怎样定期刷新测试数据？

• 怎样保证这个产品数据的保密性？

令人欣慰的是，所有这些问题的答案现在都能通过工具和内部过程找到。
    当需要验证这些变更时，问题出现了：这些变更怎样才能转换到生产环境中？最理想的情况是，我们可以依赖软件包中任何现有的导入（import）或导出(export)函数，也可以开发特定的程序来尝试进行自动化处理。但是在大多数情况下，这种转换都是通过手工重新录入数据实现的。由于人在执行重复任务中的可靠性大致是1/100，因此很容易看出自动化这个过程有多重要 ??—这是既保证生产效率又保证安全的唯一方式。
    对测试活动进行自动化是同一个过程的固有部分。测试程度依赖于可接受的可靠性程度。测试是代价昂贵的活动，它构成对变更进行反应的一个阻塞点。市场上有很多工具，在这个领域提供具体的解决方案。惠普收购市场领导者美科利（Mercury Interactive）表明这种工具对许多公司来说具有高度的战略意义。诚然，当我们看到市场上有一定程度的自动化产品可卖（特别关于测试场景的工具），我们都情不自禁地想购买这些产品。但是它们真的有效吗？这里，成功使用这种类型的产品在很大程度上依赖于你们底层的变更管理过程的健壮性。 
    首先，实施严格的变更管理过程是一件合情合理而且实用的事情。然而，我们必须认识到，这条途径不一定是我们今天文化的一部分。我们的文化倾向于拒绝那些许多人认为是太过于严苛的东西。但是，我们越来越全球化的世界在安全性和可靠性方面有更多的要求，所以我们必须适应这种变化。最终的结果是，多点严格和条理不会伤害任何人。
    一个组织是基于方法论和合适的工具而存在的—这种工具完全适应于你们的技术环境，而且被你们团队的大多数人所完全接受。我使用“大多数”一词，是因为在基于工具的途径中要尽量取得一致性有些过度乐观。 你们能够肯定的是，在你们组织的某个地方，潜伏着一个无可救药的顽固份子，他将以或多或少坚实的论据来对抗这条途径。这就是人的本性。
    这些组织的变化是激动人心的。他们呼唤用技术和人为的要素来实现目标。当然，在前进的道路上有绊脚石，但是这条道路将引导我们笔直地通往未来：一个最大自动化世纪的未来。

                                                                                                    原文出自：http://arcadsoftware.com/category/philippe-magnes-blog-insight/

   

       

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30201869/viewspace-1563917/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30201869/viewspace-1563917/