ESI - Enterprise Systems Integration Skills
Service Line Overview
Code: ESI
Full Name: Enterprise Systems Integration
Fee Modifier: 1.15
Description: ERP/HIS/LMS integration, API development, system architecture, migration planning
Skills Index
| # | Skill | Command | Purpose |
|---|
| 1 | Integration Assessment | /esi-assess | Evaluate current integration landscape |
| 2 | API Review | /esi-api-review | Audit existing APIs and interfaces |
| 3 | Architecture Review | /esi-arch-review | Assess system architecture |
| 4 | Migration Planning | /esi-migration | Plan system migrations |
| 5 | Data Mapping | /esi-data-map | Map data flows between systems |
| 6 | Integration Patterns | /esi-patterns | Recommend integration patterns |
| 7 | Vendor Evaluation | /esi-vendor-eval | Evaluate integration platforms/vendors |
| 8 | Cutover Planning | /esi-cutover | Plan go-live cutover activities |
Skill 1: Integration Assessment
Command: /esi-assess
Purpose
Evaluate the current state of enterprise systems and integration landscape to identify gaps, risks, and optimization opportunities.
Inputs Required
organization_name: "Company Name"
assessment_scope: "full|department|specific_systems"
systems_in_scope:
- name: "System Name"
type: "ERP|CRM|HIS|LMS|WMS|TMS|Custom"
vendor: "Vendor Name"
version: "x.x"
deployment: "on-premise|cloud|hybrid"
users: 000
criticality: "critical|high|medium|low"
current_integrations:
- source: "System A"
target: "System B"
method: "API|file|database|manual"
frequency: "real-time|hourly|daily|manual"
pain_points: ["Issue 1", "Issue 2"]
Assessment Framework
Integration Maturity Model (5 Levels)
| Level | Name | Characteristics |
|---|
| 1 | Ad-hoc | Manual data transfer, no standards, inconsistent |
| 2 | Managed | Point-to-point integrations, some documentation |
| 3 | Defined | Integration patterns established, API standards |
| 4 | Measured | Centralized monitoring, SLAs, metrics tracked |
| 5 | Optimized | iPaaS/ESB, automated governance, self-service |
Assessment Dimensions
-
Technical Architecture
- System inventory completeness
- Integration topology (point-to-point vs hub)
- Protocol diversity (REST, SOAP, SFTP, etc.)
- Data format consistency
-
Data Quality
- Master data management
- Data consistency across systems
- Duplicate detection
- Data governance
-
Security
- Authentication mechanisms
- Authorization controls
- Encryption (transit/rest)
- Audit logging
-
Operations
- Monitoring capabilities
- Error handling
- Recovery procedures
- SLA compliance
-
Governance
- Integration standards
- Change management
- Documentation
- Ownership model
Output: Integration Assessment Report
# Integration Assessment Report
## [Organization Name]
### Assessment Date: [Date]
## Executive Summary
[High-level findings and recommendations]
## Integration Maturity Score
**Overall Maturity Level:** [1-5] - [Level Name]
| Dimension | Score (1-5) | Key Finding |
|-----------|-------------|-------------|
| Technical Architecture | X.X | [Finding] |
| Data Quality | X.X | [Finding] |
| Security | X.X | [Finding] |
| Operations | X.X | [Finding] |
| Governance | X.X | [Finding] |
## System Landscape
### Systems Inventory
| System | Type | Vendor | Criticality | Integration Count |
|--------|------|--------|-------------|-------------------|
| [Name] | [Type] | [Vendor] | [Crit] | [Count] |
### Integration Map
[Visual representation of system integrations]
## Gap Analysis
### Critical Gaps
| Gap | Impact | Urgency | Remediation |
|-----|--------|---------|-------------|
| [Gap] | [Impact] | [Urgency] | [Action] |
### Technical Debt
| Item | System | Risk Level | Estimated Effort |
|------|--------|------------|------------------|
| [Item] | [System] | [Risk] | [Days] |
## Recommendations
### Immediate (0-3 months)
1. [Recommendation]
### Short-term (3-6 months)
1. [Recommendation]
### Long-term (6-12 months)
1. [Recommendation]
## Roadmap
[Phased approach to integration modernization]
Skill 2: API Review
Command: /esi-api-review
Purpose
Comprehensive audit of existing APIs including design, security, performance, and documentation quality.
Inputs Required
api_inventory:
- name: "API Name"
type: "REST|SOAP|GraphQL|gRPC"
version: "v1.0"
endpoint: "/api/v1/resource"
authentication: "OAuth2|API-Key|Basic|JWT|None"
documentation: "OpenAPI|WSDL|None"
consumers: ["System A", "System B"]
avg_calls_per_day: 10000
avg_response_time_ms: 200
review_focus: "security|performance|design|all"
API Assessment Criteria
1. Design Quality (REST APIs)
| Criterion | Best Practice | Weight |
|---|
| Resource Naming | Nouns, plural, lowercase | 10% |
| HTTP Methods | Proper use of GET/POST/PUT/DELETE | 15% |
| Status Codes | Appropriate HTTP codes | 10% |
| Versioning | URL or header versioning | 10% |
| Pagination | Consistent pagination pattern | 10% |
| Filtering/Sorting | Query parameter standards | 10% |
| Error Handling | Consistent error response format | 15% |
| HATEOAS | Hypermedia links (optional) | 5% |
| Idempotency | Safe retry behavior | 15% |
2. Security Assessment
| Check | Description | Severity |
|---|
| Authentication | Valid auth mechanism | Critical |
| Authorization | Role-based access control | Critical |
| Input Validation | Sanitization, type checking | High |
| Rate Limiting | Throttling implemented | High |
| TLS/SSL | HTTPS only, TLS 1.2+ | Critical |
| Sensitive Data | No PII in URLs/logs | Critical |
| CORS | Proper CORS configuration | Medium |
| API Keys | Key rotation, not in code | High |
3. Performance Metrics
| Metric | Target | Measurement |
|---|
| Response Time (P50) | < 200ms | Average response |
| Response Time (P95) | < 500ms | 95th percentile |
| Response Time (P99) | < 1000ms | 99th percentile |
| Availability | > 99.9% | Uptime percentage |
| Error Rate | < 0.1% | 4xx + 5xx responses |
| Throughput | Varies | Requests/second capacity |
4. Documentation Quality
| Element | Required | Score |
|---|
| OpenAPI/Swagger Spec | Yes | 20% |
| Authentication Guide | Yes | 15% |
| Error Code Reference | Yes | 15% |
| Example Requests | Yes | 15% |
| Example Responses | Yes | 15% |
| Rate Limit Info | Yes | 10% |
| Changelog | Yes | 10% |
Output: API Audit Report
# API Audit Report
## [Organization Name]
### Audit Date: [Date]
## Executive Summary
- APIs Reviewed: [Count]
- Overall Health Score: [X/100]
- Critical Issues: [Count]
- High Priority: [Count]
## API Portfolio Overview
| API | Type | Version | Health Score | Status |
|-----|------|---------|--------------|--------|
| [Name] | REST | v2.1 | 85/100 | Healthy |
## Detailed Findings
### API: [API Name]
#### Design Quality: [X/100]
| Criterion | Score | Finding |
|-----------|-------|---------|
| [Criterion] | [Score] | [Finding] |
#### Security Assessment: [Pass/Fail]
| Check | Status | Finding |
|-------|--------|---------|
| Authentication | [Pass/Fail] | [Details] |
#### Performance: [X/100]
| Metric | Current | Target | Status |
|--------|---------|--------|--------|
| P50 Response | [X]ms | 200ms | [Met/Not Met] |
#### Documentation: [X/100]
| Element | Status | Notes |
|---------|--------|-------|
| OpenAPI Spec | [Yes/No] | [Notes] |
## Recommendations by Priority
### Critical (Immediate)
1. [Security issue]
### High (Within 30 days)
1. [Performance issue]
### Medium (Within 90 days)
1. [Design improvement]
## API Governance Recommendations
[Recommendations for API standards and governance]
Skill 3: Architecture Review
Command: /esi-arch-review
Purpose
Assess enterprise system architecture for scalability, resilience, security, and alignment with business needs.
Inputs Required
architecture_scope: "enterprise|domain|application"
architecture_documentation:
- type: "context|container|component|deployment"
available: true|false
technology_stack:
frontend: ["React", "Angular"]
backend: ["Java", "Node.js", ".NET"]
database: ["PostgreSQL", "MongoDB", "Oracle"]
messaging: ["Kafka", "RabbitMQ", "Azure Service Bus"]
integration: ["MuleSoft", "Azure APIM", "Custom"]
deployment_model: "on-premise|cloud|hybrid"
cloud_provider: "AWS|Azure|GCP|None"
non_functional_requirements:
availability: "99.9%"
response_time: "< 500ms"
data_retention: "7 years"
concurrent_users: 10000
Architecture Assessment Framework
1. C4 Model Review
| Level | Diagram | Assessment Focus |
|---|
| Context | System Context | External actors, system boundaries |
| Container | Container | Applications, databases, services |
| Component | Component | Internal structure of containers |
| Code | Class/Sequence | Implementation patterns |
2. Quality Attributes (ISO 25010)
| Attribute | Sub-characteristics | Weight |
|---|
| Performance | Time behavior, Resource utilization | 15% |
| Reliability | Maturity, Availability, Fault tolerance | 20% |
| Security | Confidentiality, Integrity, Authentication | 20% |
| Maintainability | Modularity, Reusability, Analyzability | 15% |
| Scalability | Horizontal, Vertical, Elasticity | 15% |
| Compatibility | Interoperability, Co-existence | 10% |
| Portability | Adaptability, Installability | 5% |
3. Architecture Patterns Assessment
| Pattern | When to Use | Assessment Criteria |
|---|
| Monolith | Simple apps, small teams | Deployment complexity, coupling |
| Microservices | Complex domains, scaling needs | Service boundaries, data ownership |
| Event-Driven | Async processing, decoupling | Event design, eventual consistency |
| Serverless | Variable workloads, cost optimization | Cold starts, vendor lock-in |
| Hybrid | Migration, gradual modernization | Integration complexity, consistency |
4. Technical Debt Categories
| Category | Examples | Risk Level |
|---|
| Architectural | Wrong patterns, over-engineering | High |
| Code | Duplication, complexity | Medium |
| Infrastructure | Outdated versions, manual processes | High |
| Documentation | Missing, outdated docs | Medium |
| Testing | Low coverage, manual testing | Medium |
Output: Architecture Assessment Report
# Architecture Assessment Report
## [Organization/System Name]
### Assessment Date: [Date]
## Executive Summary
**Architecture Health Score:** [X/100]
**Primary Concern:** [Key finding]
**Recommendation:** [Main recommendation]
## Architecture Overview
### Current State
[Description of current architecture with diagrams]
### C4 Diagrams
- Context Diagram: [Available/Missing]
- Container Diagram: [Available/Missing]
- Component Diagram: [Available/Missing]
## Quality Attribute Analysis
| Attribute | Score | Assessment | Risk |
|-----------|-------|------------|------|
| Performance | X/10 | [Finding] | [H/M/L] |
| Reliability | X/10 | [Finding] | [H/M/L] |
| Security | X/10 | [Finding] | [H/M/L] |
| Maintainability | X/10 | [Finding] | [H/M/L] |
| Scalability | X/10 | [Finding] | [H/M/L] |
## Pattern Assessment
### Current Patterns
| Pattern | Implementation | Fitness Score |
|---------|----------------|---------------|
| [Pattern] | [How used] | [X/10] |
### Recommended Patterns
| Current | Recommended | Rationale |
|---------|-------------|-----------|
| [Current] | [Target] | [Why] |
## Technical Debt Register
| ID | Category | Description | Impact | Effort | Priority |
|----|----------|-------------|--------|--------|----------|
| TD-001 | [Cat] | [Desc] | [H/M/L] | [Days] | [1-5] |
## Recommendations
### Quick Wins (< 1 month)
1. [Recommendation]
### Strategic Improvements (1-6 months)
1. [Recommendation]
### Transformational (6-18 months)
1. [Recommendation]
## Target Architecture
[Vision for future state with diagrams]
Skill 4: Migration Planning
Command: /esi-migration
Purpose
Plan and structure system migration projects including legacy modernization, cloud migration, and platform changes.
Inputs Required
migration_type: "cloud|platform|version|consolidation|modernization"
source_system:
name: "Current System"
type: "ERP|CRM|Custom|Database"
vendor: "Vendor Name"
version: "x.x"
data_volume_gb: 500
user_count: 1000
integrations: 25
target_system:
name: "Target System"
type: "Same|Different"
vendor: "Vendor Name"
version: "x.x"
deployment: "cloud|on-premise|hybrid"
constraints:
max_downtime_hours: 4
budget: 500000
timeline_months: 12
compliance: ["GDPR", "PCI-DSS"]
Migration Strategy Framework
Migration Approaches (6 Rs)
| Strategy | Description | When to Use | Risk |
|---|
| Rehost | Lift-and-shift | Quick wins, no changes needed | Low |
| Replatform | Lift-tinker-shift | Minor optimization, managed services | Medium |
| Refactor | Re-architect | Major improvements, cloud-native | High |
| Repurchase | Replace with SaaS | COTS available, build vs buy | Medium |
| Retire | Decommission | No longer needed | Low |
| Retain | Keep as-is | Too complex/risky to migrate | Low |
Migration Phases
Phase 1: Assess (4-8 weeks)
├── Application discovery
├── Dependency mapping
├── Data profiling
├── Risk assessment
└── Strategy selection
Phase 2: Mobilize (4-6 weeks)
├── Team formation
├── Tooling setup
├── Environment provisioning
├── Training
└── Pilot selection
Phase 3: Migrate (Variable)
├── Wave planning
├── Data migration
├── Application migration
├── Integration testing
└── Performance testing
Phase 4: Optimize (Ongoing)
├── Performance tuning
├── Cost optimization
├── Security hardening
└── Operational excellence
Data Migration Approach
| Approach | Description | Downtime | Complexity |
|---|
| Big Bang | All at once | High | Low |
| Phased | Incremental waves | Medium | Medium |
| Parallel Run | Dual operation | None | High |
| Hybrid | Combination | Low | Medium |
Output: Migration Plan
# Migration Plan
## [Project Name]
### Version: 1.0 | Date: [Date]
## Executive Summary
**Migration Type:** [Type]
**Source:** [System] → **Target:** [System]
**Timeline:** [X months]
**Budget:** $[Amount]
**Strategy:** [Chosen R]
## Scope
### In Scope
- [Item 1]
- [Item 2]
### Out of Scope
- [Item 1]
## Current State Analysis
### Source System Profile
| Attribute | Value |
|-----------|-------|
| Data Volume | [X] GB |
| Users | [X] |
| Integrations | [X] |
| Customizations | [X] |
### Dependency Map
[Visual representation of dependencies]
## Migration Strategy
### Approach: [Strategy Name]
**Rationale:** [Why this approach]
### Wave Plan
| Wave | Systems | Users | Data (GB) | Timeline |
|------|---------|-------|-----------|----------|
| 1 | [Systems] | [Users] | [GB] | [Dates] |
| 2 | [Systems] | [Users] | [GB] | [Dates] |
## Data Migration
### Approach: [Big Bang/Phased/Parallel]
### Data Categories
| Category | Volume | Migration Method | Validation |
|----------|--------|------------------|------------|
| Master Data | [GB] | [Method] | [Validation] |
| Transactional | [GB] | [Method] | [Validation] |
| Historical | [GB] | [Method] | [Validation] |
### Data Quality Rules
| Rule | Source Field | Validation | Action on Fail |
|------|--------------|------------|----------------|
| [Rule] | [Field] | [Validation] | [Action] |
## Cutover Plan
[Detailed cutover activities - see /esi-cutover]
## Risk Register
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| [Risk] | [H/M/L] | [H/M/L] | [Mitigation] |
## Resource Plan
| Role | Count | Duration | Source |
|------|-------|----------|--------|
| Project Manager | 1 | Full | Internal |
| Technical Lead | 1 | Full | Internal |
| Developers | [X] | [Duration] | [Source] |
## Timeline
[Gantt chart or milestone view]
## Success Criteria
| Criterion | Target | Measurement |
|-----------|--------|-------------|
| Data Accuracy | > 99.9% | Reconciliation |
| Downtime | < [X] hours | Clock time |
| Performance | Same or better | Benchmark |
Skill 5: Data Mapping
Command: /esi-data-map
Purpose
Document and analyze data flows between systems including field-level mappings, transformations, and data lineage.
Inputs Required
mapping_scope: "integration|migration|audit"
source_system:
name: "Source System"
schema_available: true|false
data_dictionary: true|false
target_system:
name: "Target System"
schema_available: true|false
entities_in_scope:
- name: "Customer"
source_table: "CUST_MASTER"
target_table: "customers"
record_count: 50000
transformation_complexity: "simple|moderate|complex"
Data Mapping Framework
Mapping Types
| Type | Description | Example |
|---|
| Direct | 1:1 field mapping | source.name → target.name |
| Transformation | Apply function | UPPER(source.name) → target.name |
| Concatenation | Combine fields | source.first + source.last → target.fullname |
| Split | Separate field | source.address → target.street, city, zip |
| Lookup | Reference table | source.code → lookup → target.description |
| Default | Fixed value | NULL → target.status = 'ACTIVE' |
| Conditional | Business rules | IF source.type = 'A' THEN... |
| Derived | Calculated | source.qty * source.price → target.total |
Data Quality Dimensions
| Dimension | Description | Measurement |
|---|
| Completeness | All required data present | % non-null |
| Accuracy | Data is correct | % matching reference |
| Consistency | Same across systems | % matching |
| Timeliness | Data is current | Age of data |
| Validity | Conforms to rules | % passing validation |
| Uniqueness | No duplicates | % unique records |
Output: Data Mapping Specification
# Data Mapping Specification
## [Integration/Migration Name]
### Version: 1.0 | Date: [Date]
## Overview
**Source:** [System Name]
**Target:** [System Name]
**Purpose:** [Integration/Migration]
**Entities:** [Count]
## Entity Mappings
### Entity: [Entity Name]
#### Source-Target Overview
| Attribute | Source | Target |
|-----------|--------|--------|
| Table/Object | [Name] | [Name] |
| Record Count | [Count] | [Expected] |
| Key Field(s) | [Fields] | [Fields] |
#### Field Mapping
| # | Source Field | Source Type | Target Field | Target Type | Mapping Type | Transformation | Required | Notes |
|---|--------------|-------------|--------------|-------------|--------------|----------------|----------|-------|
| 1 | customer_id | VARCHAR(20) | id | UUID | Transform | UUID_GENERATE(customer_id) | Y | PK |
| 2 | cust_name | VARCHAR(100) | name | VARCHAR(255) | Direct | - | Y | - |
| 3 | addr_line1 | VARCHAR(50) | street | VARCHAR(100) | Direct | - | N | - |
| 4 | - | - | created_at | TIMESTAMP | Default | CURRENT_TIMESTAMP | Y | System |
#### Transformation Rules
**TR-001: [Rule Name]**
- Source: `[field]`
- Target: `[field]`
- Logic:
[Transformation logic/pseudocode]
- Example:
- Input: [example input]
- Output: [example output]
#### Lookup Tables
| Lookup Name | Source Value | Target Value |
|-------------|--------------|--------------|
| status_map | 'A' | 'ACTIVE' |
| status_map | 'I' | 'INACTIVE' |
#### Business Rules
| Rule ID | Description | Logic |
|---------|-------------|-------|
| BR-001 | [Description] | [Logic] |
## Data Quality Rules
### Pre-Migration Validation
| Rule | Field(s) | Validation | Action |
|------|----------|------------|--------|
| DQ-001 | customer_id | NOT NULL | Reject |
| DQ-002 | email | Valid format | Default |
### Post-Migration Reconciliation
| Check | Query/Method | Expected |
|-------|--------------|----------|
| Record Count | COUNT(*) | Match ± 0 |
| Sum Check | SUM(amount) | Match ± 0.01 |
## Data Lineage
[Visual lineage diagram]
## Change Log
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | [Date] | [Name] | Initial |
Skill 6: Integration Patterns
Command: /esi-patterns
Purpose
Recommend and design appropriate integration patterns based on requirements, constraints, and industry best practices.
Inputs Required
integration_requirement:
source: "System A"
target: "System B"
data_type: "master|transactional|reference|event"
volume: "low|medium|high|very_high"
frequency: "real-time|near-real-time|batch|on-demand"
direction: "unidirectional|bidirectional"
constraints:
latency_requirement: "< 1s|< 1min|< 1hr|flexible"
availability: "99.9%|99.5%|99%"
ordering: "required|preferred|not_required"
exactly_once: true|false
existing_infrastructure:
esb: "MuleSoft|Azure APIM|None"
messaging: "Kafka|RabbitMQ|Azure Service Bus|None"
api_gateway: "Kong|Apigee|None"
Enterprise Integration Patterns (EIP) Catalog
Messaging Patterns
| Pattern | Description | Use Case |
|---|
| Message Channel | Communication pipe | Any message exchange |
| Point-to-Point | Single consumer | Commands, requests |
| Publish-Subscribe | Multiple consumers | Events, notifications |
| Request-Reply | Synchronous call | API calls, queries |
| Message Router | Conditional routing | Dynamic destinations |
| Message Filter | Selective processing | Conditional handling |
| Splitter | Divide message | Batch processing |
| Aggregator | Combine messages | Correlation |
| Content Enricher | Add data | Lookup augmentation |
| Content Filter | Remove data | Security, simplification |
Integration Styles
| Style | Description | Pros | Cons |
|---|
| File Transfer | Shared files | Simple, decoupled | Latency, no standards |
| Shared Database | Common DB | Simple, consistent | Coupling, scaling |
| Remote Procedure | API calls | Real-time, standards | Tight coupling |
| Messaging | Async messages | Decoupled, reliable | Complexity |
API Patterns
| Pattern | Description | Use Case |
|---|
| REST | Resource-based HTTP | CRUD operations |
| GraphQL | Query language | Flexible queries |
| gRPC | Binary RPC | High performance |
| WebSocket | Bidirectional | Real-time updates |
| Webhook | Push notifications | Event callbacks |
Output: Integration Pattern Recommendation
# Integration Pattern Recommendation
## [Integration Name]
### Date: [Date]
## Requirements Summary
| Attribute | Requirement |
|-----------|-------------|
| Source | [System] |
| Target | [System] |
| Data Type | [Type] |
| Volume | [Volume] |
| Frequency | [Frequency] |
| Direction | [Direction] |
| Latency | [Requirement] |
## Recommended Pattern
### Primary Pattern: [Pattern Name]
**Pattern Category:** [Messaging/API/File/Database]
**Rationale:**
[Why this pattern fits the requirements]
### Architecture Diagram
[ASCII or reference to diagram]
### Pattern Components
| Component | Technology | Purpose |
|-----------|------------|---------|
| Producer | [Tech] | [Purpose] |
| Channel | [Tech] | [Purpose] |
| Consumer | [Tech] | [Purpose] |
### Implementation Specification
#### Message/API Design
```json
{
"pattern": "[pattern]",
"schema": {
// Schema definition
}
}
Error Handling
| Scenario | Handling | Retry Policy |
|---|
| Timeout | [Action] | [Policy] |
| Invalid Data | [Action] | [Policy] |
| System Down | [Action] | [Policy] |
Monitoring Points
| Metric | Threshold | Alert |
|---|
| Latency | [ms] | [Action] |
| Error Rate | [%] | [Action] |
| Queue Depth | [count] | [Action] |
Alternative Patterns Considered
| Pattern | Pros | Cons | Why Not |
|---|
| [Alt 1] | [Pros] | [Cons] | [Reason] |
| [Alt 2] | [Pros] | [Cons] | [Reason] |
Implementation Roadmap
Phase 1: Foundation
Phase 2: Development
Phase 3: Testing
Phase 4: Deployment
---
## Skill 7: Vendor Evaluation
### Command: `/esi-vendor-eval`
### Purpose
Evaluate and compare integration platform vendors (iPaaS, ESB, API Management) for enterprise needs.
### Inputs Required
```yaml
evaluation_scope: "iPaaS|ESB|API-Management|Full-Stack"
requirements:
must_have:
- "On-premise deployment option"
- "SAP integration"
nice_to_have:
- "Low-code development"
- "AI/ML capabilities"
constraints:
budget_annual: 200000
deployment: "cloud|on-premise|hybrid"
region: "MENA|EU|US"
current_landscape:
existing_tools: ["Tool1", "Tool2"]
skill_availability: "strong|moderate|limited"
vendors_to_evaluate:
- "MuleSoft"
- "Dell Boomi"
- "Microsoft Azure Integration"
- "Workato"
Vendor Evaluation Framework
Evaluation Categories (Weighted)
| Category | Weight | Description |
|---|
| Functional Capabilities | 25% | Features, connectors, protocols |
| Technical Architecture | 20% | Scalability, performance, deployment |
| Ease of Use | 15% | Development experience, learning curve |
| Security & Compliance | 15% | Certifications, encryption, access control |
| Vendor Viability | 10% | Market position, financials, roadmap |
| Total Cost of Ownership | 10% | Licensing, infrastructure, personnel |
| Support & Ecosystem | 5% | Documentation, community, partners |
Functional Capabilities Criteria
| Criterion | Description | Max Score |
|---|
| Pre-built Connectors | Number and quality of connectors | 10 |
| Custom Development | SDK, APIs, extensibility | 10 |
| Data Transformation | Mapping, transformation capabilities | 10 |
| Process Orchestration | Workflow, BPM capabilities | 10 |
| Event Processing | Real-time, streaming support | 10 |
| API Management | Full lifecycle management | 10 |
| B2B/EDI | EDI, B2B gateway capabilities | 10 |
| Master Data | MDM capabilities | 10 |
Major iPaaS Vendors Reference
| Vendor | Strength | Consideration |
|---|
| MuleSoft | Enterprise features, Salesforce | Cost, complexity |
| Dell Boomi | Ease of use, MDM | Limited on-prem |
| Microsoft Azure | Microsoft ecosystem | Azure lock-in |
| Workato | Automation, low-code | Enterprise scale |
| Informatica | Data management | Learning curve |
| SnapLogic | AI, performance | Niche market |
| Celigo | NetSuite, e-commerce | SMB focus |
| Jitterbit | Speed, flexibility | Smaller ecosystem |
Output: Vendor Evaluation Report
# Integration Vendor Evaluation
## [Client Name]
### Evaluation Date: [Date]
## Executive Summary
**Recommended Vendor:** [Vendor Name]
**Runner-up:** [Vendor Name]
**Rationale:** [Summary rationale]
## Requirements Summary
### Must-Have Requirements
| # | Requirement | Weight |
|---|-------------|--------|
| 1 | [Requirement] | Critical |
### Nice-to-Have Requirements
| # | Requirement | Weight |
|---|-------------|--------|
| 1 | [Requirement] | High |
## Vendors Evaluated
1. [Vendor 1]
2. [Vendor 2]
3. [Vendor 3]
## Detailed Scoring
### Overall Scores
| Vendor | Functional | Technical | Ease of Use | Security | Viability | TCO | Support | **Total** |
|--------|------------|-----------|-------------|----------|-----------|-----|---------|-----------|
| [V1] | X.X | X.X | X.X | X.X | X.X | X.X | X.X | **X.X** |
| [V2] | X.X | X.X | X.X | X.X | X.X | X.X | X.X | **X.X** |
### Category Breakdown
#### Functional Capabilities
| Criterion | [V1] | [V2] | [V3] | Notes |
|-----------|------|------|------|-------|
| Connectors | X/10 | X/10 | X/10 | [Notes] |
#### Technical Architecture
| Criterion | [V1] | [V2] | [V3] | Notes |
|-----------|------|------|------|-------|
| Scalability | X/10 | X/10 | X/10 | [Notes] |
## Total Cost of Ownership (5-Year)
| Cost Component | [V1] | [V2] | [V3] |
|----------------|------|------|------|
| License (Year 1) | $XXX | $XXX | $XXX |
| License (Years 2-5) | $XXX | $XXX | $XXX |
| Implementation | $XXX | $XXX | $XXX |
| Infrastructure | $XXX | $XXX | $XXX |
| Training | $XXX | $XXX | $XXX |
| Support | $XXX | $XXX | $XXX |
| **Total 5-Year TCO** | **$XXX** | **$XXX** | **$XXX** |
## Strengths & Weaknesses
### [Vendor 1]
| Strengths | Weaknesses |
|-----------|------------|
| [Strength] | [Weakness] |
## Reference Checks
| Vendor | Reference | Industry | Feedback |
|--------|-----------|----------|----------|
| [V1] | [Company] | [Industry] | [Summary] |
## Recommendation
### Primary Recommendation: [Vendor Name]
**Rationale:**
1. [Reason 1]
2. [Reason 2]
**Implementation Considerations:**
- [Consideration 1]
- [Consideration 2]
### Alternative: [Vendor Name]
**When to Consider:**
- [Scenario]
## Next Steps
1. Proof of Concept with [Vendor]
2. Contract negotiation
3. Implementation planning
Skill 8: Cutover Planning
Command: /esi-cutover
Purpose
Plan detailed go-live cutover activities for system migrations and integrations including rollback procedures.
Inputs Required
cutover_type: "big-bang|phased|parallel"
go_live_date: "2026-03-15"
systems_involved:
- name: "System Name"
role: "source|target|supporting"
criticality: "critical|high|medium"
cutover_window:
start: "Friday 22:00"
end: "Monday 06:00"
total_hours: 56
stakeholders:
business_owner: "Name"
it_lead: "Name"
vendor_contacts: ["Name1", "Name2"]
rollback_triggers:
- "Data reconciliation variance > 0.1%"
- "Critical functionality failure"
Cutover Planning Framework
Cutover Phases
| Phase | Duration | Activities |
|---|
| Pre-Cutover | T-4 weeks | Rehearsal, checklist, communications |
| Freeze Period | T-1 week | Change freeze, final prep |
| Cutover Start | T-0 | Begin cutover activities |
| Data Migration | Variable | Extract, transform, load |
| Validation | 4-8 hours | Data and functional validation |
| Go/No-Go | 1 hour | Decision point |
| Go-Live | Variable | Enable production, user access |
| Hypercare | 1-2 weeks | Intensive support |
Go/No-Go Decision Framework
| Criterion | Weight | Pass Threshold |
|---|
| Data Reconciliation | 30% | Variance < 0.01% |
| Critical Functions | 25% | 100% pass |
| Performance | 20% | Within 10% of baseline |
| Integration Health | 15% | All integrations active |
| Rollback Feasibility | 10% | < 4 hours to rollback |
Output: Cutover Plan
# Cutover Plan
## [Project Name]
### Version: 1.0 | Go-Live: [Date]
## Executive Summary
**Go-Live Date:** [Date]
**Cutover Window:** [Start] to [End] ([X] hours)
**Cutover Type:** [Big-Bang/Phased/Parallel]
**Risk Level:** [High/Medium/Low]
## Cutover Scope
### Systems
| System | Role | Owner | Contact |
|--------|------|-------|---------|
| [System] | [Role] | [Name] | [Phone/Email] |
### Data Scope
| Entity | Records | Migration Time | Validation |
|--------|---------|----------------|------------|
| [Entity] | [Count] | [Hours] | [Method] |
## Communication Plan
### Stakeholder Notifications
| When | Who | Method | Message |
|------|-----|--------|---------|
| T-2 weeks | All users | Email | Go-live announcement |
| T-1 week | Key users | Meeting | Final preparation |
| Go-live | All | Email/SMS | System live confirmation |
### War Room Setup
**Location:** [Physical/Virtual]
**Hours:** [Start] to [End]
**Access:** [Details]
## Detailed Cutover Schedule
### T-4 Weeks: Rehearsal
| Day | Activity | Owner | Duration |
|-----|----------|-------|----------|
| [Day] | Cutover rehearsal #1 | [Owner] | [Hours] |
### T-1 Week: Freeze & Final Prep
| Day | Activity | Owner | Duration |
|-----|----------|-------|----------|
| [Day] | Change freeze begins | [Owner] | - |
| [Day] | Final data backup | [Owner] | [Hours] |
### Cutover Weekend
#### Friday [Date]
| Time | Activity | Owner | Duration | Status |
|------|----------|-------|----------|--------|
| 22:00 | Cutover kickoff | PM | 15 min | |
| 22:15 | Disable source system access | [Owner] | 15 min | |
| 22:30 | Final data extract | [Owner] | 2 hrs | |
| 00:30 | Data transformation | [Owner] | 3 hrs | |
#### Saturday [Date]
| Time | Activity | Owner | Duration | Status |
|------|----------|-------|----------|--------|
| 03:30 | Data load - Batch 1 | [Owner] | 4 hrs | |
| 07:30 | Data load - Batch 2 | [Owner] | 4 hrs | |
| 11:30 | Data reconciliation | [Owner] | 3 hrs | |
| 14:30 | Functional testing | [Owner] | 4 hrs | |
#### Sunday [Date]
| Time | Activity | Owner | Duration | Status |
|------|----------|-------|----------|--------|
| 08:00 | Integration testing | [Owner] | 4 hrs | |
| 12:00 | Performance testing | [Owner] | 2 hrs | |
| 14:00 | **GO/NO-GO Decision** | Steering | 1 hr | |
| 15:00 | Enable user access | [Owner] | 1 hr | |
| 16:00 | Cutover complete | PM | - | |
## Validation Checklist
### Data Reconciliation
| Check | Source | Target | Variance | Status |
|-------|--------|--------|----------|--------|
| Record count - Customers | [X] | [X] | [%] | |
| Record count - Orders | [X] | [X] | [%] | |
| Sum - Order Value | $[X] | $[X] | [%] | |
### Functional Validation
| Test Case | Expected | Actual | Status |
|-----------|----------|--------|--------|
| TC-001: [Name] | [Expected] | | |
| TC-002: [Name] | [Expected] | | |
### Integration Validation
| Integration | Method | Status | Notes |
|-------------|--------|--------|-------|
| [System A ↔ B] | API call | | |
## Go/No-Go Criteria
### Decision Matrix
| Criterion | Weight | Threshold | Actual | Pass |
|-----------|--------|-----------|--------|------|
| Data Reconciliation | 30% | < 0.01% | | |
| Critical Functions | 25% | 100% | | |
| Performance | 20% | ± 10% | | |
| Integrations | 15% | 100% | | |
| Rollback Ready | 10% | Yes | | |
| **Total Score** | 100% | > 90% | | |
### Decision Authority
| Scenario | Decision | Authority |
|----------|----------|-----------|
| All criteria pass | GO | Project Manager |
| 1 criteria fails (non-critical) | GO with conditions | IT Director |
| Critical criteria fails | NO-GO | Steering Committee |
## Rollback Plan
### Rollback Triggers
- [ ] Data reconciliation variance > 0.1%
- [ ] Critical functionality failure
- [ ] Major integration failure
- [ ] Performance degradation > 50%
- [ ] Steering committee decision
### Rollback Procedure
| Step | Activity | Owner | Duration |
|------|----------|-------|----------|
| 1 | Disable target system access | [Owner] | 15 min |
| 2 | Restore source system backup | [Owner] | 2 hrs |
| 3 | Re-enable source system | [Owner] | 30 min |
| 4 | Validate source system | [Owner] | 1 hr |
| 5 | Notify stakeholders | PM | 15 min |
| **Total Rollback Time** | | | **~4 hrs** |
### Point of No Return
**Time:** [Sunday 12:00]
**Reason:** [Explain why rollback becomes impractical]
## Hypercare Plan
### Support Model (Weeks 1-2 Post Go-Live)
| Day | Support Hours | Team | Focus |
|-----|---------------|------|-------|
| Day 1-3 | 24/7 | Full team | Critical issues |
| Day 4-7 | 6:00-22:00 | Core team | High priority |
| Week 2 | Business hours | Reduced | All issues |
### Escalation Path
| Level | Response Time | Contact |
|-------|---------------|---------|
| L1 - Help Desk | 15 min | [Contact] |
| L2 - Application | 30 min | [Contact] |
| L3 - Technical | 1 hr | [Contact] |
| L4 - Vendor | Per SLA | [Contact] |
## Contacts
### War Room Contacts
| Role | Name | Phone | Email |
|------|------|-------|-------|
| Cutover Lead | [Name] | [Phone] | [Email] |
| Technical Lead | [Name] | [Phone] | [Email] |
| Business Lead | [Name] | [Phone] | [Email] |
| Vendor Contact | [Name] | [Phone] | [Email] |
## Appendices
### A. Pre-Cutover Checklist
- [ ] All development complete
- [ ] UAT signed off
- [ ] Production environment ready
- [ ] Backup verified
- [ ] Rollback tested
- [ ] Communication sent
- [ ] War room setup
### B. Post-Cutover Checklist
- [ ] All validations pass
- [ ] User access enabled
- [ ] Monitoring active
- [ ] Support team briefed
- [ ] Stakeholders notified
- [ ] Documentation updated
Service Line Integration
Fee Modifier
ESI Base Modifier: 1.15 (applied to standard rates)
Typical Engagement Phases
| Phase | Duration | Deliverables |
|---|
| Assessment | 2-4 weeks | Integration Assessment, API Review |
| Design | 3-6 weeks | Architecture Review, Pattern Recommendations |
| Planning | 2-4 weeks | Migration Plan, Data Mapping |
| Execution | Variable | Implementation (per pattern) |
| Cutover | 1-2 weeks | Cutover Plan, Go-Live Support |
Cross-Skill Workflows
Full Integration Modernization:
/esi-assess → /esi-api-review → /esi-arch-review →
/esi-patterns → /esi-vendor-eval → /esi-migration →
/esi-data-map → /esi-cutover
System Migration:
/esi-assess → /esi-arch-review → /esi-migration →
/esi-data-map → /esi-cutover
New Integration:
/esi-patterns → /esi-api-review → /esi-data-map
Platform Selection:
/esi-assess → /esi-vendor-eval → /esi-arch-review
Integration with Other Service Lines
| Service Line | Integration Point |
|---|
| DIG | Digital transformation requiring system modernization |
| AAI | Automation requiring system integration |
| COE | Data pipelines, BI system integration |
| HLT | HIS/EMR integration, HL7/FHIR |
| MAR | Port system integration (TOS, VTMIS) |
| EDU | LMS integration, student systems |
Templates & Artifacts
All ESI deliverables should use standard CPS branding via:
/doc-gen for document generation
assets/cps-branding.json for styling
scripts/cps-document-generator.js for automation
Standard Artifacts by Skill
| Skill | Primary Artifact | Format |
|---|
| /esi-assess | Integration Assessment Report | DOCX/PDF |
| /esi-api-review | API Audit Report | DOCX/PDF |
| /esi-arch-review | Architecture Assessment | DOCX/PDF |
| /esi-migration | Migration Plan | DOCX/PDF |
| /esi-data-map | Data Mapping Specification | XLSX/DOCX |
| /esi-patterns | Pattern Recommendation | DOCX |
| /esi-vendor-eval | Vendor Evaluation Report | DOCX/PDF |
| /esi-cutover | Cutover Plan | DOCX/XLSX |