架构组织管理
架构组织管理的五大原则：构想、节奏、预见、协作和简化
架构组织的三在概念：准则、模式和反模式
准则：为了把原则运用到实践中，需要实施细节。准则把广泛的原则翻译成是否和如何执行原则的细节。
模式：描述了开发或者使用软件架构时可能遇到的常见问题的解决方案。
反模式：反模式描述了组织在实践中可能遇到的陷阱，描述了不该做的事情，或者用在错误背景下的解决方案。
一、构想
说明了如何向架构的受益人描述一幅一致的、有约束力和灵活的未来图景。构想需要维持一致性和协调性（灵活性）。
【其实就是和客户及开发团队保持一致，同时考虑扩展，为了更好的保证一致性可以使用RUP的“4+1构架视图”（逻辑视图【用户】、实现视图【软件开发工程师】、用例视图【系统分析人员】、进程视图【软件集成工程师】、部署视图【软件工程师】）】
【理解客户迫切价值；将客户价值映射成能解决问题的解决方案；将以上问题转成一组特定的约束条件】
验证构想准则：
1、架构师的构想与发起人、用户、最终客户期望实现的目标是否保持一致。
反模式：风险后置 【先分析问题将可能存在的问题先找出确定可行性，应该主动向上层提供一个选择】
模式：前后一致 【架构是多用户使用，有特定的用户需要特定的功能但可能会破坏架构质量和稳定性，应该将上级拉入架构构想中让他们知道风险】
2、实施人员信任并使用架构。
反模式：墙头草【确定了构架以后要对架构作任何加入都应该开休讨论会对新加入功能进行审核，避免开发人员的对开发人员对架构的不信任应该及时兑现承兑】
模式：三人臭皮匠【架构的思想并非只来自己架构师，高级提供构想，架构平台留给架构师，实现细节留给开发人员】
3、关于架构和构件的潜藏知识对其用户是可见的
反模式：一叶障目【知识共享（培训、专题讨论、启用知识管理平台）】
模式：轮流工作
【总结：构想是架构搭建的关键也是思想上大家统一确定如何实现目标的架构，此步骤的关键在于将上级和下级的发动，上级确定目标，下级确定细节，保证需求一致正确。最后就是知识的共享，这样增加团队凝聚力。创建一个学习型应用合并的团队，有必要时应该工作轮转（解决学习和管理）】
二、节奏
节奏原则：刻画了一种在整个组织范围内的协调程度，即定期地根据可预测的速度、内容和质量对制品生产进行检查与规划。
【节奏是一个架构团体内部及它与客户和供应者之间反复出现的、可预测的工件交换活动，其实就是控制架构开发的进度及解决出现的问题和客户和开发团队】
准则：
1、定期地再评估、同步和调整架构。【定期讨论会议，及时讨论问题解决问题】
反模式：一步成功 【一个架构的发布不是只针对现在或特定功能，它应该是一个完整性的、系统性的架构。如果存在市场机遇的时候可以先发布一个围绕特定功能，利用此主题抓住市场。再发布系统版】
模式：发布委员会
2、架构用户对架构发布的进度和内容具有高度的信心。
反模式：超敏捷【高层管理的行动更直接地改变组织行为时组织行为不能得到严格的遵守】
模式：舍兵保帅【当一个架构发布不能按预期阶段发布时，应该主动与客户沟通，将不太重要的特性移到后面发布周期】
3、通过节奏协调明确的活动
反模式：销售未检验的产品【问题不能积累，定期建立应该的成功】
模式：同步发布【与合作伙伴一起确定交付架构特性的先后顺序】
【总结：节奏它强调的是一个按计划进行。不能让问题积累，出现问题应该立刻解决。当时间有冲突时应该舍兵保帅，制定制度严格执行（架构定期评估、避免高层改动）架构应该是一个长期的系统的稳定的】
三、预测
要在预测未来与检查并适应现状之间做出平衡
准则：
1、预见风险、预见客户、预见客户的需求、预见市场驱动标准和演变技术、预见战略业务方向的改变
反模式：遗漏细节【其实就是需求的不全面，让业务专业参与，调研覆盖面很重要】
模式：示范区【大面积推广前先进行实验】
2、通过快速复审和开发周期，评估技术和业务上的风险与机会
3、当认识到关键的估计或假设有错时，及时调整功能特性、预算
【总结：其实预见就是对当前架构及构架所相关知识与市场的预测，以及架构项目的管理】
四、协作
1、架构师不断地了解谁是最关键的受益人，他们如何贡献价值，以及他们需要什么
反模式：光说不做
模式：了解你的受益人
2、受益人之间达成明确和强制性的契约。
反模式：不记录讨论结果
模式：互惠互利
3、通过社会行为制度和非正式规范强化合作。
反模式：非正式时间做正式工作
模式：杜绝意外【变更时应该及早的提醒】
模式：和HR密切和作
【总结：协作其实就是管理以及和客户打交道，了解他们需求，将达成的契约强化（记录）另外就是和下级开发人员的协作及各种旁类资源的协作】
五、简化
简化是指将所作用组织与环境都进行巧妙地理解与最小化，组织形成架构并且思考架构。
准则：
1、开发人员长期使用架构，减少总成本和复杂性
反模式：简单复制并修改
模式：由慢而快
2、架构小组明确理解关键最小需求，并且将其构造成多应用共享的核心元素
反模式：缺乏有效抽象【每次加入时避免出现榕树、根部肥大】
模式：迁移途径
3、通过长期的预算和行动确保当相关元素没有被共享、增加了不心要的复杂性时或者是因为有明确的业务理由时，把相关元素从核心移走。
反模式：编码大于架构【把首席架构师的埋单合理分配给实现新特性和调整架构两个任务，让最能干的工程序师来领导实现新特性】
模式：统计构件变更
【总结：简化其实关注的就是代码的简化，可使用设计模式进行抽象等】
