设为首页 加入收藏

TOP

HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-上篇(一)
2019-09-17 17:45:52 】 浏览:78
Tags:HRMS 人力资源 管理系统 单机 用到 SaaS 应用 架构 分析 功能性 关键 约束 -上篇

一、开篇

      上一篇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、架构师不懂需求

image

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

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

image

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

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

image

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

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

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

image

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

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

●高开高走落不到实处

● 理想与现实需要折中

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

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

● 过早做出关键性决策

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

● 埋头干活儿缺乏前瞻性

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

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

 

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

3.1、EA架构方法论体系

image

       对于企业或提供行业的产品及服务时,我们需要一整套的系统化思维去思考和设计业务流程。特别是业务越来越复杂及业务范围越来越广时,这就需要我们有一整套的方法论去指导我们去设计及规划系统,一个大家都明白的共同语言来分析和解决问题,这个共同语言就是EA所提供的。

首页 上一页 1 2 3 4 下一页 尾页 1/4/4
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇支付宝系统架构内部剖析 下一篇老王讲架构:负载均衡

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目