HRMS (Human Resource management System)-saas Architecture Design-Overview Design Practice

1. Opening
      In the early stage, we wrote 2 articles for the architecture preparation stage and demand analysis. "HRMS (Human Resource Management System)-From stand-alone application to SaaS application-Architecture analysis (functional, non-functional, key constraints)-Part 1" "HRMS (Human Resource Management System)-From Stand-Alone Application to SaaS Application-Architecture Analysis (Functionality, Non-Functionality, Key Constraint)-Part Two" to expand on the content.

       This article will explain in detail the main points of the outline architecture design during the architecture design process to communicate with you, and learn how to strengthen the role of the outline architecture design in the architecture design in the future, and help us quickly confirm the direction of the architecture and the core framework.

      Before explaining the specific outline architecture working method, please refer to our limited business scenarios:

     1. What is the introduction of the HRMS system? (Which functions are covered? What is the value and role? What is the industry situation?)

      Please read "HRMS (Human Resource Management System)-From Stand-alone Application to SaaS Application-System Introduction"

      2. The content of the analysis in this chapter will focus on the business scenarios represented by the 4 types of enterprises, (differentiate the concerns of enterprises of different sizes, and the scale will determine the design of the system)

      This article will focus on the representatives of 4 types of enterprises to explain the needs and applications of HRMS for enterprises of different sizes

      A. Small and medium-sized enterprises with less than 100 employees
      B. Large and medium-sized enterprises with less than 500 employees
      C. Large conglomerate enterprises with more than 1,000 employees
      D. Global company system (tens of thousands)
      3. What are the responsibilities and core capabilities of the architect when designing the system?

      Please read "System Architecture Series-Introduction"

 

1. About the outline architecture stage
 

1.1. Definition of outline architecture
       Conceptual architecture is the initial idea of system design, which is to determine the most critical design elements and interaction mechanisms of the system, and then consider specific technical applications to design the actual architecture. The conceptual architecture stage focuses on the overall situation, does not stick to the trivial, and does not pay too much attention to the details of the design and implementation.

       Features of the outline architecture stage:

Satisfy the basic definition of "architecture = component + interaction" (all architectures cannot escape this mode)

Define the "responsibility" of high-level components in general, and give the relationship between high-level components

Interface details should not be involved

Before talking about the specific outline architecture design practice, please think about the following questions:

Why are the architectures of different systems different?

In architecture design, when should the general direction of the architecture be different? (Function, quality, constraint

 

1.2. Current status of the industry 1.2.1. Incorrectly equating the "summary structure" with the "ideal structure"
Architecture design is driven by functional requirements, right?

Architecture design is driven by use cases, right?

In fact, the driving force of architecture design: function + quality + constraints

1.2.2, mistakenly regard "phase" as "view"
Summary architecture stage or conceptual view?

The stage reflects the sequence relationship, and the view reflects the parallel relationship

In the outline architecture stage, stable high-level architecture design results are formed according to major needs, special needs, and high-risk requirements

 

1.3. Main work content and objectives
       Conceptual architecture is an architecture design stage. It must be prior to the detailed architecture design stage, aiming at major requirements, characteristic requirements, high-risk requirements, and documented high-level architecture design results.

       Major requirements shape the conceptual architecture. The major requirements here cover the key content of the three types of requirements such as function, quality, and constraints.

       If you only consider the functional requirements to design the conceptual architecture, the conceptual architecture will be reduced to an "idealized architecture". This fragile architecture will soon face the pressure of "major changes", and even directly lead to the failure of the project.

 

2. What is the method and scientific practice process of the outline structure stage?
 

The whole can be divided into 3 stages:

1. Through the robust graph: the goal of the preliminary design is to discover responsibilities, and draw the robust graph using the principle of "responsibility collaboration chain"

2. High-level segmentation: Use mature experience and methodology to select the appropriate architecture model in combination with the scene to determine the hierarchical relationship of the system

3. Question-driven: consider non-functional requirements to continuously drive the outline architecture design process.

2.1. The goal of the preliminary design is to discover responsibilities and draw robust graphs using the principle of "responsibility collaboration chain"
Three objects of robust graphs:

? Boundary objects model the interaction between the simulated external environment and the future system. Boundary objects are responsible for receiving external input, processing internal content interpretation, and expressing or transmitting corresponding results.

? The control object encapsulates the behavior and describes the control behavior of the event flow in the use case.

? Entity objects describe information. It often comes from domain concepts and has a good corresponding relationship with the objects in the domain model.

Preliminary design principles
? The goal of the preliminary design is to "discover responsibilities" and lay the foundation for high-level segmentation

? Preliminary design is "not" necessary, but when the "system to be designed" does not have much direct experience for the architect, preliminary design is strongly recommended

? Based on key functions (rather than for all functions), with the help of robust diagrams (rather than sequence diagrams, sequence diagrams are too detailed) for preliminary design

       For the difference between these objects, please refer to "HRMS (Human Resource Management System)-From Stand-alone Application to SaaS Application-Architecture Analysis (Functionality, Non-Functionality, Key Constraint)-Part 1" for a description of the robust graph Basic usage instructions. Subsequent articles will be used directly and will not repeat the specific usage.

       After reading the robust graph, you find that the robust graph also has entities, controls, and boundary objects. How can it be so similar to the MVC pattern used in the web system, then let's compare the similarities and differences between these two patterns:

       Through the above comparison, we find that the robust graph can more comprehensively reflect the content involved in the architecture design process, and the separate architecture mode focuses more on some of the architecture levels, such as the logical architecture adopts the MVC mode.

2.2. High-level segmentation (the specific method of operation for the formation of the conceptual framework)
1), direct layering

2), first divided into subsystems, and then stratified for each subsystem

For high-level segmentation, we can adopt a staged model to implement the landing practice:

1. Directly divide the level: directly divide the system into multiple levels, sort out the relationship between each level

2. Divided into two stages: first divide into multiple subsystems, and then sort out the hierarchy of the subsystems, sort out the hierarchical relationship without grid systems

In view of the introduction of hierarchical mode, here are several types of division modes and methods:

1. Logical layer: logical layer, the upper layer uses the concept of the lower layer; it does not pay attention to physical division or generality

2. Physical layer: distributed on different machines

3. Layering of versatility: the more versatility, the lower the level

 

2.2.1, Layer: logical layer
Layer: The logical layer, the upper layer uses the concept of the lower layer; it does not care about physical division or generality. Layer is a form of logically organizing code. For example, in the logical layering, the presentation layer, service layer, business layer, and domain layer are divided by software functions. It does not refer to the specific server or physical location.

        Multi-layer Layer architecture pattern

       Such as our common three-tier architecture model, the three-tier architecture in the usual sense is to divide the entire business application into: User Interface layer, Business Logic Layer, Data access layer. The purpose of distinguishing levels is for the idea of "high cohesion and low coupling". In the software architecture design, the layered structure is the most common and the most important structure. The hierarchical structure recommended by Microsoft is generally divided into three layers, from bottom to top: data access layer, business logic layer (also known as domain layer), and presentation layer.

The logical-level architecture can help us solve logical coupling and achieve flexible configuration and migration. A good logical layering can bring:

A, logical organization code / clarity of code logic

B. Easy to maintain (maintainability)

C. Better reuse of code (reusability)

D. Better team development experience (development process support)

 

2.2.2 Tier: physical layer Tier: physical layer, each layer is distributed and deployed on different machines, Tier refers to the specific location where the code runs and is deployed, and is a division on the physical level, Tier refers to the specific logical layer Operating location. Therefore, the logical layer can be deployed or migrated to different physical layers, and one physical layer can be deployed to run multiple logical layers.
       Tier refers to the location where the code runs. Multiple Layers can run on the same Tier, and different Layers can also run on different Tiers. Of course, the premise is that the application itself supports this architecture. Take the J2EE and .NET platforms as examples. Most of the time, different layers are directly invoked through DLL or JAR package references (for example, the business logic layer needs to reference the data access layer). When deploying this way, Only multiple Layers can be deployed on one server at the same time. On the contrary, if the communication calls between different Layers are implemented through RPC, during deployment, different Layers can be deployed on different servers. This is also a very common decoupling design.

A good physical architecture can bring:

A. Performance improvement

B. Scalability

C, fault tolerance

D. Security

2.2.3, versatility stratification Adopt versatility stratification mode, the principle is that the more versatility, the lower the level
And the calling relationship of each layer is top-down, the lower the higher the versatility.

2.3. Driven by doubts, constantly improve the system architecture (quality attributes and constraints determine the evolution of the architecture)
The high-level framework of the conceptual architecture is shaped based on the major functions in the system. In the process, the preliminary conceptual architecture needs to be continuously questioned through non-functional requirements such as quality and constraints, and the conceptual architecture is gradually improved to meet and support various quality and constraints. Claim. For the specific method of operation, we can take the "Target-Scenario-" introduced in the previous page "HRMS (Human Resource Management System)-From Stand-alone Application to SaaS Application-Architecture Analysis (Functionality, Non-Functionality, Key Constraint)-Part 1" Decision table" to achieve.

?Analyze non-functional requirements through "target-scenario-decision table":

By analyzing the key quality and constraint content, giving specific scenarios and coping strategies, sorting out a clear decision table, fusing the solutions given in the decision table in the conceptual architecture stage, and finally giving a preliminary conceptual architecture design.

 

3. The HRMS system based on the previous analysis? How do we get started?
Combining the main points of the requirements combing mentioned above, we combined with the HRMS system for application practice, and gradually formed the outline architecture design.

A. Draw a robust graph based on RelationRose, determine the boundary and key content of the system

1). Analyze the participants and application functional boundaries in the system:

Based on the above, we can find our core function points:

Organizational management: It mainly realizes the management of the company’s organizational structure and its changes; the management of position information and the working relationship between positions, staffing according to the vacancies of the positions; human planning according to the organizational structure, and calculation and management of personnel costs, Support the generation of organization chart, organization chart, etc.

Personnel files: It mainly realizes the management of all kinds of information in the entire process of employees from trial, conversion to dismissal or retirement, management of personnel information changes, and provides various forms and angles of inquiry and statistical analysis methods

Labor Contract: Provides management of the signing, modification, cancellation, renewal, labor disputes, and economic compensation of employees' labor contracts. Automatic reminder of trial period and contract expiration can be set according to needs

Recruitment management: realize the whole process management from planning recruitment positions, publishing recruitment information, collecting applicants' resumes, selecting personnel based on job qualifications, managing interview results, and notifying probation

Salary and welfare: Salary management system is suitable for all kinds of enterprises, administrations, institutions and scientific research units. It directly integrates data such as attendance and performance appraisal, and mainly provides functions such as salary accounting, salary distribution, expenditure calculation, and statistical analysis. Support for multiple or partial payment of wages; support withholding tax or payment of taxes; support for payment of wages on behalf of the bank, providing the output function of the agency data, and also support the payment of cash, and provide the function of payment list. The content and the rate of provision can be set; the welfare management system provides the extraction and management functions of various welfare funds for employees. It mainly includes defining fund types, setting the conditions for fund withdrawal, conducting daily fund management, and providing corresponding statistical analysis. Daily fund management includes regular fund withdrawal, fund repayment, transfer in and out, etc. In addition, it provides the function of submitting relevant reports to relevant management agencies

Administrative management: It mainly provides management of employees' attendance and helps enterprises improve their operating systems. It mainly includes the setting of various holidays, the setting of shifts, the setting of related attendance items, as well as the management of shifts, overtime, business trips, leave requests, statistics of late arrivals and early departures, statistics of attendance, etc. Provides interfaces with various attendance machine systems, and provides relevant data for the payroll management system. Support notification and announcement distribution, support conference room/vehicle and other resource reservation and synchronization calendar, support survey and voting questionnaire, support event management registration/sign-in/statistics, support personnel reward and punishment management and associate with personnel files, support event lottery management Wait

Training management: Determine the necessary training needs according to the job setting and performance appraisal results; formulate training plans for the career development of employees; manage training objectives, course content, teachers, time, location, equipment, budget, etc., and conduct training Management of personnel, training results, and training costs

Performance management: Through performance appraisal, the effects of staffing and training can be evaluated, rewards and punishments can be provided to employees, and the basis for personnel decision-making can be provided. According to the requirements of different positions in terms of knowledge, skills, abilities, performance, etc., the system provides a variety of assessment methods and standards, allows free setting of assessment items, and conducts qualitative and quantitative assessments on employee characteristics, behaviors, work results, etc.

Configuration management: In order to enhance the compatibility and flexibility of the system, a lot of system switches and configurations have been added to provide support to meet various scenarios in the future. Among them, there needs to be dynamic classification, dynamic addition, modification and other functions of configuration items

Authority management: universal authority management system, supporting organization, staff, roles, menus, buttons, data and other functions and data comprehensive authority management functions

Process management: Provide workflow engine services, support custom forms and processes, and fully support the approval flow in the HRMS system.

Human resource planning analysis: provide all-round The positional statistical analysis function satisfies enterprise human resource management and planning, and provides data basis for subsequent business decision-making.

2), system boundary

Based on the above core function points, we can sort out the boundaries of the system, including the following aspects:

i. The system boundary of the administrator

       Since the role of the administrator has been limited, he needs to have a dedicated operation and maintenance management backend. The functions provided by this backend are completely different from the backend functions and interfaces of business operators, so a separate entrance is required. Modules are also different. So we can get the access method and boundary when the administrator uses the system.

ii. HR system boundary

       The role of HR is responsible for business management related responsibilities, such as the approval link in the HR module. They have both business-initiated operations and approval link operations, so relatively speaking, the use boundary of HR roles will be broader, compared to employees . We found that HR needs to have a separate system entrance when using it, and assign it to their corresponding business modules and functions.

iii. The system boundary of employees

       For employees, only some modules in the HRMS system can be operated and used, such as attendance, reimbursement, performance, viewing and maintaining personal information, etc. The other information is filled in by HR and the user can view it, so it is easy to operate. , Employees and HR can have a unified entrance on the business system entrance, and the access boundary can be restricted by authority.

iv. Boundary of company managers

       Compared with employees, company managers have corresponding business and data management authority. At the same time, they will assume the identity of reviewers in the approval process. Many business processes are related to managers. Therefore, compared with employees, the business of company managers And the operation authority is larger, more upper and lower management aspects have more business content, and at the same time, it can also complete the related business of the employee role operation.

3), data object

i. Basic data: metadata, service management, logs, modules, basic configuration, data dictionary, system management and other basic data management included in the system

ii. Business data: covers organization, employees, HRMS system business and process data, external third-party business linkage data, etc.

iii. Other data: Covers other types of data such as files, pictures, videos, etc.; the result data after statistical analysis; the data interacted with or retained by third-party systems and other related content. Other data information such as log logs.

B. Divide high-level subsystems

       Based on the core requirements after the analysis of the robust graph above, we give the macro architecture outline of the system. Here, only user roles and responsibility chains are considered, thus forming the above-mentioned high-level segmentation.

C. The basic principle of quality requirements affecting the architecture: further questioning

       Combining the key quality and constraints that we have sorted out before, please refer to "HRMS (Human Resource Management System)-From Stand-Alone Application to SaaS Application-Architecture Analysis (Functional, Non-functional, Key Constraints)-Part Two" for details. I won’t list them in detail due to the length of the space. Based on these quality attributes and constraints, let’s further improve the outline structure:

1) Consider the continuous availability and scalability in the key quality attributes, and get the intermediate results of the outline architecture:

2) Consider the interoperability in the key quality attributes, and further optimize the intermediate results of the summary architecture:

3) Considering high performance, in addition to high load, it is also necessary to consider static and caching to improve system performance:

       The above basically formed the prototype of a summary architecture, but this is not enough. We still have a key content that has not been analyzed, that is, the system constraints. We need to analyze and disassemble the previously clear key constraints and transform them into functional or quality requirements:

D. Analyze the basic principles of the impact of constraints on the architecture: directly restrict and transform into functional or quality requirements

Analyze the content of the above table and verify it with the summary architecture given after the last few rounds of analysis to see if these constraints will affect the content of the architecture, and then optimize and adjust:

i. Business environment and constraints: At present, the above-mentioned outline structure can be supported and will not affect the current outline structure.

ii. Constraints on the use environment: The PC and App-side access modes previously drafted have considered the above-mentioned scenarios, and multi-language can be considered in the detailed design of the application layer.

iii. Development environment constraints: the outline architecture does not involve details yet, and the current constraints will not have a major impact on the architecture

iv. Technical environmental constraints: no impact, belonging to the level of detail

E. Based on the above steps, we have obtained a preliminary outline architecture, which basically meets various requirements and scenarios of function, quality and constraints, and draws the following outline architecture design diagram.



4. Summary of the main points of the outline architecture stage
Based on the previous practice of the outline architecture design deduction process, we summarize the three core points of the outline architecture process as follows:

1. First, we need to analyze and find the key functions, quality and constraints in the HRMS system

2. Secondly, use the robust graph to find the users, key functions and responsibility chains of the system, form a preliminary sub-system split, use high-level segmentation to form a hierarchical structure in the process, and constantly respond and improve through the questioning + solution model Quality and restraint requirements.

3. Finally, through the 1- and 2-step practical process, the preliminary outline structure is finally derived to provide the basis for the next step of the detailed structure.

I hope that through the demonstration of the above examples, you can provide some help in the follow-up process of system architecture design and practice.

Five, more information
For more knowledge of system architecture, I have established an exchange group, and relevant information will be shared in the group as soon as possible. Welcome everyone to join the group to learn and exchange:

Group: (Scan the QR code to enter the group-limited places)

HRMS (Human Resource Management System)-SaaS Architecture Design-Outline Design Practice