타스크: 기존 자산 분석
이 타스크는 서비스 지향 솔루션의 디자인 요소를 서비스 및 파티션 관점에서 식별하고 해당 서비스의 초기 스펙을 문서화합니다.
목적
  • 서비스 지향 솔루션의 디자인 요소를 서비스 및 파티션 관점에서 식별합니다.
  • 초기 서비스 스펙을 문서화합니다.
  • 초기 종속성과, 서비스 간 통신을 결정합니다.
관계
기본 설명
기존 자산 분석은 서비스의 실현(realization)을 완료하기 위해 산업 표준, 모델 및 자산 뿐 아니라 기존 자산을 레버리지하는 프로세스(예: 패키지 응용프로그램 또는 사용자 정의 응용프로그램과 같은 기존 시스템)입니다. 상향식 접근 방식을 사용하여 기존 자산 분석에서 후보 서비스, 컴포넌트 및 플로우를 식별하고 유효성 검증합니다. 기존 시스템과 관련된 기술적 제한조건은 위험성 관리를 위해 가능한 한 빨리 평가해야 합니다. 따라서 서비스 실현(realization) 결정의 기술적 실현 가능성 처리는 기존 자산 분석 후/중에 가능한 한 빨리 이루어집니다.
단계
사용자 정의 응용프로그램에서 후보 서비스 식별

두 하위 단계는 기존 응용프로그램에서 제공된 기능성을 식별하는 데 사용됩니다. 첫 번째 하위 단계인 덜 세분화된 맵핑에서는 기존 응용프로그램의 포트폴리오에 비즈니스 프로세스를 맵핑합니다. 두 번째 하위 단계인 세분화된 맵핑에서는 레거시 응용프로그램에 있는 특정 트랜잭션 또는 일괄처리 프로세스에 서비스를 맵핑합니다. 세분화된 맵핑은 서비스 스펙에서 처리됩니다.

덜 세분화된 맵핑의 목적은 서비스에 대한 비즈니스 기능의 사전(예: 초기) 맵핑을 도출하는 것입니다.

기존 응용프로그램의 기능성에서 응용프로그램 후보 서비스를 식별하려면 비즈니스 프로세스와 기존 응용프로그램 간의 관계를 이해해야 합니다. 이것은 덜 세분화된 맵핑으로 설명할 수 있습니다. 이 맵핑은 아래에 표시된 대로 비즈니스 활동 또는 비즈니스 프로세스와 기존 응용프로그램의 비즈니스 기능 사이에 있습니다.

비즈니스 프로세스와 기존 응용프로그램 간의 관계를 캡처하려면 다음의 덜 세분화된 맵핑 단계를 수행합니다.

  1. 각 응용프로그램에서 지원되는 비즈니스 기능을 이해합니다.  일반적으로 비즈니스 기능은 비즈니스 프로세스에 있는 활동에 맵핑할 수 있습니다.
  2. 기존 응용프로그램의 속성을 사용한 기술, 아키텍처 스타일 등이라는 점에서 기록합니다.
  3. 공통 서비스를 수행하는 응용프로그램을 식별합니다.

덜 세분화된 맵핑 및 응용프로그램 포트폴리오를 분석합니다.

기존 응용프로그램의 비즈니스 가치와 기술 품질을 이해하면 최고 가치의 서비스에 제공된 최고 우선 순위의 변환 계획을 작성하고 응용프로그램의 기술 품질(예: 결합도)을 기반으로 한 범위 및 기술적 위험성을 평가하는 데 도움이 됩니다.

응용프로그램 포트폴리오 분석에서는 덜 세분화된 맵핑의 범위 및 경계를 제공합니다. 예를 들어, 아주 낮은 비즈니스 가치 또는 낮은 기술적 가치를 가진 노후화된 응용프로그램은 후보 서비스 식별 범위에 없을 가능성이 높습니다.

응용프로그램 포트폴리오 분석으로(수행한 경우) 덜 세분화된 맵핑을 위해 기존 서비스에 대한 정보가 제공됩니다. 이 분석의 결과는 아래 표시와 같은 후보 서비스입니다.

패키지된 응용프로그램에서 후보 서비스 식별

독립된 소프트웨어 벤더(ISV) 패키지는 일반적으로 조직 내의 서브시스템 및/또는 서비스 컴포넌트를 사용할 수 있도록 구현됩니다. 예를 들어, 포괄적인 엔터프라이즈 자원 조달 계획(ERP) ISV 패키지(예: SAP, PeopleSoft 및 Oracle 제공 패키지)는 조직에 있는 하나 이상의 도메인을 모두 지원하는 다중 서브시스템을 구성하는 전체 시스템으로 구현됩니다. 이 섹션에서는 종사자(practitioner)가 기존 ISV 패키지에 있는 기능성 및 후보 서비스를 식별할 수 있는 일련의 단계를 설명합니다. 이 분석으로 비즈니스 기능/시스템 매트릭스, 비즈니스 규칙 카탈로그 및 서비스 모델 중간 산출물을 기존 ISV 패키지의 기능을 기반으로 사용할 수 있습니다.

참고: 각 ISV 패키지는 서로 다르기 때문에 각각에 대해 세부적으로 규정된 접근 방식을 개발할 수 없습니다. 다음 활동에서는 일반 접근 방식 및 일반 활동 세트를 설명합니다.

  • ISV 패키지에 있는 후보 서비스를 식별합니다.
  • 서비스 실현(realization) 중에 고려할 ISV 패키지의 상위 레벨 특성을 식별합니다.

ISV 패키지 식별

범위 내의 도메인 및 비즈니스 컴포넌트를 위한 ISV 패키지는 비즈니스 컴포넌트 오버레이 입력에 대한 CBM 시스템(또는 이와 동등한)에서 식별해야 합니다. 이 결과는 ISV 패키지의 목록에 있으며 이 패키지는 예상 솔루션 범위에 있는 특정 비즈니스 컴포넌트의 기능성을 사용합니다. 이 입력 내용이 누락되는 경우, 범위 내의 도메인 및 비즈니스 컴포넌트를 지원하는 ISV 패키지를 식별하고 비즈니스 컴포넌트에 맵핑해야 합니다.

일부 ISV 패키지(예: SAP, PeopleSoft 및 Oracle)는 많은 코어 및 선택적 모듈로 구성되어 있습니다. 예를 들어, SAP에는 제조 모듈, 인적 자원 모듈 및 고객 관계 관리 모듈이 있습니다. 이러한 경우에는 사용할 ISV 패키지의 특정 모듈 종류를 지정해야 합니다. 이 결과로 시간을 절약하고 불필요한 서비스 확대를 막는 데 초점을 맞춘 분석이 이루어집니다.

ISV 패키지 분류

ISV 패키지의 분류로 서비스 실현(realization) 중에 고려할 중요한 특성을 쉽게 간파할 수 있습니다(기능적 및 기술적 컴포넌트 모두에 해당). ISV는 표 10에 요약된 특성(예: 해당 코어 역량, 크기 및 수익)을 기반으로 한 계층 1, 2 또는 3 ISV로 분류할 수 있습니다. 특히 기술적 영향 및 비즈니스 영향 형태에 유의하십시오.

ISV 카테고리 계층 1 ISV 계층 2 및 3 ISV
설명 패키지된 응용프로그램을 제공하는 엔터프라이즈 자원 조달 계획(ERP) 벤더와 같은 대규모 ISV로 인해 비즈니스에서 해당 코어 자원 및 오퍼레이션을 관리할 수 있습니다. 중소 규모의 ISV에서는 산업별 수직적(vertical) 비즈니스 솔루션을 제공합니다.
특성
  • 제품 계획, 파트 구매, 유지보수 인벤토리, 공급자와의 상호 작용, 고객 서비스 제공 및 트래킹 순서에 필요한 통합, 다중 모듈, 전체 산업용 응용프로그램
  • 비즈니스의 재정 및 인적 자원 형태에 필요한 응용프로그램 모듈도 포함할 수 있습니다.
  • CBM 맵에서 다중 비즈니스 컴포넌트 및 도메인 스팬
  • 고유 미들웨어, 보안 및 기타 기술적 컴포넌트로 패키지화
  • 일반적으로 엔터프라이즈에 있는 특정 기능을 지원하는 산업별 수직적(vertical) 서브시스템을 사용합니다.
  • 일반적으로 하나 이상의 계층 1 ISV가 있는 비즈니스 인터페이스를 문서화합니다.
  • 대개 CBM 도메인 및 적은 수의 비즈니스 컴포넌트에 포함됩니다.
  • 대개 외부, 써드파티 미들웨어 및 기타 기술적 컴포넌트에 따라 다릅니다.
  • 고유의 보안 컴포넌트가 있습니다.
기술적 영향 대규모 "풋프린트"가 제공되는 경우, 이 ISV는 조직에서 사용한 기술적 아키텍처 및 표준에 큰 영향을 줄 수 있습니다. 이 경우, 이러한 영향력은 서비스 실현(realization) 중에 식별하고 고려합니다.
서비스 실현(realization) 중에 미들웨어 및 기타 기술적 컴포넌트(예: 인증 및 로깅)를 고려해야 합니다.
이러한 ISV는 일반적으로 대규모 조직의 아키텍처 면에 미치는 영향이 작은 편이고, 더 작고 전문화된 산업별 조직에서는 이 ISV가 서비스 실현(realization)에 큰 영향을 미칩니다.
이러한 패키지에서는 고유 미들웨어 또는 기술적 컴포넌트를 제공하지 않습니다. 이 패키지는 써드파티 미들웨어 및 기술적 컴포넌트에 따라 다르거나 계층 1 ISV에서 제공된 앞의 미들웨어 및 컴포넌트에 따라 다를 수 있습니다. 일부 소규모 ISV에서는 기술적 컴포넌트에 인터페이스를 제공할 수 없습니다. 이 패키지는 써드파티 미들웨어 및 기술적 컴포넌트에 따라 다르거나 계층 1 ISV에서 제공된 앞의 미들웨어 및 컴포넌트에 따라 다를 수 있습니다. 일부 소규모 ISV에서는 기술적 컴포넌트에 인터페이스를 제공할 수 없습니다.
비즈니스 영향 계층 1 ISV에 투자한 조직에는 이 ISV 패키지를 가능한 한 전체 범위로 레버리지하는 경향이 있습니다. 이러한 경우, 기존 패키지를 사용하여 서비스를 실현하고 새 서비스를 사용하는 경향이 강합니다. 이러한 패키지에서는 더 좁은 범위의 기능성을 사용하기 때문에 이러한 패키지를 확장하여 새 서비스를 실현하는 경향 및 기회가 적어집니다.
예제 SAP, Siebel, Peoplesoft, Oracle Financials Manugistics, Provia, Evoke/TD>

ISV 패키지가 가상으로 모든 조직에서 사용되기 때문에 대부분의 서비스 지향 솔루션은 ISV 패키지를 기반으로 한 서비스 컴포넌트를 통해 실현된 서비스를 통합합니다. 이 패키지를 분류하면 종사자(practitioner)는 SOA 솔루션에 있는 이 패키지의 역할 및 관련 중요성을 이해할 수 있으며 또한 서비스 실현(realization) 중에 고려할 기술적 및 기능적 특성을 식별할 수 있습니다.

각 ISV 패키지의 경우, 분류 중에 수행된 분석을 통해 다음 영역을 이해할 수 있습니다.

  1. 엔터프라이즈에 있는 이 ISV 패키지의 중요성 및 영향력에 대한 이해
  2. 이 ISV 패키지를 통해 새 서비스를 모두 실현하는 경향
  3. 엔터프라이즈에 있는 ISV 패키지 및 해당 역할에서 사용한 아키텍처 표준 및 기술적 컴포넌트
  4. ISV 패키지와 호환 가능한 미들웨어 및 기술적 컴포넌트의 이해

ISV 패키지에 있는 서비스 액세스를 위한 옵션 분석

이 단계에서는 ISV 패키지의 기능에 액세스 가능한 메커니즘을 식별합니다(예: 서비스 공개 및 실현(realization)과 직접 관련된 패키지의 기술적 형태). 이 정보는 ISV 패키지의 후보 서비스를 식별하는 데 사용되고(다음 단계) 후에 기술적 실현 가능성을 평가하고 서비스 실현(realization)을 결정하는 데 사용됩니다.

여러 메커니즘을 ISV 패키지에 액세스하는 데 사용할 수 있습니다. 이 단계에서 범위 패키지의 각 패키지를 분석하여 이 패키지에 사용할 수 있는 메커니즘을 결정하고 설명합니다. 일반적으로 ISV 패키지는 다음과 같은 하나 이상의 메커니즘을 지원합니다.

메커니즘 설명
서비스로 직접 공개 패키지는 SOA 호환 가능 서비스를 사용하여 기능성을 직접 공개하며 이것이 일반적으로 웹 서비스입니다. 이 서비스는 카탈로그에 열거할 수 있습니다. 특정 구현은 표준 및 상호운용성에 대한 준수를 위해 평가합니다.
API 사용 패키지에는 패키지의 서비스를 공개하는 데 사용할 하나 이상의 API가 제공됩니다. 이 API는 서비스로서의 기능성을 공개하는 데 직접 사용 가능하거나 웹 서비스 랩퍼 또는 Facade를 API를 통해 기능성에 액세스할 수 있도록 개발할 수 있습니다.
직접 데이터 액세스 API를 사용할 수 없는 경우, 서비스가 ISV 패키지에서 관리되는 데이터를 공개해야 하며 패키지에서 사용된 데이터베이스에 직접 액세스하도록 개발됩니다.
참고: 이 접근 방식은 기술적으로 실현 가능한 반면, ISV 패키지의 비즈니스 로직을 생략하면 데이터가 손상될 잠재적인 위험성이 생기거나 프로그램의 데이터 무결성 적용이 방해를 받게 됩니다. 이 때문에 이 기법은 "읽기 전용" 오퍼레이션을 수행하는 서비스에는 사용을 제한하는 것이 좋습니다. 그렇다 하더라도 이 접근 방식은 ISV의 데이터 스키마가 언제든 변경될 수 있기 때문에 여전히 위험성이 있으며 따라서 매우 주의해서 사용해야 합니다.

ISV 패키지 서비스 식별 기법

이 단계에서 여러 기법이 ISV 패키지를 분석하고 서비스로 공개할 수 있는 기능성을 식별하는 데 사용됩니다. 기능성과 연관된 비즈니스 규칙 또한 식별됩니다. 각 기법은 여러 Perspective에서 패키지를 평가하는 데 사용되며, 이 기법으로 패키지를 후보 서비스에 대해 전체적으로 분석할 수 있습니다. 분석 결과는 비즈니스 기능/시스템 매트릭스 및 비즈니스 규칙 카탈로그 중간 산출물에서 캡처됩니다. 기타 SOMA 식별 활동에 대해 후보 서비스는 서비스 포트폴리오 및 서비스 계층 구조에 추가됩니다.

  1. 사전 정의된 서비스의 ISV 패키지 카탈로그 검토

    일부 ISV 패키지에는 사전 정의된 서비스의 카탈로그가 제공됩니다. 이 경우, 범위 내 도메인 및 비즈니스 컴포넌트의 후보 서비스가 카탈로그를 통해 식별되고 서비스 포트폴리오에 추가됩니다. ISV에서 지원되는 경우, 이 기법은 ISV 패키지를 사용하여 후보 서비스를 식별하는 가장 쉬운 방법을 나타냅니다.

    참고: SOMA 스펙 단계에서 이러한 서비스의 세분화 정도는 서비스 공개 결정의 일부로 간주됩니다. 따라서 SOMA 식별 중에 세분화 정도를 후보 서비스의 특성으로 캡처해야 합니다. ISV 패키지에서 실현된 서비스와의 결합 정도에 따라 달라지는 공개 서비스를 집계 또는 분해해야 합니다. 이 분석으로 또한 서비스 계층 구조에서 후보 서비스를 연계시킬 수 있습니다.
  2. ISV 패키지의 API 검토

    ISV 패키지에서는 패키지의 기능성에 액세스하는 데 사용 가능한 하나 이상의 API를 제공할 수 있습니다. 이 API를 점검하여 범위 내 도메인 및 비즈니스 컴포넌트에서 서비스 포트폴리오에 추가할 후보 서비스를 식별할 수 있습니다. 이러한 API를 통해 액세스 가능한 기능성이 서비스로 제공되지 않기 때문에 서비스 랩퍼 또는 Facade가 서비스로서 이 API 호출을 공개하도록 개발해야 합니다. 이 접근 방식의 유연성으로 단일 서비스의 두 개 이상의 API 호출 조합을 사용할 수 있으며 서비스 계층 구조의 서비스와 연계하도록 개발할 패키지에서 서비스를 사용할 수 있습니다. 이 경우, 종사자(practitioner)는 서비스 계층 구조의 서비스를 식별하고 이를 지원 기능성 및 패키지의 API 호출에 맵핑합니다.
  3. ISV 비즈니스 프로세스 맵과 워크플로우

    ISV 패키지에서 사용되는 비즈니스 프로세스 및 워크플로우는 전자 형식의 하드카피로 문서화할 수 있습니다. 이러한 아티팩트는 서비스 포트폴리오에 추가하기 위해 추가 후보 서비스를 식별할 수 있도록 점검해야 합니다. 특히, 이와 같이 검토하면 프로세스가 실행되는 워크플로우 컨텍스트 뿐 아니라 패키지에 있는 비즈니스 프로세스의 종단 간 보기를 사용해야 합니다. 이렇게 하면 모든 관련 후보 서비스를 식별할 수 있으며 서비스 실현(realization) 중에 고려할 비즈니스 프로세스 및 워크플로우가 식별됩니다.
  4. ISV 패키지의 서비스 경계 식별

    ISV 패키지는 비즈니스 프로세스를 지원하고 비즈니스 컴포넌트(기능 영역) 및 도메인과 연계된 범위의 데이터를 관리할 수 있도록 개발되었습니다. 이 비즈니스 컴포넌트는 ISV 패키지를 위해 "풋프린트" 또는 "서비스 경계"를 구성합니다. 하지만 특정 엔터프라이즈에서 ISV 패키지는 해당 패키지에 대한 전체 서비스 경계의 서브세트에서 구현할 수 있습니다. 종사자(practitioner)는 ISV 패키지의 전체 서비스 경계를 식별하여 패키지 서비스 경계에 있는 추가 서비스를 서비스 포트폴리오에 추가해야 하는지의 여부 결정합니다. 또한 종사자(practitioner)가 필요한 새 서비스를 ISV 패키지를 통해 실현해야 하는지의 여부를 결정할 수 있습니다.

    새 서비스가 서비스 지향 솔루션 사용에 필요하다고 결정한 경우, 종사자(practitioner)는 이 서비스가 ISV 패키지의 서비스 경계에 있는지의 여부를 결정합니다. 서비스 경계에 있는 경우, 필수 기능성을 지원하는 ISV 패키지의 서비스를 식별하고 서비스 포트폴리오에 추가합니다. 이렇게 하면 솔루션에서 ISV 패키지의 전체 기능을 레버리지하고 동일한 비즈니스 컴포넌트를 지원하는 다중 시스템에서 복제품을 개발하는 위험성을 줄일 수 있습니다.
  5. ISV 패키지에서 제어된 데이터 요소 분석

    솔루션 범위에 있는 데이터 요소는 ISV 패키지에서 관리할지 여부를 결정하기 위해 평가됩니다. 데이터를 ISV 패키지에서 관리하는 경우, 동일한 데이터를 읽거나 갱신하는 패키지의 기타 비즈니스 프로세스는 후보 서비스를 서비스 포트폴리오에 추가하기 위해 분석됩니다.

    이러한 분석으로 관련된 또는 외부 프로세스 및 서비스 실현(realization) 중에 고려할 솔루션의 영향을 받는 인터페이스를 표시합니다. 이 내용은 서비스 실현(realization) 중에 문서화 및 평가됩니다.
  6. ISV 보안 및 기타 기술적 컴포넌트 분석

    많은 ISV 패키지에는 인증 및 권한 부여를 위한 고유의 보안 컴포넌트가 있으며 로깅 및 메시지 전달과 같은 기능을 지원하는 기타 기술적 컴포넌트가 포함될 수 있습니다. 각 패키지의 경우, 이러한 컴포넌트는 서비스 포트폴리오에 추가할 기술적 후보 서비스를 식별할 수 있도록 식별하고 분석합니다.

    또한 이 분석 중에 이러한 컴포넌트에서 전해진 문제 또는 제한사항은 서비스 실현(realization) 중의 고려사항을 위해 식별됩니다. 예를 들어, 패키지 보안 컴포넌트의 상호작용은 패키지의 기능성을 액세스하는 데 필요하며 서비스 실현(realization)에서 이해하고 사용해야 합니다.

이러한 여러 분석 기법을 적용하면 범위 내의 ISV 패키지에 있는 후보 서비스를 서로 다른 Perspective에서 식별할 수 있습니다. 서비스 실현(realization) 중에 고려해야 할 ISV 패키지의 기능적 및 기술적 컴포넌트에서 전해진 문제 및 제한조건도 식별할 수 있습니다.

자산 비기능적 요구사항이 문서화되는지 확인

기존 자산을 위한 비기능적 요구사항 문서화 시, 다음 핵심 주제를 고려해야 합니다.

  • 예외 처리- 현재 예외 처리 방법을 이해해야 합니다. 일괄처리에서 예외가 발생하면 프로그램에서는 이상 종료되고(비정상적 종료) 코어 덤프를 생성합니다. 프로그래머는 코어 덤프를 찾아 처리해야 할 일을 판단해야 합니다. 이는 허용되지 않을 수도 있습니다. 누구든 처리해야 할 일(예: 예외 처리 프레임워크와 통합하는 방법)을 판단해야 합니다.
  • 프로세스 및 데이터 분배 - 데이터 및 프로세스가 실행되는 위치를 점검해야 합니다. 하나의 시스템에서 CICS 응용프로그램을 실행하면 다른 시스템에 대한 요청(CICS의 기능으로 알려짐) 또는 다른 시스템의 데이터 원격 호출을 송신할 수 있습니다. JDBC를 통해 DB로 연결되는 커넥터를 사용하는 대신, 프로세스 또는 데이터가 실행 중인 원격 시스템으로 직접 이동하는 것을 고려할 수 있습니다.
  • 데이터 가용성 - 4시간 유지보수 창이 필요한 VSAM에 고객 파일이 있는 경우, 24/7 고객 서비스를 지원할 수 없습니다. 새로운 저장영역 솔루션을 고려해야 합니다.
  • 권한 부여/인증 - 많은 레거시 응용프로그램에는 응용프로그램 코드의 권한 부여 및 인증 메커니즘이 있습니다. 이것으로 사용자 액세스 관리를 우수 사례에서 지원되는 연합 관리 환경으로 옮길 수 있습니다.
  • 스테이징 지연 - 일반적으로 일괄처리 프로그램은 하루 한 번 밤에 실행됩니다. 요구사항이 좀 더 자주 프로그램을 실행하는 것인 경우, 스케줄 프로그램을 수정하여 빈도를 변경합니다.
특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보