This repository will contain the artefacts produced by the "It Depends" team for the Autumn 2022 session of O'Reilly Architecture Katas. The project this season is to create a proposed architecture for "Hey Blue!", a system to facilitate moments of meaningful connection between police officers and members of their community.

• About ItDepends
• Goal
• Requirements
  • Architectural Vision
  • Domain Analysis Map
• Architecture Decisions
  1. Architectural Characteristics
  2. Architectural Styles
  3. ADRs
• Solution
  1. Interaction Manager
  2. Donation and Redemption
  3. Analytics and Reporting
  4. Media Manager
• Connecting the dots
• Characteristics Mapping
• References

We are the minds of software engineers and architects who have come together across three continents to work collaberatively and produce this proposed architecture.

• Shari Lines
• Miguel Gasca
• Kavya Shivakumar
• Prashant Jasani
• Susmitha Kunisetty
• Uma Kapoor

To design a feasible mobile/web solution which helps community by enabling citizens and police officers to connect and earn points which can be redeemed in charities or retail store.

The directory linked to above contains all artefacts related to functional requirements and architectural characteristics, as well as user story diagrams derived from the 4 processes documented in the original requirements.

• Business Process Workflow : Consists of process workflows for interaction, redeeming and registering.
• System Requirements
• Use Cases

• Evolutionary Considerations takes note of potential directions of evolution of Hey Blue! regarding Usability and scope of positive interactions.
• Volummetric Analysis has some napkin calculations feeding into throughput, elasticity and scale requirements of Hey Blue!

An abstract diagram illustrating the overall vision of Hey Blue! is

This is a domain model that fed further into our analysis. We have used different colors to denote areas of closer conceptual relation. Note: The shapes don't necessarily imply services/actions and the lines don't necessarily imply dependencies/calls/messages/events. This is meant to be a starting point for decomposition.

• Interactions is larger, red and in the middle because it is the core of the system.
• All Civilian/Officer core domain areas are orange.
• All retail business areas are green.
• All charity areas are blue.
• All data/reporting/analytics is purple.
• Monetary domain concepts in yellow.(i.e. how does HeyBlue make money and how do they apportion part of this to go back to community building).
• Grey is 3rd party and white is cross-cutting.

• Cross-Cutting Decisions Records This contains all recorded decisions made during our process. Starting with the first one to adopt MADR format and guidelines.

  • Design principles
  • Architectural Characteristics
  • Structural Decisions including Architectural Style ADR

• Functional Decisions Records

  • Security Compliance
  • UI Design Model
  • protect officer location
  • Provide control functionality to protect officer location
  • Retail store and Municipality
  • Data Strorage

We have identified core architectural characteristics and captured it into this worksheet based on Architecture Characteristics Worksheet

We built a worksheet based off of the one found at Developer to Architect Styles Worksheet. We considered all styles listed there except for Layered (it was least well suited from the list and has poor domain to architecture isomorphism). We added to the list Serverless and also a hybrid Event-Based-Serverless. The results of our analysis with a table constrained to our core characteristics is as below. The decision was made to use a hybrid Event-Based Serverless style. The detailed explanation of this decision is captured in 010 Architectural Styles

The proposed architecture is captured in a system landscape diagram. We have logically seperated our analysis of the architecture into 4 systems, and each is addressed in turn in it's own directory.

• Interaction Manager : Responsible to manage Civilian and Citizen registration and their potential interactions with each other by faciliting proximity detection, interfacing with social media and analytics.
• Donation and Redemption : Responsible to manage and administer Business and charities' relations along with point system and redemptions.
• Analytics and Reporting : Responsible for analytics and reporting and operational data management
• Media Manager : Responsible for Social media management

Each of these systems analysis contains the following

• Context Diagram
• Container Diagram
• Sequence Diagram/Data Model

A visual journey through understanding the breadth and depth of our proposed solution starts with the top level use case digram. Here we see our four primary actors and the four core scenarios. From there you may drill down to the images which are an expansion of each individual use case, these are in the Business Process Flow directory. Zooming back out a level the user story map provides a view that organizes the user journey into related user stories under activities. These distinct activities correlate 1:1 with the four systems in our System Landscape diagram. Each of those four systems has a dedicated directory under solution where we drill down from System Context to Container views. We also include sequence diagrams for primary user and/or data flows and data models at this level.

Using the template by Mark Richards that is available in Architectural Characteristics Worksheet we have identified how the characters can be mapped to our software system Contexts and here is the representation. (0 to 4 stars being the most)

• https://app.diagrams.net/
• https://www.developertoarchitect.com/

We have also maintained templates for

• C4,
• Draw.io Stencils
• MADR3.0 template