论文部分内容阅读
编译 杨勇
业务部门经常独自开发移动应用程序，只有在出现问题时才转而求助IT部门。围绕业务部门及其移动应用程序需求更好地进行治理可以帮助缓解最糟糕的“痛点”。
当独立蓝十字公司在2012年发布第一个移动应用程序时，它同时也迎合了当时的技术趋势，影子IT从此长存下来。
这是因为该应用程序来自公司的市场部门——没有IT部门的任何参与。
和大多数影子IT项目一样，营销和IT部门来回推诿这一应用程序带来的问题。
当应用程序首次亮相时，位于费城的非营利健康保险公司的企业架构总监Ken Russo说，患者使用这一应用程序，以移动的方式访问独立蓝十字公司的会员网站，这实现了营销的目标，即在移动领域获得一席之地，但是从一开始就存在问题。
该应用程序是由营销部门雇用外部机构开发的，它依靠屏幕抓取技术与网站连接。所以每次公司门户网站出现变化（实际经常会变化），这一应用程序就没法用了。营销部门首先会去找供应商解决问题，然后才找IT部门寻求帮助。
Russo说：“解决方案非常脆弱。它需要供应商不停地进行维护，成本高得难以接受。此外，在一个平台上解决了的问题在其他平台上不一定能解决。我们需要更好的方法。”
有了这种经历后，公司领导决定采用更好的方法。Russo被授予新的角色和职位——消费者和移动解决方案交付总监，负责制定移动应用的技术战略。他决定采用一种流程，包括使用Kony移动应用程序开发平台，使应用程序能够按照业务部门的要求尽快完成。
企业着急在移动领域占有一席之地，导致业务部门自己开发和部署应用程序，这意味着IT部门正面临一个全新的影子IT时代。事实上，研究公司Gartner预测，到2020年，企业内部使用的70%的移动应用程序是在没有IT部门参与情况下开发或采用的。
事实上，这么多移动应用程序的开发与IT部门无关，对于一个不停地处理关键任务而过度劳累的技术部门而言，这似乎是好事。但这种情况还是让技术部门面临更头疼的问题。事实上，外部开发可能导致大量的问题落在IT部门身上——就像Russo所经历的那样。
差劲的移动应用程序带来的问题不止是浪费IT部门的时间。分析师说，如果没有正确的配置和集成，这样的应用程序可能会带来基础设施安全风险。同样，这样的应用程序无法全面的保护数据不被盗取或者丢失，从而使数据面临风险。如果（a）不同部门针对相同的服务签订了合同，（b）业务承办方在启动自己的应用程序时没有考虑维护需求和集成要求，（c）他们开发和部署质量低劣的应用程序，然后返回来找IT部门解决问题，或者（d）上述所有，这些都会增加企业的成本，降低了企业的效率。
Gartner分析师Jason Wong说：“业务部门想要开发应用程序，这可能是好事，表明企业具有前瞻性的思维，使用移动手段进行创新，实现业务转型。但是IT部门必须参与。”
Greenwich Associates是金融行业的市场情报和咨询服务提供商，其全球首席信息官兼总经理Isaac Sacolick对此深有感触。
Sacolick说，虽然聘请供应商开发移动应用程序很容易，但是，当应用程序开发遇到复杂的问题时，业务部门通常不具备正确处理问题的能力。他说，业务部门可能没有全面考虑用户体验、安全要求、数据需求、与企业后端系统的网络连接，以及持续维护等问题。此外，他们可能缺乏评估供应商的技能或者经验，在开发项目的合同条款上也可能会措辞不当。
应对差劲的应用程序开发
然而，Sacolick和其他人不认为首席信息官应该，甚至可以阻止业务部门从事移动应用程序开发。相反，IT部门应该支持这方面的工作，这样才有可能实现更好、更安全的应用程序。
Gartner分析师Katherine Lord说：“首席信息官应接受这一点，因为这可能带来竞争优势。首席信息官不应该将其视为威胁或者认为业务部门争夺职能。让业务部门去干没什么问题。”
Sacolick说，首席信息官应该考虑部署低代码移动应用开发平台，在后端系统中创建标准API，以便今后的程序員使用，并根据需要找到外部开发合作伙伴，与之建立协议。
Forrester Research将低代码开发平台定义为能够以最少的手动编码实现快速应用开发和交付的平台。在2014年的一份报告中，Forrester说，这样的平台允许IT部门支持业务部门人员构建可持续、易于维护的应用程序。
巴黎圣母大学ND移动应用程序项目经理Matt Willmore认为API是一个好方法。Willmore说，在大学里，学生已经使用公开可用的数据来为各种任务开发移动应用程序。他们采取抓取或者解析方法来完成任务，但Willmore说他想创建公开的API来支持学生的移动开发工作。
需要：明确的标准，良好的管理
无论首席信息官选择给业务部门用户授权去开发，还是继续在IT部门内部进行开发，分析师认为IT领导应针对移动应用制定明确的标准，并展开最佳实践的交流。
Gartner的Wong说，在开发移动应用程序时，应确定使用什么样的工具、流程和标准，这样IT部门从技术角度可以确保应用程序能够可持续发展，而且符合企业的战略和安全要求。
Wong说：“IT部门应制定一套架构以及一套标准、政策和管理方法，以帮助促进移动应用程序开发的分散化和民主化，而不要使之成为瓶颈问题。”
圣母大学的Willmore正在朝这个方向迈进。他说：“我们要做的一件事情是给学生越来越多的资源让他们去开发。我们不想限制他们，所以我们组织了黑客马拉松和周末活动，与学生们交流，并为学生制定了开发框架。”
Willmore解释说：“之前，[一个应用程序]会被放到我们这里，这意味着由我们为其提供支持；现在，我们为他们建立框架，让他们在整个大学层面上进行开发。当需要支持的时候，那么我们已经将其置于我们的框架中了。” Lord说，沟通是使这种计划成功的关键所在。IT领导们必须与整个企业中的专业人士建立联系，让高管、经理们和员工知道移动应用开发政策和过程，以及IT部门可以为他们提供帮助这一事实。她补充说，这意味着要分配适当的员工时间来实现这一切。
Lord说：“这需要协作。不能只是由IT部门控制[开发]，或者由业务部门控制。”
这是独立蓝十字公司的Russo所采取的方法。他统一了公司的移动工作。他部署了Kony的应用程序开发平台，在IT部门中引入了敏捷开发方法，以便更好地响应业务部门的请求，并创建了一个由IT部门和业务部门工作人员组成的团队，执行移动发展战略。
他说，这些步骤使得公司能够针对重点关注的问题制定指南，包括用户体验和数据保护，2012年底公司推出了首款IT部门认可的移动应用程序——旗舰产品IBX。
Russo說，当业务部门想要实现移动应用时，他们现在来到IT部门，IT部门帮助确定他们是只需要向IBX添加一项功能，还是去开发新的应用程序，以及什么技术最能满足他们的需求。
Russo承认，在一定程度上，这是一种老式的管理方法，解决了差劲的移动应用程序带来的非常现代的“痛点”问题。
他说：“您建立了关系，而企业建立了对您的信任。经过四年的努力，我们获得了很好的声誉，所以当移动领域有需要时，他们知道来找我们。”
保持数据安全
德勤咨询集团内部服务线德勤数字的数字体验实践主管Steve Soechtig说，一旦企业已经制定了一些关于标准化的指南，并在企业内广而告之以确保业务部门了解这些指南，那么IT部门随后应该建立一个稳定的服务层，允许访问数据，提供会话服务。
“如果他们能够创建所有开发可以访问的公共服务层，那么他们可以保留控制。即使他们不直接控制开发，他们也控制着真正重要的东西：数据的安全性和完整性。”
他解释说，服务层是一个技术抽象层，它从前端移动或者Web应用程序中屏蔽了所有后端系统。
他说：“理想情况下，移动或者Web应用程序可以调用服务层来检索数据或者发布事物。”Soechtig说，强大的服务层还包括标准服务，例如安全、负载平衡和其他基本功能。
Mary K. Pratt是《计算机世界》的特约撰稿人。她在马萨诸塞州。
原文网址：http：//www.computerworld.com/article/3178745/mobile-apps/how-cios-cope-when-mobile-app-development-goes-rogue.html
业务部门经常独自开发移动应用程序，只有在出现问题时才转而求助IT部门。围绕业务部门及其移动应用程序需求更好地进行治理可以帮助缓解最糟糕的“痛点”。
当独立蓝十字公司在2012年发布第一个移动应用程序时，它同时也迎合了当时的技术趋势，影子IT从此长存下来。
这是因为该应用程序来自公司的市场部门——没有IT部门的任何参与。
和大多数影子IT项目一样，营销和IT部门来回推诿这一应用程序带来的问题。
当应用程序首次亮相时，位于费城的非营利健康保险公司的企业架构总监Ken Russo说，患者使用这一应用程序，以移动的方式访问独立蓝十字公司的会员网站，这实现了营销的目标，即在移动领域获得一席之地，但是从一开始就存在问题。
该应用程序是由营销部门雇用外部机构开发的，它依靠屏幕抓取技术与网站连接。所以每次公司门户网站出现变化（实际经常会变化），这一应用程序就没法用了。营销部门首先会去找供应商解决问题，然后才找IT部门寻求帮助。
Russo说：“解决方案非常脆弱。它需要供应商不停地进行维护，成本高得难以接受。此外，在一个平台上解决了的问题在其他平台上不一定能解决。我们需要更好的方法。”
有了这种经历后，公司领导决定采用更好的方法。Russo被授予新的角色和职位——消费者和移动解决方案交付总监，负责制定移动应用的技术战略。他决定采用一种流程，包括使用Kony移动应用程序开发平台，使应用程序能够按照业务部门的要求尽快完成。
企业着急在移动领域占有一席之地，导致业务部门自己开发和部署应用程序，这意味着IT部门正面临一个全新的影子IT时代。事实上，研究公司Gartner预测，到2020年，企业内部使用的70%的移动应用程序是在没有IT部门参与情况下开发或采用的。
事实上，这么多移动应用程序的开发与IT部门无关，对于一个不停地处理关键任务而过度劳累的技术部门而言，这似乎是好事。但这种情况还是让技术部门面临更头疼的问题。事实上，外部开发可能导致大量的问题落在IT部门身上——就像Russo所经历的那样。
差劲的移动应用程序带来的问题不止是浪费IT部门的时间。分析师说，如果没有正确的配置和集成，这样的应用程序可能会带来基础设施安全风险。同样，这样的应用程序无法全面的保护数据不被盗取或者丢失，从而使数据面临风险。如果（a）不同部门针对相同的服务签订了合同，（b）业务承办方在启动自己的应用程序时没有考虑维护需求和集成要求，（c）他们开发和部署质量低劣的应用程序，然后返回来找IT部门解决问题，或者（d）上述所有，这些都会增加企业的成本，降低了企业的效率。
Gartner分析师Jason Wong说：“业务部门想要开发应用程序，这可能是好事，表明企业具有前瞻性的思维，使用移动手段进行创新，实现业务转型。但是IT部门必须参与。”
Greenwich Associates是金融行业的市场情报和咨询服务提供商，其全球首席信息官兼总经理Isaac Sacolick对此深有感触。
Sacolick说，虽然聘请供应商开发移动应用程序很容易，但是，当应用程序开发遇到复杂的问题时，业务部门通常不具备正确处理问题的能力。他说，业务部门可能没有全面考虑用户体验、安全要求、数据需求、与企业后端系统的网络连接，以及持续维护等问题。此外，他们可能缺乏评估供应商的技能或者经验，在开发项目的合同条款上也可能会措辞不当。
应对差劲的应用程序开发
然而，Sacolick和其他人不认为首席信息官应该，甚至可以阻止业务部门从事移动应用程序开发。相反，IT部门应该支持这方面的工作，这样才有可能实现更好、更安全的应用程序。
Gartner分析师Katherine Lord说：“首席信息官应接受这一点，因为这可能带来竞争优势。首席信息官不应该将其视为威胁或者认为业务部门争夺职能。让业务部门去干没什么问题。”
Sacolick说，首席信息官应该考虑部署低代码移动应用开发平台，在后端系统中创建标准API，以便今后的程序員使用，并根据需要找到外部开发合作伙伴，与之建立协议。
Forrester Research将低代码开发平台定义为能够以最少的手动编码实现快速应用开发和交付的平台。在2014年的一份报告中，Forrester说，这样的平台允许IT部门支持业务部门人员构建可持续、易于维护的应用程序。
巴黎圣母大学ND移动应用程序项目经理Matt Willmore认为API是一个好方法。Willmore说，在大学里，学生已经使用公开可用的数据来为各种任务开发移动应用程序。他们采取抓取或者解析方法来完成任务，但Willmore说他想创建公开的API来支持学生的移动开发工作。
需要：明确的标准，良好的管理
无论首席信息官选择给业务部门用户授权去开发，还是继续在IT部门内部进行开发，分析师认为IT领导应针对移动应用制定明确的标准，并展开最佳实践的交流。
Gartner的Wong说，在开发移动应用程序时，应确定使用什么样的工具、流程和标准，这样IT部门从技术角度可以确保应用程序能够可持续发展，而且符合企业的战略和安全要求。
Wong说：“IT部门应制定一套架构以及一套标准、政策和管理方法，以帮助促进移动应用程序开发的分散化和民主化，而不要使之成为瓶颈问题。”
圣母大学的Willmore正在朝这个方向迈进。他说：“我们要做的一件事情是给学生越来越多的资源让他们去开发。我们不想限制他们，所以我们组织了黑客马拉松和周末活动，与学生们交流，并为学生制定了开发框架。”
Willmore解释说：“之前，[一个应用程序]会被放到我们这里，这意味着由我们为其提供支持；现在，我们为他们建立框架，让他们在整个大学层面上进行开发。当需要支持的时候，那么我们已经将其置于我们的框架中了。” Lord说，沟通是使这种计划成功的关键所在。IT领导们必须与整个企业中的专业人士建立联系，让高管、经理们和员工知道移动应用开发政策和过程，以及IT部门可以为他们提供帮助这一事实。她补充说，这意味着要分配适当的员工时间来实现这一切。
Lord说：“这需要协作。不能只是由IT部门控制[开发]，或者由业务部门控制。”
这是独立蓝十字公司的Russo所采取的方法。他统一了公司的移动工作。他部署了Kony的应用程序开发平台，在IT部门中引入了敏捷开发方法，以便更好地响应业务部门的请求，并创建了一个由IT部门和业务部门工作人员组成的团队，执行移动发展战略。
他说，这些步骤使得公司能够针对重点关注的问题制定指南，包括用户体验和数据保护，2012年底公司推出了首款IT部门认可的移动应用程序——旗舰产品IBX。
Russo說，当业务部门想要实现移动应用时，他们现在来到IT部门，IT部门帮助确定他们是只需要向IBX添加一项功能，还是去开发新的应用程序，以及什么技术最能满足他们的需求。
Russo承认，在一定程度上，这是一种老式的管理方法，解决了差劲的移动应用程序带来的非常现代的“痛点”问题。
他说：“您建立了关系，而企业建立了对您的信任。经过四年的努力，我们获得了很好的声誉，所以当移动领域有需要时，他们知道来找我们。”
保持数据安全
德勤咨询集团内部服务线德勤数字的数字体验实践主管Steve Soechtig说，一旦企业已经制定了一些关于标准化的指南，并在企业内广而告之以确保业务部门了解这些指南，那么IT部门随后应该建立一个稳定的服务层，允许访问数据，提供会话服务。
“如果他们能够创建所有开发可以访问的公共服务层，那么他们可以保留控制。即使他们不直接控制开发，他们也控制着真正重要的东西：数据的安全性和完整性。”
他解释说，服务层是一个技术抽象层，它从前端移动或者Web应用程序中屏蔽了所有后端系统。
他说：“理想情况下，移动或者Web应用程序可以调用服务层来检索数据或者发布事物。”Soechtig说，强大的服务层还包括标准服务，例如安全、负载平衡和其他基本功能。
Mary K. Pratt是《计算机世界》的特约撰稿人。她在马萨诸塞州。
原文网址：http：//www.computerworld.com/article/3178745/mobile-apps/how-cios-cope-when-mobile-app-development-goes-rogue.html