820 lines
30 KiB
Markdown
820 lines
30 KiB
Markdown
# LDPv2 - Requirements Analysis Document
|
|
|
|
## 1. Executive Summary
|
|
|
|
LDPv2 (Lifecycle Data Platform version 2) is a comprehensive application lifecycle management tool designed to manage and document all applications within a business unit. It serves as a central repository for application information, tracking deployments, dependencies, SLAs, and stakeholder relationships throughout the complete application lifecycle.
|
|
|
|
## 2. Purpose and Scope
|
|
|
|
### 2.1 Primary Objectives
|
|
|
|
- Provide a centralized documentation platform for all managed applications
|
|
- Track application lifecycle from ideation to decommissioning
|
|
- Manage deployment history across multiple environments
|
|
- Document and monitor external dependencies and data usage agreements
|
|
- Maintain SLA definitions and compliance tracking
|
|
- Facilitate stakeholder communication and responsibility mapping
|
|
|
|
### 2.2 Target Users
|
|
|
|
- Business Unit Directors and Program Managers
|
|
- Application Product Owners
|
|
- Development Teams
|
|
- Infrastructure and Operations Teams
|
|
- Compliance and Data Governance Officers
|
|
|
|
## 3. Technical Architecture
|
|
|
|
### 3.1 Technology Stack
|
|
|
|
#### 3.1.1 Backend
|
|
|
|
- **Framework**: Spring Boot 3.x
|
|
- **Security**: Spring Security with JWT-based authentication
|
|
- **Authentication Strategy**:
|
|
- Initial implementation: Local authentication (username/password)
|
|
- Future evolution: OAuth 2.0 / OpenID Connect integration
|
|
- **Authorization**: Role-based access control (RBAC) with environment-specific permissions
|
|
- **Persistence**: PostgreSQL 16
|
|
- **ORM**: Hibernate 6.x (JPA implementation)
|
|
- **API Style**: RESTful API with JSON payloads
|
|
|
|
#### 3.1.2 Frontend
|
|
|
|
- **Framework**: Angular 18
|
|
- **Authentication**: JWT token-based authentication
|
|
- **HTTP Client**: Angular HttpClient with interceptors for token management
|
|
- **State Management**: To be determined (NgRx, Signals, or service-based)
|
|
- **UI Components**: To be determined (Angular Material, PrimeNG, or custom)
|
|
|
|
#### 3.1.3 Database
|
|
|
|
- **RDBMS**: PostgreSQL 16
|
|
- **Schema Management**: Liquibase or Flyway for database migrations
|
|
- **Connection Pooling**: HikariCP (Spring Boot default)
|
|
|
|
### 3.2 Security Architecture
|
|
|
|
#### 3.2.1 Authentication Flow
|
|
|
|
1. User submits credentials to `/api/auth/login`
|
|
2. Backend validates credentials against database
|
|
3. Upon successful authentication, JWT token is generated and returned
|
|
4. Frontend stores JWT token (localStorage or sessionStorage)
|
|
5. Subsequent requests include JWT token in Authorization header
|
|
6. Backend validates token on each request via Spring Security filters
|
|
|
|
#### 3.2.2 Authorization Model
|
|
|
|
- **Environment-Based Roles**: Users can have different permissions per environment
|
|
- Example: User may have READ access to PROD but WRITE access to DEV
|
|
- **Role Hierarchy**: To be defined (e.g., ADMIN > MANAGER > USER > VIEWER)
|
|
- **Resource-Level Permissions**: Fine-grained access control on applications and business units
|
|
|
|
#### 3.2.3 Future OAuth Integration
|
|
|
|
- Support for enterprise SSO (Single Sign-On)
|
|
- Integration with identity providers (Azure AD, Okta, Keycloak)
|
|
- Backward compatibility with local authentication during migration
|
|
|
|
### 3.3 API Design Principles
|
|
|
|
- RESTful resource-based endpoints (e.g., `/api/applications`, `/api/deployments`)
|
|
- Consistent HTTP verb usage (GET, POST, PUT, DELETE, PATCH)
|
|
- Pagination for list endpoints
|
|
- Filtering and sorting capabilities
|
|
- HATEOAS support for discoverability (optional)
|
|
- Versioned API (e.g., `/api/v1/...`)
|
|
|
|
### 3.4 Data Persistence Strategy
|
|
|
|
- **Entity Mapping**: JPA entities with Hibernate annotations
|
|
- **Relationship Management**: Appropriate use of @OneToMany, @ManyToOne, @ManyToMany
|
|
- **Cascade Operations**: Carefully configured cascade types to maintain referential integrity
|
|
- **Lazy/Eager Loading**: Optimized fetch strategies to prevent N+1 queries
|
|
- **Auditing**: Automatic timestamp management using `@CreatedDate` and `@LastModifiedDate`
|
|
|
|
## 4. Functional Requirements
|
|
|
|
### 4.1 Business Unit Management
|
|
|
|
**Description**: Organizations are structured around business units that own and manage applications.
|
|
|
|
**Requirements**:
|
|
|
|
- Each business unit must have a unique name
|
|
- Business units must maintain a list of associated contacts with specific roles (Director, Program Manager, etc.)
|
|
- Support for hierarchical contact management with role-based assignments
|
|
|
|
**Data Model**:
|
|
|
|
- Business Unit entity with name and metadata
|
|
- Many-to-many relationship with Contact entities
|
|
- Role specification for each business unit contact
|
|
|
|
**API Endpoints**:
|
|
|
|
- `GET /api/business-units` - List all business units
|
|
- `GET /api/business-units/{id}` - Get business unit details
|
|
- `POST /api/business-units` - Create new business unit
|
|
- `PUT /api/business-units/{id}` - Update business unit
|
|
- `DELETE /api/business-units/{id}` - Delete business unit
|
|
- `GET /api/business-units/{id}/contacts` - Get contacts for business unit
|
|
|
|
### 4.2 Application Management
|
|
|
|
**Description**: Applications are the core entities tracked within the system, representing software systems deployed across various environments.
|
|
|
|
**Requirements**:
|
|
|
|
#### 4.2.1 Application Lifecycle Status
|
|
|
|
Applications must track their current status through the following states:
|
|
|
|
- **IDEA**: Initial concept phase, not yet in development
|
|
- **IN_DEVELOPMENT**: Active development in progress
|
|
- **IN_SERVICE**: Deployed and operational in production
|
|
- **MAINTENANCE**: Undergoing maintenance or limited support
|
|
- **DECOMMISSIONED**: Retired and no longer in use
|
|
|
|
Status transitions should be tracked with timestamps for audit purposes.
|
|
|
|
#### 4.2.2 Multi-Environment Deployment
|
|
|
|
- Applications must support deployment across multiple environments
|
|
- Each deployment must be linked to a specific version of the application
|
|
- Complete deployment history must be maintained with timestamps
|
|
- Deployment tracking must record who deployed and when
|
|
|
|
#### 4.2.3 Stakeholder Management
|
|
|
|
- Applications must maintain a list of contacts
|
|
- Each contact must be associated with a specific role (Product Owner, Functional Authority, Developer, Maintainer, etc.)
|
|
- Support for multiple stakeholders per role
|
|
- Contact information must include name, email, and phone number
|
|
|
|
#### 4.2.4 Service Level Agreements
|
|
|
|
- Each application must be associated with an SLA definition
|
|
- SLA compliance must be trackable
|
|
|
|
#### 4.2.5 Technical Documentation
|
|
|
|
- Applications must support multiple technical documentation references
|
|
- Each documentation entry must include:
|
|
- Title
|
|
- URL reference
|
|
- Creation and update timestamps
|
|
|
|
#### 4.2.6 Lifecycle Management
|
|
|
|
- End-of-life date tracking
|
|
- End-of-support date tracking
|
|
- Version-specific lifecycle information
|
|
|
|
#### 4.2.7 External Dependencies
|
|
|
|
- Applications must be able to reference multiple external dependencies
|
|
- Dependencies can be of various types (detailed in section 4.4)
|
|
|
|
**Data Model**:
|
|
|
|
- Application entity with status tracking (enum: IDEA, IN_DEVELOPMENT, IN_SERVICE, MAINTENANCE, DECOMMISSIONED)
|
|
- Relationship to Business Unit (many-to-one)
|
|
- Relationship to SLA (optional, one-to-one)
|
|
- Relationship to Versions (one-to-many)
|
|
- Relationship to Contacts (many-to-many)
|
|
- Relationship to Technical Documentation (one-to-many)
|
|
- Relationship to External Dependencies (one-to-many)
|
|
|
|
**API Endpoints**:
|
|
|
|
- `GET /api/applications` - List applications (with filtering by status, business unit)
|
|
- `GET /api/applications/{id}` - Get application details
|
|
- `POST /api/applications` - Create new application
|
|
- `PUT /api/applications/{id}` - Update application
|
|
- `PATCH /api/applications/{id}/status` - Update application status
|
|
- `DELETE /api/applications/{id}` - Delete application
|
|
- `GET /api/applications/{id}/versions` - Get versions for application
|
|
- `GET /api/applications/{id}/deployments` - Get deployment history
|
|
- `GET /api/applications/{id}/contacts` - Get stakeholders
|
|
- `GET /api/applications/{id}/dependencies` - Get external dependencies
|
|
|
|
### 4.3 Version Management
|
|
|
|
**Description**: Each application release is tracked as a distinct version with specific attributes.
|
|
|
|
**Requirements**:
|
|
|
|
- Every deployed application must be linked to a specific version
|
|
- Version tracking must include:
|
|
- **Version Identifier**: Semantic version or custom identifier (e.g., "1.2.3", "2024.Q1")
|
|
- **External Reference**: Link to source control, ticketing system, or release notes
|
|
- **Release Date**: When the version was officially released
|
|
- **End-of-Life Date**: When support for this version ends
|
|
- **Creation Timestamp**: When the version record was created
|
|
|
|
**Data Model**:
|
|
|
|
- Version entity linked to Application (many-to-one)
|
|
- Unique identifier and version metadata
|
|
- Lifecycle dates specific to the version
|
|
- Constraint: Version identifier must be unique within an application
|
|
|
|
**API Endpoints**:
|
|
|
|
- `GET /api/applications/{appId}/versions` - List versions for an application
|
|
- `GET /api/versions/{id}` - Get version details
|
|
- `POST /api/applications/{appId}/versions` - Create new version
|
|
- `PUT /api/versions/{id}` - Update version
|
|
- `DELETE /api/versions/{id}` - Delete version
|
|
|
|
### 4.4 External Dependencies Management
|
|
|
|
**Description**: Applications often rely on external data sources and services. These dependencies must be documented and tracked.
|
|
|
|
**Requirements**:
|
|
|
|
#### 4.4.1 Dependency Types
|
|
|
|
External dependencies can be classified into the following types:
|
|
|
|
- **WEB_SERVICE**: REST APIs, SOAP services, microservices
|
|
- **DATABASE**: External database connections
|
|
- **CERTIFICATE**: SSL/TLS certificates, authentication certificates
|
|
- **NETWORK_FLOW**: Network connections, firewall rules, VPN tunnels
|
|
|
|
#### 4.4.2 Dependency Documentation
|
|
|
|
Each external dependency must include:
|
|
|
|
- Name and type classification
|
|
- Descriptive documentation (free text)
|
|
- Technical documentation specific to the dependency
|
|
- Creation and update timestamps
|
|
|
|
#### 4.4.3 Data Usage Agreements
|
|
|
|
- External dependencies must be linkable to one or more Data Usage Agreements
|
|
- This enables tracking of data governance and compliance requirements
|
|
|
|
**Data Model**:
|
|
|
|
- External Dependency entity with type enumeration
|
|
- Relationship to Application (many-to-one)
|
|
- Relationship to Data Usage Agreements (many-to-many)
|
|
|
|
**API Endpoints**:
|
|
|
|
- `GET /api/applications/{appId}/dependencies` - List dependencies for application
|
|
- `GET /api/dependencies/{id}` - Get dependency details
|
|
- `POST /api/applications/{appId}/dependencies` - Create new dependency
|
|
- `PUT /api/dependencies/{id}` - Update dependency
|
|
- `DELETE /api/dependencies/{id}` - Delete dependency
|
|
- `GET /api/dependencies/{id}/agreements` - Get data usage agreements for dependency
|
|
|
|
### 4.5 Data Usage Agreements
|
|
|
|
**Description**: Data Usage Agreements formalize the authorization to use external data sources and must be tracked for compliance purposes.
|
|
|
|
**Requirements**: Each Data Usage Agreement must contain:
|
|
|
|
- **Data Nature**: Description of the type of data covered by the agreement
|
|
- **Documentation Link**: Reference to the legal or formal agreement document
|
|
- **Validity Start Date**: When the agreement becomes effective
|
|
- **Validity End Date**: When the agreement expires (optional for indefinite agreements)
|
|
- **Creation Timestamp**: When the agreement record was created
|
|
|
|
**Data Model**:
|
|
|
|
- Data Usage Agreement entity with validity period
|
|
- Many-to-many relationship with External Dependencies
|
|
|
|
**API Endpoints**:
|
|
|
|
- `GET /api/data-usage-agreements` - List all agreements (with expiration filtering)
|
|
- `GET /api/data-usage-agreements/{id}` - Get agreement details
|
|
- `POST /api/data-usage-agreements` - Create new agreement
|
|
- `PUT /api/data-usage-agreements/{id}` - Update agreement
|
|
- `DELETE /api/data-usage-agreements/{id}` - Delete agreement
|
|
|
|
### 4.6 Environment Management
|
|
|
|
**Description**: Environments represent distinct deployment targets where applications can be installed. Unlike traditional fixed environment types, LDPv2 treats environments as flexible entities that can be created and configured as needed.
|
|
|
|
**Requirements**:
|
|
|
|
#### 4.6.1 Environment as First-Class Entity
|
|
|
|
Each environment is a distinct entity with its own attributes and lifecycle. This allows for:
|
|
|
|
- Multiple production environments (e.g., PROD-EU, PROD-US, PROD-ASIA)
|
|
- Team-specific development environments (e.g., DEV-TeamAlpha, DEV-TeamBeta)
|
|
- Customer-specific environments
|
|
- Temporary or experimental environments
|
|
|
|
#### 4.6.2 Environment Attributes
|
|
|
|
Each environment must be tracked with the following attributes:
|
|
|
|
- **Name**: Unique identifier for the environment (e.g., "PROD-EU", "INT-QA", "DEV-Mobile")
|
|
- **Description**: Optional free-text description of the environment's purpose
|
|
- **Production Flag**: Boolean indicator to identify production environments
|
|
- **Criticality Level**: Numeric rating (e.g., 1-5) to prioritize monitoring, incident response, and deployment approvals
|
|
- Level 5: Critical production environments
|
|
- Level 4: Important pre-production environments
|
|
- Level 3: Integration and testing environments
|
|
- Level 2: Development environments
|
|
- Level 1: Experimental or temporary environments
|
|
- **Timestamps**: Creation and update tracking for audit purposes
|
|
|
|
#### 4.6.3 Environment Flexibility
|
|
|
|
- Environments can be created, updated, and deactivated as needed
|
|
- No hard-coded list of environments in the application code
|
|
- Support for environment-specific security roles and permissions
|
|
- Environments can be organized or tagged for better management (future enhancement)
|
|
|
|
#### 4.6.4 Environment-Based Access Control
|
|
|
|
- Users can have different permissions per environment
|
|
- Critical environments (high criticality level or production flag) may require additional approval workflows
|
|
- Deployment permissions should be configurable per environment
|
|
|
|
**Data Model**:
|
|
|
|
- Environment entity with flexible attributes
|
|
- No enumeration constraints on environment names
|
|
- Referenced by Deployment entity for tracking application versions
|
|
- Potential for environment grouping or categorization (future)
|
|
|
|
**API Endpoints**:
|
|
|
|
- `GET /api/environments` - List all environments (with filtering by production flag, criticality)
|
|
- `GET /api/environments/{id}` - Get environment details
|
|
- `POST /api/environments` - Create new environment
|
|
- `PUT /api/environments/{id}` - Update environment
|
|
- `DELETE /api/environments/{id}` - Deactivate/delete environment
|
|
- `GET /api/environments/{id}/deployments` - Get all deployments in this environment
|
|
|
|
**Security Considerations**:
|
|
|
|
- Creating or modifying production environments should require elevated privileges
|
|
- Environment deletion should be soft delete to preserve deployment history
|
|
- Audit logging for all environment changes
|
|
|
|
### 4.7 Deployment Tracking
|
|
|
|
**Description**: Deployments represent the installation of a specific application version to a specific environment.
|
|
|
|
**Requirements**:
|
|
|
|
#### 4.7.1 Deployment Definition
|
|
|
|
A deployment is uniquely defined by the combination of:
|
|
|
|
- Application (which application)
|
|
- Version (which release)
|
|
- Environment (where it's deployed)
|
|
|
|
#### 4.7.2 Deployment History
|
|
|
|
- Complete deployment history must be maintained (immutable records)
|
|
- Each deployment record must include:
|
|
- Deployment timestamp
|
|
- User or system that performed the deployment
|
|
- Optional notes or comments
|
|
- Creation timestamp for audit purposes
|
|
|
|
#### 4.7.3 Current State Tracking
|
|
|
|
- The system must be able to identify the currently active version in each environment
|
|
- This is determined by the most recent deployment for a given application-environment combination
|
|
- A dedicated API endpoint should provide current deployment state
|
|
|
|
**Data Model**:
|
|
|
|
- Deployment entity with foreign keys to Application, Version, and Environment
|
|
- Timestamp-based ordering for historical tracking
|
|
- Business logic to determine "current" deployment (most recent by deployment date)
|
|
|
|
**API Endpoints**:
|
|
|
|
- `GET /api/deployments` - List all deployments (with filtering)
|
|
- `GET /api/deployments/{id}` - Get deployment details
|
|
- `POST /api/deployments` - Record new deployment
|
|
- `GET /api/applications/{appId}/deployments/current` - Get current deployments per environment
|
|
- `GET /api/environments/{envId}/deployments/current` - Get all current deployments in environment
|
|
- `GET /api/deployments/history?applicationId={appId}&environmentId={envId}` - Deployment history for app in env
|
|
|
|
**Business Rules**:
|
|
|
|
- Deployments are immutable once created (no updates, only new deployments)
|
|
- Deployment dates cannot be in the future
|
|
- Version must belong to the specified application
|
|
|
|
### 4.8 Contact and Stakeholder Management
|
|
|
|
**Description**: Contacts represent roles and responsibilities associated with applications, business units, and SLAs.
|
|
|
|
**Requirements**:
|
|
|
|
#### 4.8.1 Contact Roles
|
|
|
|
The system must support various contact roles including but not limited to:
|
|
|
|
- Product Owner
|
|
- Functional Authority
|
|
- Developer
|
|
- Maintainer
|
|
- Technical Lead
|
|
- Business Analyst
|
|
- Director
|
|
- Program Manager
|
|
|
|
Roles should be configurable and extensible.
|
|
|
|
#### 4.8.2 Contact Structure
|
|
|
|
A contact represents a functional role that can be associated with:
|
|
|
|
- One or more named individuals (persons)
|
|
- Multiple applications
|
|
- Business units
|
|
- SLAs
|
|
|
|
#### 4.8.3 Person Information
|
|
|
|
Each person assigned to a contact must have:
|
|
|
|
- First name and last name
|
|
- Email address (required, unique)
|
|
- Phone number (optional)
|
|
- Primary contact designation (one person per contact should be marked as primary)
|
|
|
|
#### 4.8.4 Contact Relationships
|
|
|
|
Contacts must be linkable to:
|
|
|
|
- Applications (with application-specific roles)
|
|
- Business Units (with organizational roles)
|
|
- SLAs (as responsible parties for service delivery)
|
|
|
|
**Data Model**:
|
|
|
|
- ContactRole entity defining available roles
|
|
- Contact entity representing the functional position
|
|
- Person entity with individual contact details
|
|
- Junction tables for Contact-Person, Application-Contact, BusinessUnit-Contact, and SLA-Contact relationships
|
|
|
|
**API Endpoints**:
|
|
|
|
- `GET /api/contact-roles` - List available contact roles
|
|
- `GET /api/contacts` - List all contacts
|
|
- `GET /api/contacts/{id}` - Get contact details with persons
|
|
- `POST /api/contacts` - Create new contact
|
|
- `PUT /api/contacts/{id}` - Update contact
|
|
- `DELETE /api/contacts/{id}` - Delete contact
|
|
- `GET /api/persons` - List all persons
|
|
- `GET /api/persons/{id}` - Get person details
|
|
- `POST /api/persons` - Create new person
|
|
- `PUT /api/persons/{id}` - Update person
|
|
|
|
### 4.9 Service Level Agreement (SLA) Management
|
|
|
|
**Description**: SLAs define the expected service levels, maintenance windows, and responsibilities for applications.
|
|
|
|
**Requirements**:
|
|
|
|
#### 4.9.1 Core SLA Metrics
|
|
|
|
Each SLA must define:
|
|
|
|
- **Availability Percentage**: Expected uptime (e.g., 99.9%)
|
|
- **Minimum Average Response Time**: Expected response time in seconds
|
|
- **Reaction Time**: Time to respond to incidents (as text description)
|
|
|
|
#### 4.9.2 Maintenance Windows
|
|
|
|
- SLAs must support multiple maintenance windows
|
|
- Each maintenance window must specify:
|
|
- Day of the week (MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY)
|
|
- Start time (HH:MM format)
|
|
- End time (HH:MM format)
|
|
- Multiple maintenance windows can be defined for the same SLA
|
|
|
|
#### 4.9.3 Critical Periods
|
|
|
|
- SLAs must track critical periods when higher service levels are required
|
|
- Each critical period must include:
|
|
- Start datetime
|
|
- End datetime
|
|
- Duration in minutes
|
|
- Optional description
|
|
|
|
#### 4.9.4 SLA Documentation
|
|
|
|
- **Diagram**: Support for storing draw.io diagrams in JSON format showing system architecture and dependencies
|
|
- **Dependencies Description**: Free-text description of system dependencies
|
|
- **Responsibility Scope**: Clear definition of what is and isn't covered by the SLA
|
|
|
|
#### 4.9.5 SLA Contacts
|
|
|
|
- Multiple contacts must be assignable to each SLA
|
|
- These represent the responsible parties for maintaining service levels
|
|
|
|
**Data Model**:
|
|
|
|
- SLA entity with metrics and documentation
|
|
- MaintenanceWindow entity (one-to-many from SLA)
|
|
- CriticalPeriod entity (one-to-many from SLA)
|
|
- SLA-Contact junction table (many-to-many)
|
|
|
|
**API Endpoints**:
|
|
|
|
- `GET /api/slas` - List all SLAs
|
|
- `GET /api/slas/{id}` - Get SLA details
|
|
- `POST /api/slas` - Create new SLA
|
|
- `PUT /api/slas/{id}` - Update SLA
|
|
- `DELETE /api/slas/{id}` - Delete SLA
|
|
- `GET /api/slas/{id}/maintenance-windows` - Get maintenance windows
|
|
- `POST /api/slas/{id}/maintenance-windows` - Add maintenance window
|
|
- `GET /api/slas/{id}/critical-periods` - Get critical periods
|
|
- `POST /api/slas/{id}/critical-periods` - Add critical period
|
|
|
|
## 5. Data Model Summary
|
|
|
|
### 5.1 Core Entities
|
|
|
|
1. **BusinessUnit**: Organizational container for applications
|
|
2. **Application**: Central entity representing software systems
|
|
3. **Version**: Releases of applications
|
|
4. **Environment**: Flexible deployment targets with custom names and attributes
|
|
5. **Deployment**: Records of version deployments to environments
|
|
6. **Person**: Individual stakeholders
|
|
7. **ContactRole**: Predefined roles for stakeholders
|
|
8. **Contact**: Functional positions held by persons
|
|
9. **TechnicalDocumentation**: Links to technical resources
|
|
10. **ExternalDependency**: External services and data sources
|
|
11. **DataUsageAgreement**: Legal agreements for data usage
|
|
12. **SLA**: Service level agreement definitions
|
|
13. **MaintenanceWindow**: Scheduled maintenance periods
|
|
14. **CriticalPeriod**: High-priority time windows
|
|
|
|
### 5.2 Relationship Summary
|
|
|
|
- BusinessUnit → Application (1:N)
|
|
- Application → Version (1:N)
|
|
- Application + Version + Environment → Deployment (unique combination)
|
|
- Application ↔ Contact (N:N)
|
|
- Application → ExternalDependency (1:N)
|
|
- Application → TechnicalDocumentation (1:N)
|
|
- Application → SLA (1:1, optional)
|
|
- ExternalDependency ↔ DataUsageAgreement (N:N)
|
|
- Contact ↔ Person (N:N)
|
|
- SLA → MaintenanceWindow (1:N)
|
|
- SLA → CriticalPeriod (1:N)
|
|
- SLA ↔ Contact (N:N)
|
|
|
|
### 5.3 Database Schema Considerations
|
|
|
|
- All primary keys: UUID type
|
|
- Foreign keys with appropriate CASCADE/RESTRICT rules
|
|
- Indexes on frequently queried fields (application status, environment production flag, deployment dates)
|
|
- Unique constraints where applicable (email in Person, environment name)
|
|
- Audit columns (createdAt, updatedAt) on all entities using JPA auditing
|
|
|
|
## 6. Non-Functional Requirements
|
|
|
|
### 6.1 Performance
|
|
|
|
- API response time < 500ms for 95% of requests
|
|
- Support for pagination on all list endpoints (default page size: 20)
|
|
- Efficient query optimization to prevent N+1 problems
|
|
- Database connection pooling (HikariCP)
|
|
- Caching strategy for reference data (contact roles, environments)
|
|
|
|
### 6.2 Security
|
|
|
|
- JWT token expiration: 1 hour (configurable)
|
|
- Refresh token mechanism for session extension
|
|
- Password hashing: BCrypt with appropriate work factor
|
|
- HTTPS only in production
|
|
- CORS configuration for frontend origin
|
|
- SQL injection prevention via parameterized queries (JPA)
|
|
- XSS protection via Angular sanitization
|
|
- CSRF protection via Spring Security
|
|
|
|
### 6.3 Audit and Compliance
|
|
|
|
- All entities must track creation and update timestamps
|
|
- Deployment history must be immutable for audit purposes
|
|
- Data Usage Agreement expiration must be trackable
|
|
- User actions should be logged (who did what, when)
|
|
- Database audit trail for sensitive operations
|
|
|
|
### 6.4 Data Integrity
|
|
|
|
- Foreign key constraints enforced at database level
|
|
- Validation annotations on JPA entities (@NotNull, @Size, @Email, etc.)
|
|
- Business rule validation in service layer
|
|
- Transaction management for complex operations
|
|
- Soft delete for critical entities to preserve referential integrity
|
|
|
|
### 6.5 Scalability
|
|
|
|
- The system must support hundreds of applications
|
|
- Deployment history may grow to thousands of records per application
|
|
- Efficient querying of current deployment states is critical
|
|
- Database indexing strategy for performance
|
|
- Potential for read replicas if query load increases
|
|
|
|
### 6.6 Maintainability
|
|
|
|
- Clean separation of concerns (Controller → Service → Repository)
|
|
- DTOs for API layer to decouple from entity model
|
|
- MapStruct or ModelMapper for DTO conversion
|
|
- Comprehensive API documentation (Swagger/OpenAPI)
|
|
- Unit tests (JUnit 5, Mockito) with >80% code coverage
|
|
- Integration tests for critical workflows
|
|
- Docker containerization for consistent deployments
|
|
|
|
### 6.7 Usability
|
|
|
|
- Intuitive Angular UI with responsive design
|
|
- Clear error messages and validation feedback
|
|
- Loading indicators for async operations
|
|
- Confirmation dialogs for destructive actions
|
|
- Keyboard navigation support
|
|
- Accessibility compliance (WCAG 2.1 Level AA)
|
|
|
|
## 7. Implementation Phases
|
|
|
|
### 7.1 Phase 1: Core Foundation (MVP)
|
|
|
|
- Database schema creation with Liquibase/Flyway
|
|
- JPA entity model implementation
|
|
- Spring Security with local authentication
|
|
- JWT token generation and validation
|
|
- Basic CRUD APIs for:
|
|
- BusinessUnit
|
|
- Application (with status tracking)
|
|
- Environment
|
|
- Contact and Person
|
|
- Angular authentication module
|
|
- Basic application listing and detail views
|
|
|
|
### 7.2 Phase 2: Deployment Tracking
|
|
|
|
- Version entity and APIs
|
|
- Deployment entity and APIs
|
|
- Deployment history tracking
|
|
- Current deployment state queries
|
|
- Angular deployment management interface
|
|
- Deployment timeline visualization
|
|
|
|
### 7.3 Phase 3: Dependencies and Compliance
|
|
|
|
- External Dependency entity and APIs
|
|
- Data Usage Agreement entity and APIs
|
|
- Dependency-Agreement linkage
|
|
- Technical Documentation management
|
|
- Angular forms for dependency tracking
|
|
- Expiration alerts for agreements
|
|
|
|
### 7.4 Phase 4: SLA Management
|
|
|
|
- SLA entity and APIs
|
|
- Maintenance Window management
|
|
- Critical Period tracking
|
|
- SLA-Contact relationships
|
|
- Draw.io diagram storage and display
|
|
- Angular SLA management interface
|
|
|
|
### 7.5 Phase 5: Advanced Features
|
|
|
|
- Environment-based role permissions
|
|
- OAuth 2.0 integration
|
|
- Advanced search and filtering
|
|
- Dashboard and analytics
|
|
- Reporting capabilities
|
|
- Notification system
|
|
- API rate limiting
|
|
|
|
## 8. Testing Strategy
|
|
|
|
### 8.1 Backend Testing
|
|
|
|
- **Unit Tests**: Service layer business logic (JUnit 5, Mockito)
|
|
- **Integration Tests**: Repository layer with test database (Testcontainers)
|
|
- **API Tests**: Controller endpoints (MockMvc, REST Assured)
|
|
- **Security Tests**: Authentication and authorization flows
|
|
- **Performance Tests**: Load testing for critical endpoints (JMeter, Gatling)
|
|
|
|
### 8.2 Frontend Testing
|
|
|
|
- **Unit Tests**: Angular components and services (Jasmine, Karma)
|
|
- **Integration Tests**: Component interaction and routing
|
|
- **E2E Tests**: Critical user workflows (Cypress, Playwright)
|
|
- **Accessibility Tests**: WCAG compliance checking
|
|
|
|
### 8.3 Test Coverage Goals
|
|
|
|
- Backend code coverage: >80%
|
|
- Frontend code coverage: >70%
|
|
- Critical path E2E coverage: 100%
|
|
|
|
## 9. Deployment Architecture
|
|
|
|
### 9.1 Development Environment
|
|
|
|
- Local PostgreSQL instance via Docker
|
|
- Spring Boot running on port 8080
|
|
- Angular dev server on port 4200
|
|
- Hot reload enabled for both frontend and backend
|
|
|
|
### 9.2 Production Environment
|
|
|
|
- Containerized deployment (Docker/Kubernetes)
|
|
- PostgreSQL cluster with replication
|
|
- Load balancer for backend instances
|
|
- CDN for frontend static assets
|
|
- Separate database for each environment (dev, test, prod)
|
|
- Automated backup strategy
|
|
|
|
### 9.3 CI/CD Pipeline
|
|
|
|
- Source control: Git (GitHub, GitLab, or Bitbucket)
|
|
- Build automation: Maven for backend, npm for frontend
|
|
- Continuous Integration: Jenkins, GitLab CI, or GitHub Actions
|
|
- Automated testing in pipeline
|
|
- Docker image building and publishing
|
|
- Automated deployment to test environments
|
|
- Manual approval for production deployment
|
|
|
|
## 10. Documentation Requirements
|
|
|
|
### 10.1 Technical Documentation
|
|
|
|
- API documentation (Swagger/OpenAPI specification)
|
|
- Database schema documentation (ER diagrams)
|
|
- Architecture decision records (ADRs)
|
|
- Deployment and configuration guides
|
|
- Security best practices guide
|
|
|
|
### 10.2 User Documentation
|
|
|
|
- User manual for each user role
|
|
- Quick start guide
|
|
- Video tutorials for common workflows
|
|
- FAQ section
|
|
- Troubleshooting guide
|
|
|
|
## 11. Future Considerations
|
|
|
|
### 11.1 Potential Enhancements
|
|
|
|
- Integration with CI/CD pipelines for automatic deployment recording
|
|
- Automated SLA compliance monitoring and alerting
|
|
- Dashboard views for application portfolio management
|
|
- Notification system for expiring Data Usage Agreements
|
|
- Advanced reporting and analytics
|
|
- Mobile application for on-the-go access
|
|
- Webhook support for external integrations
|
|
- GraphQL API as alternative to REST
|
|
- Elasticsearch integration for advanced search
|
|
- Audit log viewer with filtering
|
|
|
|
### 11.2 Reporting Requirements
|
|
|
|
- Application inventory reports by status
|
|
- Deployment frequency analytics
|
|
- Environment utilization reports
|
|
- SLA compliance reporting
|
|
- Dependency mapping and impact analysis
|
|
- End-of-life planning reports
|
|
- Data usage agreement expiration forecasts
|
|
- Stakeholder contact directory
|
|
|
|
## 12. Success Criteria
|
|
|
|
The LDPv2 system will be considered successful when:
|
|
|
|
1. All applications within the business unit are accurately documented
|
|
2. Deployment history is complete and traceable across all environments
|
|
3. Stakeholders can easily identify current application states and ownership
|
|
4. Compliance officers can track data usage agreements effectively
|
|
5. SLA definitions are clearly documented and accessible
|
|
6. The system serves as the single source of truth for application lifecycle data
|
|
7. Users can perform all core functions without training (intuitive UI)
|
|
8. System uptime > 99.5%
|
|
9. User satisfaction score > 4.0/5.0
|
|
|
|
----------
|
|
|
|
**Document Version**: 2.0
|
|
**Last Updated**: February 2026
|
|
**Status**: Technical Specification - Ready for Development
|
|
**Prepared By**: Laurent
|
|
**Review Date**: To be scheduled
|