从敷衍了事的管理态度、手工修改密码再到冗余的业务应用，这些迹象都是判断IT环境是否陷入一团乱麻的重要标志。
在技术部门实际着手为企业部署IT架构、组织团队为计算环境的不断扩大而积极筹备维护之前，我们必须先拿出大量时间和精力提前制定规划。在接下来的实施过程中，我们还有机会顺便将项目中的某些暂时性方针加以扭转、消除部门之间的政策差异并解决全局层面的管理失误，最终将原本清晰的架构管理战略真正依靠严格有序的决策提升为能够服务于业务的项目技术组件。
如果企业出人意料地步入发展歧途，你能及时发现端倪吗？在本文中，我们将汇总九大标志性迹象，帮你及时鉴别糟糕的IT架构。
结构化影响：密钥更新失误很可能带来数据损失。
直接业务影响：将业务资源浪费在毫无意义的简单重复工作当中。
手工密钥更新
手工密钥更新也许还算不上糟糕的企业IT架构所能带来的最大麻烦，但却绝对是最常见的情况之一。雇佣人手代替应用程序之间的连接接口不仅带来大量额外运营支出，同时也相当于浪费了人类的聪明才智。
结构化影响：对系统接口的需求量增加，且必须为一系列平台提供支持； 通常伴随着手工工序过多一同出现。
直接业务影响：严重拖慢业务流程，提高培训成本，并带来手工工序过多的问题。
汇总最佳解决方案
每个人都希望自己能以最佳方式解决工作中的实际问题。尽管我们知道“工作”并不只是一个简单的概念，而且工作人员必须访问大量应用程序才能找出同类途径中最优的方案，这就导致完成工作往往需要耗费很长时间。
与此同时，除非IT部门花费大量时间为各种类型的解决方案打造连接接口，否则我们根本无法以敏捷方式处理任务，事情也就回到了一切以“手动”方式进行的老问题上。
结构化影响：对系统接口的需求量增加，且必须为一系列平台提供支持。
直接业务影响：将IT资源浪费在毫无意义的重复劳动之上； 为了支持那些根本无法为业务提供新功能的软件而浪费大量资金投入； 通常会带来手工工序过多的问题。
冗余应用
每一款业务应用程序存在的目的都是解决业务问题。能解决业务问题当然是好事，而多款应用都能用来解决同一个业务问题就更是好上加好了，对吧？
答案显然是否定的，但时至今日大多数企业仍然在使用大量冗余应用程序。发生这类情况的原因多种多样，也许是特定业务领域需要此类重叠式支持，或者随着企业规模的扩大、兼并及收购活动的加剧，各分支公司的运营模式会加入到母公司自身的流程当中。
无论是哪种情况，花钱为所有这些冗余应用买单都是极具败家的做法，纯粹的浪费需要立即得到制止。
#p#副标题#e#
结构化影响：对系统接口的需求量增加； 通常会引发手工工序过多的问题。
直接业务影响：在多种数据库系统之间保持数据同步及必要维护极其困难，这不仅会浪费大量人力物力，而且很可能导致查询不同数据库时得到的结果各不相同。
冗余数据
大家肯定常常遇到这种情况：不同应用程序需要调用同一种信息来完成相关工作。这时我们有两类处理办法：将所有应用指向同一套底层数据库，这种想法虽好，有时候却无法实现； 或者是为各应用分别建立数据库并加以同步，而这往往是数据一团乱麻的开始。
另外，简单重复劳动被迫以手动方式处理的问题再次出现——还真是阴魂不散。
结构化影响：系统过分脆弱且难于维护。
直接业务影响：将大量IT资源浪费在毫无意义的重复劳动之上。
接口过多
在冗余数据无法避免的情况下，大家往往会选择以同步机制解决问题，也就是说需要建立一套新的接口。即使没有冗余数据的存在，我们也经常需要从一套系统中收集结果并交付到另一套系统处。
无论是哪种情况，系统及数据库越多，我们最终需要创建的接口数量就越庞大。有接口当然比没有好，但随着日积月累，我们的IT架构会变得越来越脆弱； 这时我们会发现自己根本没有时间开发什么新功能，所有精力都被耗费在无尽的接口管理当中。
结构化影响：系统同样过分脆弱且难于维护。
直接业务影响：同样是将IT资源浪费在毫无意义的重复劳动之上，而且带来大量成本支出。
“看起来很美”的整合方案
接口太多令人手忙脚乱，这时精致的企业级应用程序整合系统或者服务总体管理自然会粉墨登场。总之，在这种情况下各种开幕式的中间件与元数据会成为大家心目中令一切恢复正常的最佳选择。
然而结果常常令人失望：（1）那些看起来既先进又智能的系统只能让简单的问题变得更简单，而根本无法直接解决问题； （2）这些系统对于传统难题仍然束手无策。为了堵住客户的嘴，服务供应商们狡猾地将接口体系重建并隐藏在EAI系统之中，这样表面上就看不出什么毛病了。
#p#副标题#e#
结构化影响：为了解决当前问题不惜引入脆弱的系统。
直接业务影响：解决方案越多，维护成本也就越高，同时宕机机率、技术团队培训费用以及子项目的复杂性都会相应提高。
敷衍了事的管理态度
也许大家的竞争对手正以极低的报价与我们争夺某个项目； 可能商业赞助就快到期，而项目仍然无法及时完工； 又或者一丝不苟的态度将导致整次交易血本无归。
无论出于哪种原因，一旦我们采取敷衍了事的管理态度，那么总有一天这套满是补丁、漏洞的系统会来个大爆发，彻底停止工作。
当然，如果大家足够幸运，没准它能坚持到我们离职或者退休，不过机会不大就对了。
结构化影响：提高维护技术难度，并需要与新系统及设备相连接。
直接业务影响：提高维护成本； 令现有系统很难根据业务需求做出灵活的调整及变化。
使用陈旧技术
这是关键性业务！它完全能够满足业务需求！这两个理由似乎足够让我们选择不那么新潮的技术，所谓“提高维护成本”指的是什么呢？
当大家利用微软在十年前就已经不再支持的Visual Basic版本编写程序时，也就意味着这套开发成品无法被近七年内任何版本的SQL Server所读取或写入，而且支持该程序的惟一一款Windows系统不支持当前市面上任何一款主流打印机的驱动程序——这就是“提高维护成本”的意思。要解决上述问题，我们必须得额外掏钱，还要劳神费力。
结构化影响：无——不会有人对内容感兴趣的。
直接业务影响：雇佣这种专家纯粹是浪费工资，把他们的意见打印出来则浪费了纸张和油墨，而且这种一厢情愿的管理方式只会换来员工们的无情嘲讽。
白皮书
我们看到一大堆批判现状的警示标志，因此我们成立企业技术架构管理小组，同时雇佣一到两位常驻专家。而这些专家的工作成果似乎非常令人满意。
所谓“工作成果令人满意”，是指我们总能看到一堆堆读不完的白皮书。他们组织的这些材料真能给IT架构带来改善吗？很遗憾，几乎没人真的在乎他们在材料中写下哪些总结。事实上正是因为没人关注、没人咨询，这些专家才会闲到再去撰写更多的白皮书。这是一种恶性循环，我并不否认专家意见的重要性，但让这些意见落到实处显然更为重要。
原文链接：http://www.cioage.com/art/201205/97486.htm
