List architectural characteristics

[alecn2002]

List architectural characteristics

Carefully extract from problem description + add obvious as a consequence from the problem nature

Diversity Cyber Council Kata Requirements 2024

[alecn2002]

My opinion:

• 1x Agility - not important
• 1x Abstraction - this is one specific domain (well, actually 3: CV processing, hiring matching and payments), but they're cleary defined and not expected to evolve drastically, so: not important
• 4x Configurability: as it's expected to intercommunicate with multiple (and open-listed) number of HR systems - high importance
• 3x Cost: customer didn't say nothing on this topic; supposing it's average
• 1x Deployability: no requirements neither explicit nor implicit
• 4x Domain partitioning: 3 distinct domains (well, 4 if including AI as a distinct domain), so - high importance
• 3x Elasticity: on Employer and internal management side - definitely no as it's not expected more than 100s (or maybe first 1000s) of customers; On the job seekers side - yes if application will be deployed in the external cloud. Overall: possibly yes, no clear definition in requirements
• 1x Evolvability: no explicit requirements, implicitly: no
• 2x Fault-tolerance: not an online processing system, so implicitly - low requirements
• 5x Integration: high requirements, need to communicate with a zoo of HR systems, as well as payment system(s)
• 1x Interoperability: hmmm... no idea
• 2x Performance: same as Fault-tolerance reasons
• 4x Scalability: as it's expected high number of job seekers - more like important
• 1x Simplicity: no explicit not implicit; supposing not important
• 1x Testability: no requirements
• 4x Workflow: implicitly - high importance, clear workflows are defined and need to be followed

1x-5x -- importance marks

[mmest]

I add a characteristics worksheet (template here) with my first intuitive list. I have not looked at alecn2002. It is better to start independently and then discuss, I believe. Please note: characteristics will probably depend on clarification of requirements.

architecture-characteristics-mmest.pdf

[mmest]

List of most relevant architecture characteristics with explanation

Top–three.

These are the driving characteristics that the System must have or it will not be useful:

Interoperability

• Definition: The ability of the system to interface and interact with other systems to complete a business request.
• Rationale: the system is useless unless it can communicate with "Employer" HRMS. Note that "Configurability" is not what we need, because ClearView does not provide custom on–demand versions of itself. The adapter component that will interface with the external HR may be able to add a new peer by means of a configuration file rather than adding code, but it is not a problem of the architecture as a whole.

Security – data privacy

• Definition: The ability of the system to restrict access to sensitive information or functionality.
• Rationale: the System interoperates with HRMSs, which may have strong security and confidentiality requirements depending on what they will expose to our system. More important, the System manages PII (Personal Identifying Information) of a sensitive nature, whose disclosure may have legal consequences.

Data consistency

• Definition: The data across the system is in sync and consistent across databases and tables.
• Rationale: lack of consistency in the data flow from original resume to matching application may lead to missed hiring opportunities for the JobSeeker and possibly breach–of–contract or loss of confidentiality situations with both "Employer" and "Job Candidates".

Other Driving Characteristics.

These are what should be expected from this kind of System (besides the implicit characteristics)

Data Integrity

• Definition: The data across the system is correct and there is no data loss in the system.
• Rationale: can't have missing resume or role offers once they have been accepted by the system. Moreover, one hard requirement of the System is that it must allow the collection of measurements of significant metrics, which must be correct and complete.

Workflow

• Definition: The ability of the system to manage complex workflows that require multiple parts (services) of the system to complete a business request.
• Rationale: the workflows in the System are not very complex, but they do need to access at least two subsystems each.

Responsiveness

• Definition: The amount of time it takes to get a response to the user.
• Rationale: this is a user–interactive system. Attention should be given to reasonable response times:
  • The AI–Candidate interaction is a dialogue.
  • Once a de–identified resume is submitted, matching with role offers should be displayed with speed comparable to an ordinary search query on the internet.
  • Note that this implies a low degree of elasticity during peak usage hours.
  • Elasticity in itself is not a Driving Characteristic as we do not expect user to generate extrema load surges. Moreover, the System should serve a four time zones span, which implies load distribution along the 24 hours.

Scalability

• Definition: A function of system capacity and growth over time; as the number of users or requests increase in the system, responsiveness, performance, and error rates remain constant.
• Rationale: If successful, the System may see increasing adoption as the potential user pool is quite large. While we expect that the "Employer" and HMRS pool will be capped, "Job Candidate" user are many more. They may grow faster and to a greater total amount. The System architecture must be able to evolve to satisfy future demand.

ATTACHED: the worksheet as PDF

architecture-characteristics-mmest.pdf

[mmest]

(This is for choice of Architecture Style) Interestingly, most of the Driving Characteristics that I select in my previous comment do not directly impact on the choice of Architecture Style. Assuming that Performance proxies for better Responsiveness, it should be either "service–oriented" or "event–driven". Considering also cost, "event–driven" may be better even if it is not the best for interoperability. ATTACHED: the worksheet as PDF architecture-styles-mmest.pdf

[mwunderlich]

Thanks all for getting started. I'll try to take a closer look at the characteristics before the call today. Some initial comments:

• Interoperability: The system will have to support not only different interface of the external HRMS, but also different ways of interacting with them (push/pull, different auth mechanisms, etc.). So, a simple approach of having different adapters with same mechanics will probably not be sufficients.
• Security: This will require some form of encryption, both at rest and in transit.
• Internationlization: Probably a minor requirement, but it would be good to have the system usable in several languages/locales from the start.

[mmest]

Context diagram complete. It refers to the description of external communications in Issue #2. I will delete the comment with the previous incomplete diagram. EDITED: new context diagrams with encryption added to relationships, as per mwunderlich comment above.

Context Diagram.vpd.pdf

[mmest]

Note that we must remember that the AI is supposed to help the Employer by auto–filling their registration form when they subscribe to ClearView. It is in the rightmost relationship in the context diagram. The relationships marked [through ClearView Services] indicate that the connection is managed by the System; they are logical relationships, not physical connections.

[mmest]

* Internationlization: Probably a minor requirement, but it would be good to have the system usable in several languages/locales from the start. 

I agree in principle. But it is not an architecture problem, because it can be solved at the development level with no impact on the overall organization of the system. Same for accessibility.

[mmest]

* Security: This will require some form of encryption, both at rest and in transit.

Good point. For a start I am adding "encrypted" to the connection relationships in the context diagram.

[mwunderlich]

I agree in principle. But it is not an architecture problem, because it can be solved at the development level with no impact on the overall organization of the system. Same for accessibility.

Well, it is probably not the most pressing issue and we can just mention it in passing. however, I differ on the notion that it is not an architecture problem. I have worked in that area many years and seen the consquences of trying to attach internationalization later on. It just causes a lot of headaches and ugly work-arounds. but for this Kata it is only a side topic, I guess.

[mmest]

On 26 Sep 2024, at 11:41, Martin Wunderlich @.***> wrote: (…) Well, it is probably not the most pressing issue and we can just mention it in passing. however, I differ on the notion that it is not an architecture problem. I have worked in that area many years and seen the consquences of trying to attach internationalization later on. It just causes a lot of headaches and ugly work-arounds. but for this Kata it is only a side topic, I guess.

Yes, adding i18n afterward is a nightmare. What I mean with “not architectural problem” is that I do not see that I need to add a box in a diagram to contain that. I agree that i18n must be specified from the start, but I see it as a functional requirement, more than a system structure issue. On the other hand, you may have experience that points to a need for an explicit structural need, please let me know if that is necessary. I haven’t done any i18n myself… I only use English!