답변.

질문 배경:

명확한 통합 사양의 필요성은 기업의 IT 환경 발전과 함께 나타났습니다. 비즈니스 프로세스가 여러 가지 서로 다른 소프트웨어 제품과 서비스에 의존하게 되면서 90년대에는 데이터 교환을 위해 종이 문서와 수동 데이터 내보내기가 널리 사용되었습니다. 이후 EDI 교환 및 통합 플랫폼이 등장했습니다. 현재 인터페이스 사양은 효과적인 상호작용을 조직하는 데 중요한 역할을 합니다.

문제:

상세하게 작성된 통합 사양이 없으면 팀 간의 오해, 불완전한 데이터 처리, 중복 작업 또는 심지어 비즈니스 프로세스 실패가 자주 발생합니다. 질문은 다음과 같습니다: 시스템 수명 주기 동안 두 개 또는 그 이상의 당사자가 요구 사항을 명확하게 이해할 수 있도록 사양을 어떻게 문서화하고 유지해야 합니까?

해결책:

시스템 분석가는 공식적인 설명 표준(예: OpenAPI, WSDL, XSD, BPMN), 템플릿 및 모델링 도구를 사용하여 통합 사양을 개발합니다. 사양에는 반드시 다음이 포함됩니다:

• 메시지 구조, 데이터 형식, 오류 처리 규칙
• 상호작용의 비즈니스 시나리오 및 보안 요구 사항 설명
• SLA, 모니터링 및 이벤트 로깅 요구 사항
• 각 릴리스마다 문서 업데이트 및 유지 보수 규정

주요 특징:

• 각 참여 시스템의 책임 영역을 명확히 구분.
• 인터페이스 설명에 공식 언어 사용.
• 통합 생애 주기 동안 사양 유지 및 업데이트.

트릭 질문들.

동기식 시스템 간의 상호작용과 비동기식 상호작용의 차이는 무엇이며, 항상 비동기 방식이 고장에 강한가요?

비동기 교환은 실제로 응용 프로그램의 결합도를 낮추고 대기열 덕분에 더 강할 수 있지만, 모든 시나리오에서 최적은 아닙니다: 높은 응답 시간 요구사항이나 트랜잭션성을 가진 요청에는 동기식 상호작용이 더 적합합니다.

API 설명 및 데이터 구조만으로 시스템 간의 통합을 완전히 이해할 수 있습니까?

아니요, 비즈니스 시나리오, 오류 처리 모델, 모니터링 요구 사항, SLA, 지연 허용 및 버전 관리 합의도 문서화해야 합니다.

통합 형식 변경 시 팀 간의 구두 합의에만 의존할 수 있습니까?

아니요, 모든 변경 사항은 사양에 공식화되고 서면으로 합의해야 하며, 그렇지 않으면 실행 불일치와 잠재적인 사고의 위험이 있습니다.

일반적인 실수 및 안티 패턴

• 팀 간의 사양 버전 불일치
• 예외 및 비정상 상황 문서화를 소홀히 함
• 변경 후 사양 업데이트를 게을리 함

실생활 예시

부정적인 사례: 고객이 API의 데이터 형식을 변경했지만 이메일로 파트너 팀에만 통보했습니다. 다른 통합 시스템의 개발자는 이를 고려하지 않았고 일부 트랜잭션이 처리되지 않았습니다. 장점:

• 혁신을 신속하게 도입 단점:
• 고장이 발생했으며, 데이터 복구가 긴급히 필요했고, 시간과 비용이 소요되었습니다.

긍정적인 사례: 분석가는 변경 요청을 작성하고 Swagger 사양을 업데이트했으며, 내부 채팅을 통해 모든 관련 팀에 변경 사항을 알리고 변경 사항 구현 확인을 기다렸습니다. 장점:

• 모든 측이 변경 사항에 대해 사전에 알고 있었습니다.
• 오류 위험이 줄어들었습니다. 단점:
• 합의하는 데 더 많은 시간이 필요했습니다.