基于Portal构架的企业门户系统设计与实现

IT架构规划方法论

IT架构规划方法论

项目方法及成果 项目方法 完整的IT战略包含三个基本层面：IT战略方向、IT架构和IT管控。 无论是对于一家企业，还是对于政府机构，IT战略总是与业务战略紧密相关的。一方面，业务战略决定了IT的战略方向，而另一方面，IT战略则为业务战略的实现提供支持。因此，在确定客户的IT战略方向时，既要看业务发展对IT提出了哪些要求，也要看IT能在哪些方面促进业务的发展。具体来讲，确定IT战略方向时要明确以下四个方面的问题：IT愿景、IT发展的目标、IT在业务发展中的角色以及应该具备的IT能力。

IT架构包含流程和数据、应用系统以及IT基础设施（硬件设备、系统软件和网络等）三个方面的内容。其中，流程和数据部分解决的是IT与业务的接口问题，对于客户而言，如有必要，在制定IT战略时有可能需要对部分的业务流程进行适当的调整与优化。 IT管控也是IT战略中很重要的、但常常会被忽视的一个组成部分。IT管控包括IT部门的业务流程、IT部门的组织模型、IT部门与人员的业绩目标和考核方法以及各种IT业务规范和业务标准。 总的来讲，在项目启动之后，整个规划项目将划分成四个关键的步骤：分析业务与IT现状、确定IT战略方向、设计未来IT蓝图以及制定IT战略实施计划。各个阶段将分别完成一系列任务，并提交相应的工作成果。

在整个项目过程中，最关键、最核心的是未来IT蓝图设计阶段。项目组将在理解了用户的业务战略、业务现状、IT现状以及已有的IT项目计划的基础上，充分运用对行业的业务发展趋势以及技术发展趋势的深刻理解，参考国外机构在实施信息化过程中的各种先进经验，设计出未来的IT蓝图。 研究方法说明 项目启动 本阶段最重要的任务是通过与客户项目负责人的深入沟通，进一步明确并确定项目的工作范围，在此基础上制定出合理的项目计划。同时，与客户双方均需尽快为项目配备相应的资源。

产品架构设计

产品的架构分为五个层面： ?战略层 ?范围层 ?结构层 ?框架层 ?表现层 这五个层面，每一个层面都由它下面的那个层面来决定。从战略层到表现层，也就是从抽象到具体的过程。这五个层面并不是独立开来的，也就是说并不是要完全做好“底下一层”才能做“上面一层”，而是让每一层面的工作在下一层面可以结束之前完成。如下图所示：

在每一个层面我们都会根据竞争对手的情况和在业内已经过用户检验并得到良好结果的方面，做出符合我们自身情况的决策。（这里就是大家常常所说的“竞品分析”和“不重复发明轮子”，其中重点是你要真正的看”懂“竞品，找出优质并符合自身的轮子）。在每一个层面我们都会根据竞争对手的情况和在业内已经过用户检验并得到良好结果的方面，做出符合我们自身情况的决策。（这里就是大家常常所说的“竞品分析”和“不重复发明轮子”，其中重点是你要真正的看”懂“竞品，找出优质并符合自身的轮子）。 此外，早期的互联网产品基本都是信息型的产品，而随着互联网技术的告诉发展以及人们对互联网产品的需求越来越广，越来越高。互联网产品加入了越来越多的功能，这就有了我们平常所说的功能型产品。但是目前大多数互联网产品都不是处于信息型或功能型单一的方面，而是”混合型“的产品。（你能说新闻类产品就是单纯的信息型产品吗？或者你能说搜索引擎产品就是简单的功能型产品吗？） 但是，我们在做产品讨论、沟通或决策的时候。我们会发现有人从内容需求、信息架构、导航设计这条线去讨论，而有些人会以功能规格、交互设计、界面设计这条思路去阐述。这样往往将这两个方面混在一起讨论，从而产生模棱两可的结果，谁也说服不了谁。其实原因就是你们说的不在一个维度上，自然谁也无法说服谁。所以我们姑且将两个分开讨论。也就是下图的分布：

ADMEMS软件架构设计方法设计方案

ADMEMS软件架构设计方法设计方案方法体系 作为方法体系，ADMEMS方法通过3个阶段和1个贯穿环节，来覆盖“需求进，架构出”的架构设计完整工作容。其中“3个阶段”是指预备架构阶段（PA阶段）、概念架构阶段（CA阶段）、细化架构阶段（RA阶段），“1个贯穿环节”是指对非功能目标的考虑。 PA阶段的任务是全面理解需求，从而把握需求特点，进而确定架构设计驱动力。其中，ADMEMS矩阵居于方法的核心；CA阶段必须考虑包括功能、质量、约束在的所有方面的需求，ADMEMS方法有自己的概念架构设计步骤和做法；RA阶段的总体方法为5视图方法，涉及逻辑架构、物理架构、开发架构、运行架构和数据架构。 文档模板（下载全套模板） ADMEMS方法为软件架构设计提供了整套文档模板，涉及文档简介、架构描述方式、架构设计目标、

架构设计原则、逻辑架构视图、开发架构视图、运行架构视图、物理架构视图、数据架构视图、关键质量属性的设计。在架构设计实践中，架构师可以直接使用这套文档模板来设计架构，以及对架构进行描述。

前辈推荐 晋兴（中航集团公司631研究所研究员，前系统软件室主任）：ADMEMS是当前软件架构设计领域先进的方法体系，在论述架构设计不同阶段的分析方法与设计技术的同时，给出了相应的实践策略、实践套路及有用的设计案例。本方法具有极强的实用性，不但是一线架构师及希望成为软件架构师者的福音，对我国软件业界在软件架构相关方面的研究工作也有一定的推动作用。 周伯生（北航计算机学院教授、博士生导师，美国SDPS学会院士）：ADMEMS架构设计方法学既是提出者亲身的实践总结，又概括了业界的有效实践；不仅生动地反映提出者的创造性思维和对学术的刻苦耕耘，又反映出提出者对架构学的崇高历史责任感；不仅对架构师们有很好的参考价值，而且对推动架构学界的深入研究具有重要意义。 黄绍良（清华大学创新研究会成员，南开大学软件学院教授）：软件工程的架构师犹如建造工程的建筑师一样，一些建筑师能够最终成为“大师”，主要是他们的建筑设计除了能够满足应用需求外，还能结合周边环境，拥有独特的组合理念和创意。把握软件的架构设计技巧和方法，才能够带出软件创新的成果。ADMEMS为从业人员理解如何才能够客观地为客户设计高效和优质的计算机软件，是成为真正软件工程师的第一步，是未来软件大师的实践指南。

产品架构设计

产品的架构分为五个层面：?战略层 ?范围层 ?结构层 ?框架层 ?表现层 这五个层面，每一个层面都由它下面的那个层面来决定。从战略层到表现层，也就是从抽象到具体的过程。这五个层面并不是独立开来的，也就是说并不是要完全做好“底下一层”才能做“上面一层”，而是让每一层面的工作在下一层面可以结束之前完成。如下图所示： 在每一个层面我们都会根据竞争对手的情况和在业内已经过用户检验并得到良好结果的方面，做出符合我们自身情况的决策。（这里就是大家常常所说的“竞品分析”和“不重复发明轮子”，其中重点是你要真正的看”懂“竞品，找出优质并符合自身的轮子）。在每一个层面我们都会根据竞争对手的情况和在业内已经过用户检验并得到良好结果的方面，做出符合我们自身情况的决策。（这里就是大家常常所说的“竞品分析”和“不重复发明轮子”，其中重点是你要真正的看”懂“竞品，找出优质并符合自身的轮子）。 此外，早期的互联网产品基本都是信息型的产品，而随着互联网技术的告诉发展以及人们对互联网产品的需求越来越广，越来越高。互联网产品加入了越来越多的功能，这就有了我们平常所说的功能型产品。但是目前大多数互联网产品都不是处于信息型或功能型单一的方面，而是”混合型“的产品。（你能说新闻类产

品就是单纯的信息型产品吗？或者你能说搜索引擎产品就是简单的功能型产品吗？） 但是，我们在做产品讨论、沟通或决策的时候。我们会发现有人从内容需求、信息架构、导航设计这条线去讨论，而有些人会以功能规格、交互设计、界面设计这条思路去阐述。这样往往将这两个方面混在一起讨论，从而产生模棱两可的结果，谁也说服不了谁。其实原因就是你们说的不在一个维度上，自然谁也无法说服谁。所以我们姑且将两个分开讨论。也就是下图的分布： 下面分别在这五个层面展开： 战略层： 这是最底的一层，这一层可以说展现了我们产品的灵魂。在这一次我们需要回答两个重要的问题： ?我们要通过这个产品得到什么？产品目标 ?我们的用户要通过这个产品得到什么？用户需求

产品架构设计

精心整理 产品的架构分为五个层面： ?战略层 ?范围层 ?结构层 ?框架层 ?表现层 这五个层面，每一个层面都由它下面的那个层面来决定。从战略层到表现层，也就是从抽象到具体的过程。这五个层面并不是独立开来的，也就是说并不是要完全做好“底下一层”才能做“上面一层”，而是让每一层面的工作在下一层面可以结束之前完成。如下图所示： 在每一个层面我们都会根据竞争对手的情况和在业内已经过用户检验并得到良好结果的方面，做出符合我们自身情况的决策。（这里就是大家常常所说的“竞品分析”和“不重复发明轮子”，其中重点是你要真正的看”懂“竞品，找出优质并符合自身的轮子）。在每一个层面我们都会根据竞争 （这里就是大家常常所说的“竞品分析”和“不重复发明轮子”，其中重点是你要真正的看”懂“竞品，找出优质并符合自身的轮子）。 此外，早期的互联网产品基本都是信息型的产品，而随着互联网技术的告诉发展以及人们对互联网产品的需求越来越广，越来越高。互联网产品加入了越来越多的功能，这就有了我们平常所说的功能型产品。但是目前大多数互联网产品都不是处于信息型或功能型单一的方面，而是”混合型“的产品。（你能说新闻类产品就是单纯的信息型产品吗？或者你能说搜索引擎产品就是简单的功能型产品吗？） 但是，我们在做产品讨论、沟通或决策的时候。我们会发现有人从内容需求、信息架构、导航设计这条线去讨论，而有些人会以功能规格、交互设计、界面设计这条思路去阐述。这样往往将这两个

方面混在一起讨论，从而产生模棱两可的结果，谁也说服不了谁。其实原因就是你们说的不在一个维度上，自然谁也无法说服谁。所以我们姑且将两个分开讨论。也就是下图的分布： 下面分别在这五个层面展开： 战略层： 这是最底的一层，这一层可以说展现了我们产品的灵魂。在这一次我们需要回答两个重要的问题：我们要通过这个产品得到什么？产品目标 ?我们的用户要通过这个产品得到什么？用户需求 这两个问题必须在范围层结束之前解决，不然你的产品从开始就已经偏离了主线，我想这个产品离着失败也就不远了。 在这一层，我提供一个方法论： 可以从四个方向去想产品： ?第一点：蓝海市场，我们发现了强需求（占先机） ?第二点：红海市场，我们有天然的优势（占天赋） ?第三点：蓝海市场+当前弱需求（超前占位） ?第四点：红海市场+自身无优势（被迫阻击） 如果做前两点的产品，可以说是幸运的，也是相对容易做出成绩的，这里你的天赋可以说是技术、平台等等。如果是蓝海市场而且目前是弱需求，可以这么说这个产品超前了，但不是说天马行空，

设计方法论

设计方法论 设计方法论顾名思义是当设计师在进行设计活动时可从理论和方法上所提出的实际性意见。当进行不同设计需求时，可为设计师提供明确的步骤与框架。众所周知设计方案要做到有理有据，富有说服力，所以设计方法论也是设计师进行产品设计时的一大利器。虽然会使创新上有所限制，但却能为设计师在没有灵感时候，提供一个有依据的可重复操作流程，进行自己的设计思考，从而输出自己的设计方案。其实资深设计师基本都会形成一套自己的设计方法论。尤其在常常需要进行汇报提案时，这更是方案汇报时的重要方法。 由于设计的细分领域宽广，每个领域都有多个研究者提出的多种设计方法论，所以并非所有的设计方法论，都适用于你当前的设计项目。这里只是收集了部分较为重点的设计方法论与大家分享。 设计框架与流程型 01 用户体验五要素 用户体验五要素框架的是由Jesse James Garrett在《用户体验要素——以用户为中心的产品设计》（中文书名）中提出。这个模型大概是

我们在学校学习交互设计课程之初，老师最先教的基本模型了。整个框架分为5层，由下往上是一个产品产生的顺序，也是我们职能沟通从产品经理到交互设计再到视觉设计的一个过程。 战略层：它可以帮助产品设计者更清晰的思考自己的产品定位是什么？能带给用户什么？可以针对用户细分，创建persona。 范围层：功能及其内容需求的整合需要做哪些？挖掘用户实际想要的特性，输出功能规格说明书，探讨需求可行性以及优先级。 结构层：关注用户行为与系统响应，选择合适的交互组建。 框架层：界面线框图设计，传达出一眼看到的最重要东西，不同内容间的关系。 表现层：有效传达信息与统一风格，不需要太多细节来吓到用户。

系统架构设计师(高级)复习精华

系统架构:系统架构师是怎样炼成的 坦率的讲，除了少数对开发程序极其热爱并愿意为之奋斗终身的编程者来说，对于大多数开发人员，写代码只是他们未来获得职业提升的一个必不可少的积累阶段，在做开发的时间里，他们会积极学习各种知识，经验，培养自己的商业头脑，包括扩展自己各方面的资源，这些积累会为他们未来成为管理者或创业打下牢固的基础。 成为架构设计师是广大开发者职业发展道路之一，架构师究竟是个什么样的职业？需要具备什么基本能力？如何才能成为一个优秀的架构设计师以及架构设计师需要关注哪些内容？针对有关问题，本期我们为您采访了(微软认证专家，系统分析员，希赛顾问团顾问，中国计算机学会会员) 张友邦，他会就相关问题与大家分享他的看法。 “在我工作的六年多时间里，除了第一年是纯粹编码以外，其余时间都在做和架构设计有关的工作，当然也还一直在写各种各样的代码。”张友邦认为架构设计可能看起来很神秘，新入门或没有架构设计经验的程序员刚开始的时候会有种不知所措的感觉，但其实架构设计是件很容易的事，它只是软件系统开发中的一个环节而已，整个软件系统的开发和维护以及变更还涉及到很多事情，包括技术、团队、沟通、市场、环境等等。 同时，张友邦表示，虽然架构设计是件容易的事情，但也不是大多数没有架构设计经验的程序员想象中的画画框图那么简单。把几台服务器一摆，每一台服务器运行什么软件分配好，然后用网络连接起来，似乎每个企业级应用都是如此简间单单的几步。但现实生活中的软件系统实实在在可以用复杂大系统来形容，从规划、开发、维护和变更涉及到许许多多的人和事。架构设计就是要在规划阶段都把后面的事情尽量把握进来，要为稳定性努力，还要为可维护性、扩扩展性以及诸多的性能指标而思前想后。除了技术上的考虑，还要考虑人的因素，包括人员的组织、软件过程的组织、团队的协作和沟通等。 另外，架构设计还需要方法论的指导。张友邦强调，这些方法论的思路包括，至上而下的分析，关注点分离，横向/纵向模块划分等。有时候觉得架构设计决策就像是浏览Google Earth，实际上反映的是一种自上而下的决策过程。对问题的分解是软件思维的基本素质，可以有横向分解、纵向分解以及两者的结合。能不能有效快速准确的分解问题，是软件开发人员需要首先训练的项目。另外，架构设计中图形化的工具非常有用，它能把系统的结构和运作机制以图形化的方式表达出来。也正因为这样才有了架构设计就是画框图的误会。再者，架构设计是一个工程性质的工作，对当事人的实际从业经验要求较高。只有对市场上的各种技术有较全面的了解之后才有可能设计出一个尽可能满足各种设计约束的架构。 在谈到架构师需要具备的能力上，张友邦认为架构师首先必须具有丰富的开发经验，是个技术主管。因为他必须清楚什么是可以实现的，实现的方式有哪些，相应的难度怎么样，实现出来的系统面对需求变化的适应性等一系列指标。另外，需要对面向过程、面向对象、面向服务等设计理念有深刻的理解，可以快速的察觉出实现中的问题并提出相应的改进(重构)方案(也就是通常说的反模式)。这些都需要长期的开发实践才能真正的体会到，单从书本

流程管理体系建设与流程架构设计

流程管理体系建设与流程架构设计 【时间地点】年月日北京 年月日上海 年月日深圳 年月日上海 年月日北京 年月日上海 年月日北京 年月日上海 【培训讲师】刘新华 【费用】￥元人（含天的学费、资料费、会务费等）外地学员可以代办住宿，费用需自理 【会务组织】森涛培训网（）．广州三策企业管理咨询有限公司 【咨询电话】；（提前报名可享受更多优惠） 【值班手机】 【在线】 【温馨提示】本课程可引进到企业内部培训，欢迎来电预约！ 【课程网址】 问题： 一、为什么我们做了一轮又一轮流程，但是效果不好呢？ 二、为什么我们设计一套又一套制度和标准，但是总是束之高阁呢？ 三、为什么我们实施各类管理体系时更关注设计和优化，总是忽视落地执行呢？ 四、为什么我们总是抱着多年前开创的职能管理模式不放手呢？ 五、为什么我们的变革一轮比一轮更难有效呢? 。。。。。。 很多企业总是一成不变的用职能管理思想开展流程管理，导致一轮又一轮的流程管理项目成效差，甚至失败，因为他们（也有一些中国咨询公司都是这个理念）注重的是流程设计（画流程图）或优化，而忽视了如何使流程真正有效的落地！ 《流程管理体系建设与流程架构设计》 ——带您跨入世纪：流程型组织时代 “流程是组织最重要资产和核心竞争力， 却往往是被企业忽略或无法有效管理的部分， 然而它对战略执行结果具有决定性的影响！ 流程管理的精髓是：提升组织的整体绩效和竞争力！” 一、【背景】 实现卓越绩效是所有组织的共同追求。面对世纪激烈的竞争环境，如何提升组织竞争力和生存能力是共同的挑战。目前管理思想和方法层出不穷：质量管理、风险管理、战略管理、精益管理、合规内控、卓越绩效管理……但无论什么管理，都只是手段，是药方，而组织的核心价值链、业务流程架构以及核心流程的清晰化和不断完善才是根本，流程管理是所有其他管理的基石！ 如何建设流程管理体系是一个困扰很多企业的难题，很多组织都是临时性的邀请咨询公司来解决这个问题，但是流程管理体系建设是一项永续开展的工作，需要靠自身才能达到目标，目前，各类组织都认识到了流程管理的重要性，但是却缺乏专业人才，导致很多组织实施困难或失败。这套系统化、国际领先的流程管理理念、方法和工具，已广泛的应用在国际知名企业，如：丰田、雀巢、可口可乐、戴尔、飞利浦、西门子、索尼、摩根银行、巴克莱银行等国际知名企业，国内企业包括海尔、中国移动、中石油、中石化、建设银行等国内知名企业。 二、【课程特色】 ◇互动——实际操练，体验（流程设计、指标设计、流程架构设计等）；

应用架构设计原则

软件系统架构设计原则就是把我们在各种场景下的架构设计进行抽选化提取公共特征形成过一定的方法论，这些方法论是经过严格推敲并具备移植性的，我们在设计系统时遵从这些设计规则可以为我们的体统提供更高的扩展性、稳定性。 1、抽象原则 各平台(含基础设施、中间件技术服务、各层业务服务等)需要通过合理地抽象，将内部信息、处理与扩展能力聚合成标准的服务于扩展接口，并通过统一的形式提供给使用者，屏蔽内部的实现与运行细节。 以下是一些符合抽象原则的架构规范或模式：架构分层(layer)/级(tier)，层、级间提供标准服务与数据接口根据业务模型，统一服务标准与数据标准使用服务目录屏蔽服务位置等实现细节使用“逻辑库”屏蔽数据库物理细节通过SLA，标准化服务的质量水平提供标准插件架构支持扩展使用标准数据库特性，保持厂商无关性使用逻辑的网络与系统名称使用商品化硬件单元。 2、共享原则 最大化重用数据、计算资源、业务组件等资产，防止数据、逻辑与技术实现不一致性带来的管理复杂性，避免重复建设成本与管理成本，通过安全机制保证共享资产的合法使用，通过业务分级保障共享资源效益最大化。以下是一些符合共享原则的架构规范或模式：同一业务服务有唯一提供者

同一技术服务有唯一提供者 同一数据有唯一可信源 控制技术多样性(但需要同时防止厂商绑定) 服务具备互操作性 服务具备易用性 统一的身份、访问控制与加解密机制 为共享服务提供多租户能力(Multi-tenancy) 提供访问计量与控制能力 提供业务分级能力，对不同级别的业务提供区分服务 3、自治原则 每一个组件(计算资源、业务组件、信息实体等)具备最大可能的自我完备性，可独立运行、监控、部署、配置与禁用，具备确定的SLA，并与其它组件之间以松散耦合的方式进行协作。当依赖的组件不存在或者无法正常提供服务时，能够以良好的方式降级，且在故障解除后自动恢复。以下是一些符合自治原则的架构规范或模式： 基于开-闭原则(OCP)设计组件 应用无启动依赖