고전적인 시스템 분석에서 중요하게 여기는 것은 설계하는 시스템의 경계가 어디인지 — 어떤 기능이 내부에서 실행되고, 어떤 것이 외부 서비스에 맡겨지며, 이들과의 통합이 어떻게 이루어지는지를 올바르게 정의하는 것입니다. 대규모 프로젝트에서는 이 단계가 아키텍처를 단순화하고 리스크를 최소화하는 데 매우 중요합니다.
70년대와 80년대에 대규모 시스템을 분석하면서 잘못된 경계 설정이 비용이 많이 드는 통합 후속 작업과 아키텍처의 혼란을 초래한다는 사실이 분명해졌습니다.
너무 넓거나 좁은 시스템 경계는 유지 관리를 복잡하게 하고, 통합 수를 증가시키며, 데이터의 불일치를 초래하게 만듭니다.
Context Diagram(컨텍스트 다이어그램)과 Service Responsibility Matrix를 사용하여 기능과 책임을 분배합니다. 시스템의 경계가 회사의 실제 구조와 일치하도록 비즈니스 목표에 집중해야 합니다.
항상 가장 높은 자율성을 지향해야 하나요?
아니요, 때때로 중복을 피하기 위해 다른 시스템에 일부 기능을 위임하는 것이 더 효과적입니다.
분석가는 모든 통합을 위한 데이터 형식을 구현 시작 전에 정의해야 하나요?
아니요, 이는 고급 디자인 단계에서 수행됩니다. 자세한 형식은 이후에 아키텍트 및 통합자와 협력하여 작업합니다.
같은 기능이 여러 시스템에서 구현되는 것이 매우 나쁜가요?
이는 중복, 동기화 비용 및 데이터 완전성 손실을 초래하므로 이러한 교차점을 피해야 합니다.
부정적인 사례:
회사의 구조를 고려하지 않고 시스템을 설계하고, 어떤 기능이 내부에서 실행될 것인지, 어떤 기능이 다른 서비스에 있을 것인지 명확히 정의하지 않았습니다.
장점: 프로젝트 설계의 빠른 시작, 최소한의 자원 소모.
단점: 많은 중복 통합, 데이터 교환의 지속적인 문제, 팽창된 아키텍처를 초래하였습니다.
긍정적인 사례:
시스템 분석가가 컨텍스트 다이어그램을 개발하고 비즈니스 및 아키텍트와 시스템 경계를 조율하여 통합 상호 작용을 최소화하였습니다.
장점: 투명한 아키텍처, 적은 통합 버그, 편리한 유지 관리.
단점: 시작할 때 방대한 준비 작업이 필요하고 모든 관련 시스템에 대한 전문 지식이 요구됩니다.