HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性非功能性关键约束)-上篇

Posted 2021-01-07 hegezhou_hot

一、开篇

      上一篇《HRMS(人力资源管理系统)-从单机应用到SaaS应用-系统介绍》我们已经详细的分析了HRMS系统具备的功能，并且从HRMS系统的概念、系统功能、HR行业管理现状及痛点、发展趋势及行业前景、行业内的服务提供商情况、HRMS系统的建设意义及价值等方面进行了系统化的分析梳理。我想大家已经对于HRMS系统的大体情况有了初步的了解，本篇将对HRMS系统的需求进行全方位的梳理（功能性需求、非功能性需求、系统约束等），这对于HRMS系统的架构设计来说是核心关键，是架构能否成功的前提。这也是衡量一个架构师是否称职合格的关键。

       本篇主要想通过HRMS系统与大家分享下架构设计环节中非常重要的基础环节-架构准备-的关键工作内容，请大家务必该环节的工作内容，这是所有成功架构设计的前提，为能够系统的阐述清晰该领域的注意事项及工作方法，所以篇幅会较长，请大家细细看完，如果有阐述不清晰或遗漏的地方，还请大家指出。

      在阐述具体的架构工作方法之前，请大家先查看以下三方面的内容：

     1、HRMS系统的介绍？（涵盖哪些功能？价值和作用是什么？行业什么情况？）

      请阅读《HRMS(人力资源管理系统)-从单机应用到SaaS应用-系统介绍》

      2、本章分析的内容将围绕4类企业代表的业务场景，（区分不同规模企业的关注点，规模将决定系统的设计方案）

      本篇将围绕4类企业代表来阐述不同规模企业对于HRMS的需求及应用

•       A、100人以下的中小企业
•       B、500人以下的大中型企业
•       C、1000人以上的集团化大企业
•       D、全球类型的公司体系（几万人）

      3、架构师在设计该系统时的职责及具备的核心能力是什么？

      请阅读《系统架构系列-开篇介绍》

 

二、为什么很多系统架构的设计会失败？

       在这10多年的工作经验中见过也参与了不少失败的架构项目，基本上总结下来发现了有很多种原因可能导致架构设计失败，所以说一个系统的架构设计是一个系统化的工程，不是只进行模块设计或功能设计那么简单，需要不断学习和积累经验，站在巨人的肩膀上思考问题，让我们少走弯路。成功和失败的经验都值得我们去总结和思考，那么基于之前总结的内容，我梳理完可以归纳为以下几个方面：

A、架构师不懂需求

B、非功能需求、关键约束、关键功能等没有找到

C、缺少关键实践及方法论

D、未能验证架构的可行性并作出调整

2.1、架构师不懂需求

       技术是为业务服务的，请每一位架构师或系统的设计者谨记该理念，不知道大家有没有总结过目前出现的各类技术的特点，我发现每一次的技术更迭就是为了解决前一主流技术存在的不足或某些领域的缺陷而产生的，所以，我们在选择一项技术或选型时，需要结合业务的实际情况灵活选择，一定要选择最好、最优的，考虑未来的变化、不确定、扩展性等非功能性需求。让我们的架构设计有一定的扩展性及健壮性。架构也是持续迭代的（请大家有空网上看看阿里巴巴、腾讯、百度、京东等互联网公司的架构迭代过程），非一蹴而就的。

2.2、遗漏或未找到非功能需求、关键约束、关键功能等

       在系统架构设计的过程中最害怕的就是遗漏关键功能或非功能性需求、系统约束等方面没有考虑，这将直接导致架构失败，前面做的所有的准备工作基本上都是白费了，往往在架构设计的过程中一个点就会导致整体失败，我们必须找到关键需求。这将需要一整套的方法论，我们往往在分析功能、非功能性需求、系统约束时缺乏方法论和梳理思路，这将会让我们陷入一系列的迷茫中，就会出现抓不住重点内容。具体某个需求在不同的行业领域、不同的用户场景等往往重要性可能不同，这就需要架构师必须进行充分的调研梳理。

2.3、缺少关键实践及方法论

       我们在实际的架构工作中往往不去学习和参考前人总结的工作经验，这样是阻碍个人成长和进步的，我认为99%的场景下我们遇到的问题前人都遇到了，只是我们没有遇到对的人，只要我们找到对的人，只要这个人肯分享，一定会帮助我们解决我们遇到的问题的，再举个例子，如果我们做互联网，那么技术问题可以试想下，我们遇到的问题我想（BAT）都遇到了，所以我们为啥不站在前人的肩膀上去思考问题呢？这让我们能够有更多的时间去总结和思考解决问题的方式，全面提升我们自身的能力。

       另外，千万不要认为自己设计的架构方案就是最好的，要不断的质疑架构的合理性及最优性，经得起大家的质疑及实际的考验，并且为确保架构的有效落地，需要持续的跟踪确认，确保方向不会出现偏差。

2.4、未验证架构的可行性并作出调整

       整体的架构方案并没有进行充分的评审及实践验真，俗话说实践是检验真理的唯一标准，这需要架构师在架构设计完成后准备各视图场景下的验证方案，确保整体架构的可行性，一旦在过程中发现遗漏及风险及时干预并调整架构设计方案，如果已经进入到开发阶段，需要制定平滑的设计方案，尽可能的规避工作量损失并保证系统功能的全面支撑。

另总结了一些软件架构设计过程中存在的误区

●高开高走落不到实处

● 理想与现实需要折中

● 遗漏关键性约束与非功能需求

● 为虚无的未来埋单而过度设计

● 过早做出关键性决策

● 客户说啥就是啥成为传话筒

● 埋头干活儿缺乏前瞻性

● 架构设计还要考虑系统可测性

● 架构设计不要企图一步到位

 

三、架构设计成功的关键方法

3.1、EA架构方法论体系

       对于企业或提供行业的产品及服务时，我们需要一整套的系统化思维去思考和设计业务流程。特别是业务越来越复杂及业务范围越来越广时，这就需要我们有一整套的方法论去指导我们去设计及规划系统，一个大家都明白的共同语言来分析和解决问题，这个共同语言就是EA所提供的。EA的真正意义是告诉你怎样去思考，怎样去沟通，怎样去做决策，以及怎样去控制项目。EA保证不同层面的人看到一个更宏观的视图，从而避免“ 只见树木、不见森林”的无效工作。 EA是一个把战略、业务与IT进行有效匹配的方法论，从而使 IT真正为业务和战略服务，从而使战略能够有效执行。 EA就是现代企业的DNA，它是一个能够整合各种方法的机制 ，从而解决各种挑战和问题。

       上述图片中呈现了EA方法论的5类具体的实践，由于篇幅有限，我这里不挨个展开介绍概念及具体内容。如果想了解详情请大家自行搜索。

       可以说我们在做一个复杂系统的设计及规划时，正确的方法论会知道我们正确的做事，做正确的事，所以这对我们每个架构师来说非常重要，请大家务必了解，当然对于EA理论的具体实践也有很多具体的方法实践模式，这里也可以归纳为几类，后面我们将详细阐述。

 

3.2、ADMEMS（Architecture Design Method has been Extended to Method System）

       ADMEMS是Architecture Design Method has been Extended to Method System的简称，是由CSAI顾问团架构设计专家组于2009年11月在第六届中国软件大会上公开发布的一个软件架构设计方法。作为方法体系，ADMEMS通过3个阶段和1个贯穿环节，来覆盖“需求进，架构出”的架构设计完整工作内容。其中“3个阶段”是指预备架构阶段（PA阶段：把握需求特点，确定架构驱动力）、概念架构阶段（CA阶段：根据重大需求，确定概念架构）、细化架构阶段（RA阶段：细化架构设计，关注不同视图），“1个贯穿环节”是指对非功能目标的考虑。

       PA阶段的任务是全面理解需求，从而把握需求特点，进而确定架构设计驱动力。其中，ADMEMS矩阵居于方法的核心；CA阶段必须考虑包括功能、质量、约束在内的所有方面的需求，ADMEMS方法有自己的概念架构设计步骤和做法；RA阶段的总体方法为5视图方法，涉及逻辑架构、物理架构、开发架构、运行架构和数据架构。

       后面我们将主要参考该架构方法来落地实践HRMS系统的架构设计过程。

 

3.2、质疑驱动架构设计（始终抱着质疑的思想来思考架构设计方案）

架构师需始终保持质疑的意识来不断驱动整个架构设计的过程，这是一个架构设计成功的关键，通过质疑可引入更多的“质量属性”，同时结合“特殊功能场景”驱动后续架构设计，最终形成最优的架构设计方案。

以HRMS系统为例：

      上面我们发现在架构设计的过程中，我们需要从多维度去思考架构设计考虑的内容及方式，我们需要从不同的方向去考虑架构过程中出现的各类问题，通过质疑并不断解决质疑的方式来设计出最终的解决方案。我们的终极目标是设计出一套先进有持续竞争力的HRMS系统，满足各类企业在经营过程中对人力资源管理所需的各类需求（功能、质量属性、约束），架构师需要用挑毛病的方式来去评估当前的架构设计方案，直到挑不出毛病（架构师自己先质疑问题并解决了），这个架构基本就成型了。

 

3.3、多阶段/多视图

       业界软件架构设计的方法论很多，各有各自的应用场景和特点，下文结合ADMEMS（Architecture Design Method has been Extended to Method System）架构设计方法论说明软件架构的过程：

       架构设计的过程和内容的不是固定不变的，现实中，比如售前提供解决方案中，很多时候需要架构师提供细化架构中才会深思的逻辑架构、物理架构等，这时候，架构师就需要有螺旋思维和跳跃思维的方式，就像武功中，招式是死的，人是活的，要学会灵活运用。

       3.3.1、架构设计过程（3个阶段）

A、Pre-architecture阶段：架构实践中最常见的最短板

最大误区：架构师是技术人员，不必懂需求

实践要点：摒弃“需求列表”方式，建立二维需求观

思维工具：二维矩阵（需求层次-需求方面矩阵）

B、Conceptual Arch阶段：大型系统成败关键

最大误区：概念架构=理想设计

实践要点：重大需求塑造概念架构

思维工具：鲁棒图、目标-场景-决策表

C、Refined Arch阶段：团队大规模并行开发基础

最大误区：架构=模块 + 接口

实践要点：贴近实践的5视图法

思维工具：包图、包-接口图、灰盒包图、序列图、目标-场景-决策表

 

         3.3.2、架构设计5视图

         5视图法分析的意义：

         ● 全面分析软件系统方方面面的问题
         ● 尽早地发现和排除项目风险与不确定因素
         ● 从不同角度去展现要设计的软件系统
         ● 为项目进行中不同的干系人提供指导：
            -- 逻辑架构描述系统功能，并指导系统测试
            -- 开发架构规范软件的层次及代码风格
            -- 数据架构指导数据库的设计
            -- 运行架构定义了一些关键过程的设计
            -- 物理架构明确软件如何部署与实施

关于架构5视图的实践过程：

3.4、内置最佳实践(经验总结)

       在我们在做系统架构时，我们应该不断的学习、总结之前的经验，就像前面我们讲到的架构的方法论、架构模式一样，我们需要形成一套方法理论体系或者应用场景解决方案去指导我们在后续的系统架构。少走弯路、找到最优的架构解决方案。

      整体来说我们可以归纳在逻辑架构、业务建模、关键约束、非功能性需求（质量需求）等几方面的经验。

3.4.1、逻辑架构设计过程中的10条经验

1) 划分子系统：分层的细化

2) 划分子系统：分区的引入

3) 划分子系统：机制的提取

4) 接口的定义：协作决定接口

5) 选用序列图：杜绝协作图

6) 包-接口图：从结构到待办的桥

7) 灰盒包图：描述关键子系统

8) 循序渐进的螺旋思维

9) 设计模式：包内结构

10) 设计模式：包间协作

       在实际的逻辑架构的设计过程中，上面的10条经验会非常有价值，我们仅需参考上面的原则来设计系统的逻辑架构，基本上架构成功的几率很大。再结合其他的4个架构视图即可得到最优的系统架构。

3.4.2、基于鲁棒图进行初步设计的10条经验（业务建模）

       ADMEMS方法归纳了鲁棒图建模的10条经验要点,分别覆盖语法，思维，技巧，注意事项等4个方面，建议后续大家在做具体的系统架构时可参考10条设计经验，少走弯路：

鲁棒图建模的10条经验:

1.遵守建模规则。

    通过以下4条语句，可以理解该图的本质：

         1.1 参与者只能与边界对象交谈。

         1.2 边界对象只能与控制对象和参与者交谈。

         1.3 实体对象也只能与控制对象交谈。

         1.4 控制对象既能与边界对象交谈，也能与控制对象交谈，但不能与参与者交谈。

2.简化建模语法

      ADMEMS方法推荐鲁棒图建模的语法。在实践中，简化的鲁棒图语法将有利于集中精力进行初步设计，而不是关注细节。

3.遵循3种元素的发现思路

用例=N个场景。每个场景的实现都是一连串的职责进行协作的结果。所以，初步设计可以通过”研究用例执行的不同场景，发现场景背后应该有哪些不同的职责“

4.增量建模

         首先，识别最明显的职责。对，就是你自己认为最明显的那几个职责--不要认为设计和建模有严格的标准答案。

接下来，开始考虑职责间的关系，并发现新职责。继续同样的思维方式。

5.只对关键功能（用例）画鲁棒图

    基于”关键需求决定架构“的理念，功能需求作为需求的一种类型，在设计架构时不必针对每个功能都画出鲁棒图。

6.每个鲁棒图有2-5个控制对象

     既然是 初步设计，鲁棒图建模时，针对关键功能的每个鲁棒图中得控制对象不必太多太细，5个是常见的上限值。相反，若实现某功能的鲁棒图中只含一个控制对象，则是明显地”设计不足“--这个控制对象的名字必然和功能的名字相同，这意味着没有对职责进行真正的切分。

7.勿关注细节：

     初步设计不应该关注细节。例如，

     1.对每个对象只标识对象名，都未识别其属性和方法。

      2.”活期账户销户界面“，具体可能是对话框，WEB界面，字符终端界面,但鲁棒图中没有关心这些细节问题。

      3.”客户资料“ 等实体对象须要持久化吗？不关心，更不关心用Table还是用File或其他方式持久化。

      4.没有标识控制流的严格顺序。

8.勿过分关注UI，除非辅助或验证UI设计。

    过分关心UI，会陷入诸如有几个窗口，是不是有一个专门的结果显示页面等诸多细节之中，初步设计就没法做了。

   别忘记了，初步设计的目标是发现职责。初步设计无须展开架构设计细节，否则就背上了”包袱“，这是复杂系统架构设计起步时的大忌

3.4.3、约束的4大类型--转化成图片

A、业务环境的约束（客户或出资方）

上线时间？预算限制？集成需求？

业务领域？业务规则或业务限制？

法律法规或专利的限制？

更多……

B、使用环境的约束（系统用户）

何阶层用户？年龄段和偏好？多个国家？

是否存在网络较弱或延迟情况？设备移动的情况下？

更多……

C、构建环境的约束（开发者和维护人员）

技术水平，城市分布，磨合程度？

开发管理程度？源代码保密？网络环境？

更多……

D、技术环境的约束（技术选型）

技术平台、中间件、编程语言的流行度，认同度，优缺点？

技术发展趋势？

更多……

 

3.5、非功能及约束贯穿整个设计过程

       我们知道在系统架构设计的过程中，不能仅仅考虑功能实现，还需要持续考虑非功能性需求（质量）及约束内容，往往这些是系统架构成功的关键点，某些时候我们往往因为忽略或遗漏这些内容而导致架构失败。

       如何设计才能使这个系统高性能呢？场景思维是关键。也就是说，我们要明确系统所处于的哪些真实具体的场景，对高性能这个大的笼统的目标最有意义：

        我们可以采取-“目标-场景-决策”表来辅助我们系统化的梳理非功能性需求内容：

         

         由此可见，通过"目标-场景-决策表"既可以帮助我们引入新的设计（例如表中决策"html静态化"），也可以帮助我们改进之前架构设计存在的问题及痛点，还可以再分析的过程中帮我们找到关键非功能需求，所以在后续的架构设计过程中我们需要善用该表。

 

四、HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-下篇（目录大纲）

一、架构分析阶段主要做什么？

1、分析业务需求和约束背后的衍生需求

2、发现遗漏需求

3、确定关键功能

4、确定关键质量

5、确定关键约束

二、如何找出关键的功能性、非功能性需求、关键约束？

1、功能需求影响架构的基本原理：职责协作链

2、质量需求影响架构的基本原理：进一步质疑

3、分析约束影响架构的基本原理：直接制约、转化为功能或质量需求

4、?第1步：需求结构化；?第2步：分析约束影响；?第3步：确定关键质量；?第4步：确定关键功能

三、HRMS系统的关键功能、关键质量指标及约束

1、结合Amazon的案例来梳理，最后得出结论？

2、确定关键功能

3、确定关键质量指标

4、确定关键约束

四、架构分析阶段总结

1、架构师分析系统的第一步是什么？

2、找出关键点是二维表？

3、如何提升分析能力是关键（实践出真知）？

4、知识提升（除了BAT及大的互联网公司可能会遇到技术瓶颈，我们现在基本上遇到的问题，大家都遇到了）

5、过犹不及（不要过度设计，能解决业务问题就是最好的，不要镜中花、水中月）

 

五、更多信息

关于更多的系统架构方面的知识，我已建立了交流群，相关资料会第一时间在群里分享，欢迎大家入群互相学习交流：

微信群：（扫码入群-名额有限）