老且仍然有用的十个信息技术原则

虽说事情并不完全如此,但是每一扇通往信息技术的大门上都应该刻上这么一句话。这当然比“进入此门者须放弃所有的希望”好多了。

至顶网CIO与应用频道 01月03日 编译:虽说事情并不完全如此,但是每一扇通往信息技术的大门上都应该刻上这么一句话。这当然比“进入此门者须放弃所有的希望”好多了。

幸运的是,信息技术早期的很多基础智慧到现在仍然在发挥作用,不过是以不同的方式,更为现代化的方式。这里有十条老派的原则,可以引导你进入下一代的信息技术,同时附上的还有你应该采用的方式同老版本做法的区别。

从来都不是只考虑技术有多好

旧版本:“从来没有人因为采购了IBM而被解雇”。

新版本:开源可以提供同样的好处。

你采购的技术是你的长期承诺。你也需要它有来自供应商的长期承诺。

为了安全起见,信息技术部门一度喜欢从大厂商那里进行采购。现在?开源产品不仅可以做到非常安全,有时你甚至也可以从IBM或其他大型供应商那里采购它们。

并不是所有的开源技术都有足够广泛的支持,但是确实有很多开源技术已经具备了这一点。例如,如果PHP能够完成这项工作,那么考虑到其可怕的安全记录,你会再看Java第二眼吗?然而,Java是身为世界上最大的软件公司之一的Oracle支持(也许在这里用“提供”一词更为准确)的。

这也不是什么新鲜的事物了。毕竟开放源代码式的共享程序库可以追溯到上个世纪七十年代。

良好的信息安全从良好的物理安全开始

旧版本:保持硬件锁定

新版本:并不一定要锁定你的房间

我们一直将硬件保持在锁定的状态,只授权允许少量的员工进入数据中心,并且用自动日志记录谁、在什么时间进入了数据中心。但是现在,不是每一个上锁的房间都是我们自己的了。

尤其对于中小企业来说,还有很多其他的选择,从使用本地设施到全面使用云计算。

但是不要把所有的积蓄都放在你自己的数据中心之外。投资一些低延迟、高带宽的网络连接你的场外供应商。还有一个甚至更好的做法:应用另一个旧的原则——不要有任何东西。在你的办公楼内相对的两边设立两个存在的点,将两者连接起来,这样就不能通过在不合时宜的地方挖上一个洞让你的业务出问题了。

了解安全威胁

旧版本:清查安全威胁和实施对策

中间版本:锁定桌面并保护边界

新版本:增强资产。同时也保护边界

在过去,阻止安全威胁基本上意味着CICS会话超时,这样黑客就无法拨入或者继承它们。然后是个人电脑、分布式系统、互联网,以及很多其他的威胁。我们回应的方式是锁定桌面电脑,并且用越来越复杂的防火墙保护网络边界。

许多人仍然认为,最好的对策是锁定一切,不要让任何人有创意。但是,企业的生死存亡都建立在创新之上,创新不仅仅意味着销售新产品。它意味着创造性的思维,以及在业务的方方面面都贯彻这种思想。

现在我们应该花更多的时间来增强资产而不是边界,而且应该花更多的时间积极地支持用户,因为企业最大的威胁就是不允许员工创新。

测试软件不仅仅意味着将代码投入生产然后看看会发生什么

旧版本:保持三种环境——开发环境、测试环境和生产环境

新版本:将大量测试转移到云端

回归和压力测试将专业人员同业余爱好者区分开来。他们总是这样做,而且他们仍然在这样做。回归测试确保新的东西不会破坏旧的东西。压力测试确保在每个人都同时使用时,一切都能表现得足够良好。

专业的信息技术人员至少要维护三种环境——开发环境、测试环境和生产环境。这意味着所有的东西都要购买三份。而且还要维护它们。哎哟!

现在,即使你维护自己的数据中心,将测试环境搭建在云端往往也会更有意义,因为你只要在你需要的时候付费就行了。它也可以根据你的生产环境,很好地进行回归测试。

压力测试?现在还没有。至少到目前为止,还有太多的变量。

控制生产环境的变化

旧版本:一个正式的更改控制流程

新版本:一个正式的更改控制流程

我们早已经过了开发人员直接就能将新代码投入生产的时代。必须要经过一个流程。其实没有人喜欢这个流程,但这可不是喜欢或者不喜欢的问题。这是为了确保更改不会影响生产,如果它会影响生产,就要确保有一个退出计划。

是不是觉得云计算改变了局面?它确实如此。它让更改控制变得更加困难,因为现在,如果你不能够对于你的云供应商小心管理的话,他们可能会在不通过你的流程的情况下,就将更改投入生产环境。

毕竟,这是在他们的基础设施上。

瀑布式的方法应该奏效,但是实际上敏捷开发才真的有效

旧版本:商业经理和程序员之间的非正式来回交互

新版本:敏捷开发(Scrum):商业经理和程序员之间非正式的来回交互,只是有一大本的规则要遵循

很久以前,正式的开发方法让信息技术逐渐失去了乐趣,业务经理们曾经会在路过的时候问道:“你能让计算机做这个吗?”然后程序员会尝试一些东西,并向业务用户展示,然后迭代直到它正确完成。

他们并不会将这种方式称之为敏捷开发。他们称之为“讨论计算机应该做什么”,虽然如此,但这确确实实就是敏捷开发。

然后瀑布方法出现了。这些方法也会有用……如果业务经理们能够完美地设想一个完整的工作系统,并且精确地将其描述出来的话。但是他们做不到这一点,所以我们失去了三十年的生产力。

进入敏捷开发需要迭代和交互,并且增加了足够多的方法以消除信息技术部门通过其他版本的敏捷开发找回的大部分的乐趣。

关系先于流程,而且关系超越事务

旧版本:管理同其他企业高管之间的关系是首席信息官工作的核心部分

新版本:管理同其他业务部分的关系是每个人工作的核心部分

企业首先是各种关系的集合,这一点先于其他的意义。有了良好的关系,一切工作都可以完成。如果没有良好的关系,一切也都成了不可能。

在企业是严格的等级结构的年代,首席信息官管理同其他企业高管的关系,这就足够了。如果其他的企业高管不信任首席信息官,信息技术部门就无法成功。

但是,信息技术部门的任何一位成员在任何时候同企业中的其他人进行的交互,都会影响业务和信息技术部门的关系。这可不仅仅是首席信息官和其他企业高管的事。如果企业内其他的部门不信任信息技术部门,信息技术部门就无法成功。如果他们信任信息技术部门,那么信息技术部门的一切工作都会变得更加容易。

注意,不是容易,而是更加容易。

整合,因为把“自动化孤岛”彼此连接起来从业务流程上看太愚蠢了

旧版本:自定义编程的批量接口逐渐积累。

新版本:服务总线或设计了实时接口的同等服务。

甚至是更新的版本:还能够与非信息技术部门推动的SaaS解决方案相集成。

当人们需要把计算机生成的报告中的信息重新输入到数据输入页面中的时候,信息技术部门意识到它最重要的职责是整合不同的系统以保持数据同步。

所以它创建了接口。很多很多的接口。各种自定义批量ETL。

现在,接口实在是太多了,多到难以维护的程度,造成了一片混乱。所以聪明的信息技术部门会投资于服务总线,或者某种类似的东西,并且为它设计接口,因为只是把一个系统堆在另一个系统上意味着“穿着新鞋走老路”,新的技术又会重新创造出老的混乱问题。

如今,很多信息技术的使用都是发生在信息技术部门之外的。这主要是指业务经理们以SaaS的形式引入的技术,这些技术成了自动化孤岛。他们逐渐厌倦了让自己的员工重新录入数据。要为此做好准备。

信息技术部门存在是为了支持业务

版本太过老旧,完全是陈词滥调了:不要为了技术而技术。

新版本:提供技术领导力。

为了技术而技术是一件糟糕的事情。但是这并不意味着信息技术的作用应该被限定在处理工单上。它必须超越这一点,提供技术领导力。

任何无法提供技术领导力的信息技术部门——建议和讨论,不仅仅是接受和交付——从根本上来说都是失败的。

技术领导力还意味着支持准备购买或者构建自己技术的经理和用户们。现在是时候认识到“影子信息技术”是一件好事情了,因为它增加了信息技术部门的带宽。

当然,这是有风险的。但是任何值得一做的事情都有风险。

信息技术必须帮助企业中的每个人都使用他们自己的技术取得成功,而不是因噎废食地阻挡一切,让“这里没有创造。”

这是为了业务变革,否则还有什么意义呢?

旧版本:信息技术是整个业务变革的主要动力。

中间版本:信息技术是业务变革的最大障碍。

新版本:信息技术是整个业务变革的主要动力。

当计算机还是亮闪闪的新生事物的时候,企业的高级管理人员指望用它在企业的各个地方推动变革,让业务流程变得更快、成本更低,而且还能够减少人工错误。

这种情况持续了很长时间,直到信息技术部门不得不支持如此之多的互联系统,以至于想要做任何新的事情都耗时费力、成本高昂而且充满风险。对瀑布式方法的依赖也无法解决这一问题。

最终我们再一次失败了。现在有了敏捷开发、更好的集成工具和非信息技术部门推动的信息技术使用,信息技术正在再一次开始推动变革,而不是在后面跟随变革的脚步。

来源:COMPUTERWORLD

0赞

好文章,需要你的鼓励

2018

01/03

17:20

分享

点赞