Gap analysis

A template for formally documenting discontinuities, unanswered questions, and perceived shortcomings between the current state and target state architecture.

For this activity, refer to chapter 2.6 Target state architecture as a guide. Gaps can be identified at any stage of the design process, and should be documented to ensure they are addressed in time.

Analysis steps

  1. Identify the components affected: Associate the scope of the gap with specific components or functional areas. You can’t move forward with that component until the gap has been resolved to an acceptable degree.
  2. Assess the current state: Document the existing or current state, if there is one, again highlighting the functional area that aligns with the future state gap.
  3. Determine the desired future state: Describe the function required in the future state architecture (focusing on the specific functional area that is exposed to a gap).
  4. Assess the gap: Identify exactly what the gap is. This is usually expressed in terms of the lack of function or impact to the design. Try to state clear metrics that quantitatively express the gap between current and future state.
  5. Summarize: Include a summary of the gap and metrics in clear language, so that anyone reading the gap can quickly see its potential impact and risk.
  6. Create action plan: Document an action plan to resolve the gap within necessary project parameters.

The gap analysis provides a clear understanding of the differences between the current state and the target state, highlighting the specific areas where improvements or changes are needed. By identifying and addressing these gaps methodically, you can make strategic improvements to technical infrastructure and capabilities, ultimately achieving a desired future state.

Gap: [GAP TITLE]

ComponentCurrent state/function

Event Log
(Data Persistence)

  • Siloed
  • Not cloud compatible
Target state
  • Event streaming
  • Data projections (warehouse)
  • Data pipelines
  • ETL
Gap
  • Insufficient for stream volume (>1M events/hr)
  • Current state ETL tools inadequate (none licensed)
  • Security and governance gaps may exist (no ISO 27002 certification)
Action Plan
SummaryCurrent (legacy) state relies on older generation on-prem relational database technology. The future state is a modern, even streaming system that can handle inbound events at scale, using on-demand (elastic) scaling. The on-prem technology does not meet performance/functional requirements, and may also have some security and governance weaknesses.
Action plan
  1. Architecture board and team architecture lead to review future/current state and propose solution.
  2. Team to validate architecture and finalize revised design.
  3. Legacy to future state migration concerns to be discussed.
  4. Cost analysis by team.
  5. Final approval of future state.
Business capabilities affected
  • Customer transaction processing
  • Real-time analytics and reporting
  • Fraud detection workflows
Component detail
  • Event ingestion service (current on-prem Kafka cluster)
  • Data warehouse (legacy on-prem RDBMS)
  • Downstream reporting and analytics layer
Data and security impact
  • Customer PII flows through the new event pipeline; encryption at rest and in transit is required
  • Audit logging must support SOC 2 and ISO 27002 compliance
  • Data retention policy needs to be re-evaluated for streamed events
Recommendations
  • Migrate to AWS Kinesis + Snowflake for event streaming and warehousing
  • Enforce TLS 1.3 between event producers and the ingestion layer
  • Begin the ISO 27002 certification roadmap with the Security team
Roadmap impact
  • Adds approximately 6-8 weeks to the current implementation timeline
  • Prerequisite for the Q3 product launch milestone
  • Requires coordination with the Security team for compliance review