架构师
作为一名企业架构师，当自己的组织开始向精益或者敏捷实践转变的时候，很有可能会感觉到一些失落。在转变之前，你经过了非常努力的工作才达到了架构师的位置，你可能编写了保持企业运行所需的大部分关键系统软件，帮助实现、甚至是设计了整个架构。你知道架构中的哪些地方使用了比较老的技术，哪些地方比较脆弱，但是由于没有资源和时间去改变而不得不对现实妥协。
同时，由于只有你知道如何保持事情运转，所以很多事情不得不亲力亲为，导致自己没有精力去研究探索最新的趋势。而为了提升时间的利用效率，你制定了统一的标准，并且尝试着在架构评审或计划会议上控制需求。但是开发人员由于不清楚公司良好运转的条件，对每天重复的老套工作和繁琐流程充满了抱怨，使得你不得不加强政策从而尽量保持控制。
现在，新的领导或者咨询公司来了，他们声称组织应当 “变得敏捷”。对此，开发者的理解是，敏捷和灵活性允许他们做自己想做的任何事情。于是，他们开始将你看作是陈旧事物的代表，开始颠覆或者忽略你。他们引入了可能会破坏基础设施稳定性或者可能会在关键时刻引发系统故障的实践和技术。虽然你清楚组织依然需要你，但是却感觉每一个人都在和自己做对。
事实上，他们可能比以往任何时候都更加需要你。需要你的知识和经验将风险和管理成本最小化，将技术任务与业务对齐。只不过虽然任务还是那些任务，但实现方式与之前相比有一点不同。因为无论是精益还是敏捷，它们都关注于价值创建、成本缩减和快速反馈，因此，如果想在新环境中取得成功那么你必须接受一些新的实践。例如，共享简单的愿景、建立桥梁、对齐业务、提供指导等所有可以促进创新的努力。
那么如何实现这种转变呢？总体来看，企业架构师和其团队需要从传统的实践中进行转变。架构师将成为信息的影响者和聚合者，同时也是信息的传播者，其角色定位不再是自己做决定，而是帮助其他人做出正确的决定。而要实现这一目标需要一些新的工具和技术。下面将会介绍一些关于如何扮演好这一新角色的途径，虽然想法比较高层，并非适合所有的组织，但是每个组织的目标是灵活的，通过技术实验和效果衡量，团队可以从中选择适合自己的，舍弃不适合的。
拥有并共享同一个愿景
保持一致性的第一步，也是非常重要的一步，就是让整个组织拥有一个长期的目标。想清楚当前和将来的架构是让项目保持协调一致的关键。应该从评估现在的架构开始，找出目前都有哪些系统，它们的作用是什么？这一步不需要深入详细的描述，也不用找到它们都部署在哪台服务器上，只需要理清楚应用程序和产品以及它们之间的关系即可。
整个架构可能分很多层。如果是大型组织，那就先将问题分解成功能区，然后再一个个的找出来。如果有基础的架构模式或者策略，那就识别出来，看看哪些地方遵循该模式，哪些地方没有。例如，如果组织采用的是面向服务的架构，那就看看哪些应用程序基于该架构直接访问主数据？它们如何与常用的数据库通信？
在搞清楚系统当前的状态之后，接下来就需要考虑清楚将来的架构是什么样子。是否应该保留与现在一样的基础架构？完全采用全新的架构是否会更好？当前架构有哪些优势和劣势？如果要演化当前的架构，那就创建一张架构更新图，在图上将变化的部分与保留的部分区分开。如果整体架构的变化是必要的，那就要清楚理想情况下最终状态是什么样。要记住，这是一个比较长远的、需要技术组的其他人遵循的愿景。
有了愿景之后，还需要确保组织中的技术领导者能够理解它。这就需要向关键的开发者介绍愿景，获取他们的反馈。通常，他们比你更清楚某些事情的来龙去脉，也更能帮助你更好地理解架构。你需要愿意并且渴望基于这些反馈调整愿景。如果要对整体架构或者某个特定区域做出革命性的改变，尽量让团队认可这种转变，因为这会让愿景更容易实现。尽量不要让架构成为一种任务，而应该将其看做是一种能够让开发团队建立共识的工具。要让开发团队成为你的合作者或者同盟。因为他们积极地参与远比完全按照自己的想法推进愿景更有价值。
在达成某种程度的共识之后，一定要让所有人都知道当前的架构和将来的架构分别是什么样子。这并不是说要将它们放到磁盘上的某个文件夹、SharePoint 网站或者 Wiki 上，而是要制作海报或者一整面墙的涂鸦，在很多地方展示它们，确保每个人都能够了解该愿景，并激励他们不断地向该目标努力。在架构演进的过程中，这些图画也需要随之改变以反映当前的工作进展。要展示出那些正在提升的地方并认可为之付出的团队。如果其他人对一起构建伟大架构的工作感到自豪，那么他们就会支持你的工作。
建立桥梁
有了愿景之后，你就想它成为现实。但是既然你或者你的团队并不开发或者管理项目，这又如何实现呢？最好的方法就是成为开发团队的合作者和资源。你的目标并不是限制或者阻碍工作的进展，而是促进它。当某个团队开始开发的时候，与他们的技术经理和项目经理沟通，向他们展示更新后的企业架构图，讨论如何让他们的项目实现这一愿景。通常情况下，团队从事的工作与企业正在进行或者已完成的项目相似。架构师应该确保团队负责人了解这些项目，以便于能够在实际的代码和产品中利用共享的经验。尽量不要关注实现细节，不要关心使用的类库及其版本，要关注高层目标和项目设计以及它们与整体愿景的对齐方法。
在讨论项目的时候，不可避免的会遇到技术选型的问题。大部分情况下，团队会倾向于使用与公司其他项目相似的技术。但是，技术人员偶尔也会学习一些新技术，并想使用它们来解决问题。
此时，不要立即对新技术说不，或者主观地认为技术人员选择新工具的原因仅仅是因为它新或者它非常有趣。虽然这种情况确实存在，但也有可能人们为解决问题而创建的新工具正好恰逢其时。应该与技术团队讨论决定使用新技术的理由是否充分。确保团队理解将新平台带到产品中的成本和困难，以及这些付出的回报。
架构师必须要学会倾听，并在给出结论之前做一些探索，通过实际的测量和边界做一些时间可控的概念验证，以此来确定可行性。如果最终发现新技术并不是正确的选择，那就试着与开发人员或者他们的领导沟通，达成一致意见。尽可能地不要让变化成为一种任务，那样不利于你与开发团队之间良好关系的建立，无法确保他们会在将来做决定时考虑你的意见。在实验新工具或者技术的时候，要限制公司在同一时间段内进行的实验的数量，因为同时进行多种实验很难精确地衡量每一个所产生的影响。
最后，成功的企业架构师只能是那些能够取得开发团队支持的人。如果你将他们当作下属，他们就会找到应付你的方式，将组织愿景和战略至于危险境地，此时你依然需要对结果负责，却几乎没有改变的能力。相反地，如果你将他们当作合作伙伴，那么他们就会帮你实现愿景，所有人都会取得成功。要拥抱变化，衡量变化，确保每一个人都理解变化的价值，同时始终都应该尽量引导团队实现组织架构的愿景。
寻找改变的机会
大的改变需要时间和机遇。一旦确定了将来的愿景，我们就会开始在企业里营造兴奋的氛围，并想立即看到结果。但有一点非常重要，那就是要时刻牢记对架构进行较大的调整需要循序渐进，需要合适的时机。要从已有的项目开始改变，引导新的实现向架构愿景的方向发展。要记住改变代码使之向预定方向发展的机会可能并不会按照期望的速度或者从期望的区域进行。要学会庆祝胜利，无论是多小的胜利，要对能作出积极改变的机会保持警惕。
也就是说，要优先处理组织已有项目中最糟糕的那部分。业务领导几乎不能理解改变技术组件的价值，也不清楚维持现状的成本。当需要纯粹的技术变化时，需要创造机会进行改变。根据改变将来对业务的价值、节约的成本以及降低的风险决定改变的速度。如果有必要，从业务部门寻找一个合作伙伴，创建一个既能增加业务价值，又能改变架构的项目。要寻找机会移除那些拖了预算和运营团队后退的老应用程序和硬件。
耐心和合理的改变速度有助于避免挫折。记住，只能改变正在进行的工作，因此预算应该尽可能地包含大部分项目。通过识别那些能够为业务创造新价值或者节约更多金钱的新项目而不是通过节约开发成本来创造机会。要记住，产生业务价值是最主要的目标，因此要避免那些有趣却没有价值的、纯粹的技术项目。当业务认识到遵循愿景所增加的产量和价值，他们做出改变的势头和步伐就会加快。此时，就有机会继续塑造并精炼愿景了。
构建学习社区
除了要对整个企业架构有一个愿景之外，企业架构师还需要清楚愿景的执行需要正确的技能和实践。每一个开发团队都需要学习并提高成功所需要的技能，在不同的团队之间共享最佳技能和实践有助于提高每一个人的能力，并建立共同的目标感。作为团队之间的桥梁，企业架构师最适合培养这种团队意识。
构建社区的方式有很多种，例如非常规的午餐和第三方培训。不要试图自己决定组织需要的内容，应该建立一个技术小组，让技术领导和那些热衷于技术的开发者参与进来帮你做出决定。团队通过定期的会议制定相关计划。确保为开发团队预留一定的时间让他们分享自己的经验——无论是成功的还是失败的。让所有人都有机会与整个 IT 组织分享知识是一个健康的组织构建社区意愿的开始。
尽量不要强制人们参加培训和学习活动。这些活动应该是开放的，大家可以根据自己的意愿选择。让人们参加不感兴趣的课程非但无法达到预期的效果，反而会挫败主讲人的激情。那些充满激情的人会乐于接受学习和成长的机会，那些不想提高的人则不会从这种机会中受益。
社区感和学习的机会会激励开发者，增强他们的归属感。通过引领社区的核心，你能够引导组织的开发团队向规划的愿景对齐，而允许其他人参与这种过程则有助于从内部确定并构建领导关系。此外，强烈的自豪感和社区感能够产生更好的质量和更多的协作。
结论
改变从来都不是容易、快速的。向新的实践转变需要时间和努力，但最终你会发现这是值得的。当团队能够一起协作创造价值，业务将 IT 看做是合作伙伴而不是负担的时候，所有的一切都是值得的。记住，一个精益企业的架构师能够让开发团队和业务部门建立合作关系，能够创建一个愿景并引导开发团队向该愿景努力。知识虽然不是很深入但是却很广泛，能帮助开发者提高自己，能通过明智的实验进行概念验证。最重要的是，懂得享受自己，能够学习新事物并创造价值，能让组织成为业界领先的创新者。
相关阅读
在我们的动画的制作中，由于一部分细致的k帧如人物表情，手部的活动是需要细致k帧的，而一些大的持续长的人体动作k起帧来比较麻烦，所以
0 创建测试用户 create user soctt identified by 11; grant dba to scott; create user one identified by 11; 1 角色role --
产品经理的核心竞争力是什么？产品经理要如何做才能成为一个成功的产品架构师呢？产品经理的核心竞争力会体现在输出决策的质量上，总结
此处介绍下Oracle的权限等级 sys;//系统管理员，拥有着最高权限 systen;//本地管理员，拥有次高权限 scott;//普通用户 角色（即权限
一个后台的用户角色权限系统总是可以大概划分为三个打的模块的：用户管理、角色管理、权限管理。本文作者将就此三个模块展开叙述，en