프레임웍스
Frameworx |
Frameworx는 통신 서비스 제공업체에 맞춘 엔터프라이즈 아키텍처 프레임워크다.
그것은 TM 포럼에 의해 개발되었다.
구조
Frameworx는 네 가지 프레임워크로 구성된다.
- 애플리케이션 프레임워크(TAM(Telecom Application Map)라고도 함)
- eTOM(비즈니스 프로세스 프레임워크)
- 정보 프레임워크(공유 정보/데이터(SID) 모델이라고도 함)
- 통합 프레임워크(TM Forum Integration Program(TIP)에서 개발됨)
정보 프레임워크
정보 프레임워크(공식적으로 공유된 정보/데이터 모델 또는 SID)는 통신의 비즈니스 객체에 대해 단일의 용어를 제공하는 통일된 참조 데이터 모델이다. 목표는 서로 다른 부서, 기업 또는 지리적 위치에 있는 사람들이 동일한 용어를 사용하여 동일한 실제 세계의 객체, 관행 및 관계를 설명할 수 있도록 하는 것이다. 그것은 프레임웍스의 일부분이다.
Frameworx 정보 모델로서 정보 프레임워크는 정보/데이터 참조 모델과 비즈니스의 공통 정보/데이터 어휘 및 시스템 관점을 제공한다. 정보 프레임워크는 특정 이해관계자 관점의 필요성 표현을 공식화하기 위해 통합 모델링 언어를 사용한다.
정보 프레임워크는 Frameworx 라이프사이클에 정의된 대로 Framewox 관점 - 비즈니스, 시스템, 구현 및 배치로 대표되는 4대 유권자 그룹(스테이크 소유자)의 우려를 전달하기 위한 공통 언어를 제공한다. eTOM(비즈니스 프로세스 프레임워크) 비즈니스 프로세스 및 활동 설명, Telecom Application Map(통신 애플리케이션 맵)과 함께 사용됨 정보 프레임워크는 비즈니스가 이해할 수 있는 정의를 제공하여 조직 내에서 비즈니스와 정보 기술 그룹 간의 브리지가 가능하도록 한다.소프트웨어 개발에 사용될 만큼 혐오스러운.
정보 프레임워크 모델은 다양한 산업 출처에서 영감을 얻지만, 그 주요 기원은 AT&T와 BT 그룹의 빌 브룩이 이끄는 팀이 만든 제휴 공통 정보 아키텍처(ACIA)와 존 스트라스너가 만든 디렉토리 활성화 네트워크 - 차세대 네트워크(DEN-ng) 모델이다.
2000년에 처음 출시되었을 때, 정보 프레임워크 모델은 비즈니스(BSS) 분야와 기기 관리 분야를 잘 다루었지만, 논리적 네트워크와 용량을 나타내는 능력은 부족했다. 이러한 결함은 토폴로지와 같은 개념을 포함하도록 모델의 개정을 통해 해결되고 있지만, 이력은 재고관리와 같은 특정 통신 분야에서 모델을 제대로 활용하지 못하는 결과를 낳았다.
원칙
Frameworx는 이러한 핵심 원리를 기반으로 한다.
구성요소 구현과 비즈니스 프로세스 분리
OSS(Operations Support Systems)를 함께 연결하면, OSS가 지원하는 비즈니스 프로세스가 IT 환경에 분산된다. 실제로 일부 데이터를 처리한 후 애플리케이션 B를 호출해야 한다는 것을 알고 애플리케이션 A로 프로세스가 시작되는 상황에 도달하고, 애플리케이션 B도 일부 처리를 한 다음 C 등을 호출한다. 그 결과 이러한 흐름들 중 실제로 어디에 있는지 이해하는 것이 매우 어렵다(예: 프로세스 흐름이 고객 주문을 받기 위한 것이라면 애플리케이션 A 또는 B 또는 C가 현재 해당 주문을 처리하고 있는가?) 그리고 분산된 특성 때문에 프로세스를 변경하는 것은 더욱 어렵다.
Frameworx는 애플리케이션 간의 비즈니스 프로세스 흐름을 제어하는 워크플로우 엔진을 사용하여 프로세스를 중앙 집중화된 인프라의 일부로 관리할 것을 제안한다. 따라서, 워크플로 엔진은 애플리케이션 A에 대한 프로세스를 시작하여 제어 권한을 워크플로 엔진으로 되돌리고 애플리케이션 B를 호출하는 등의 작업을 시작할 것이다. 이러한 방식으로 중앙 워크플로 엔진에 의해 제어되며, 엔진의 프로세스 정의 도구를 사용하여 프로세스를 수정할 수 있기 때문에 개별 프로세스 흐름이 어디에 있는지 항상 확인할 수 있다. 분명히 일부 하위 수준의 프로세스 흐름은 개별 애플리케이션에 포함될 것이지만, 이는 비즈니스 유의적인 처리 수준(즉, 비즈니스 정책과 규칙이 구현되는 수준 미만)보다 낮아야 한다. Frameworx 인증 방법론은 고객이 수용한 적절한 방법을 개선하기 위한 개구부로서 선형적으로 배포되지 않는 선호 범위를 다루는 데 도움이 된다.
느슨하게 결합된 분산 시스템
"루즈하게 결합"은 각 애플리케이션이 전체 시스템의 다른 애플리케이션과 상대적으로 독립적이라는 것을 의미한다. 따라서 느슨하게 결합되는 환경에서는 한 가지 적용이 변경되지 않고 변경될 수 있다. 극단적으로 보면, 이것은 때때로 응용 프로그램을 "플러그 앤 플레이"할 수 있는 능력을 생산한다고 볼 수 있는데, 응용 프로그램이 너무 독립적이어서 전체 시스템 동작에 영향을 주지 않고 변경될 수 있다. 그 극한은 현재로선 있을 것 같지 않은 열반으로 여겨진다.
「분산 시스템」은, 프레임웍스가 모든 활동을 관리하기 위해 단일의 단일 어플리케이션을 이용하는 통신 서비스 프로바이더(CSP)를 기반으로 하는 것이 아니라, 그 대신, 일련의 통합·공동 운영 어플리케이션을 이용하고 있음을 강조하고 있다.
OSS를 통합한다는 것은 애플리케이션 간에 데이터를 공유해야 한다는 것을 의미한다. 이것이 효과적이 되려면, 각 애플리케이션은 공유되는 데이터의 해당 부분을 다른 애플리케이션들이 어떻게 이해/해석하는지 이해해야 하며, 또는 공유된 데이터의 공통 모델이 있어야 한다. 이를 이해하려면 고객 주문 입력 절차를 거친 주문 처리 응용 프로그램과 애플리케이션 B(청구 시스템)를 사용하여 청구서를 보내야 하는 위치를 고려하십시오. 신청서 A는 고객주소에 대한 기록을 가지고 있으므로 신청서 B가 청구서를 이 주소로 보내는지 확인할 필요가 있다. 시스템 간에 이 데이터를 전달하려면 주소 정보에 대한 공통 형식이 필요하다. 각 시스템은 동일한 수의 주소 회선을 예상해야 하며 각 행의 길이는 같다. 그것은 꽤 간단하다. 그러나 주문 애플리케이션이 구리선, 모뎀, 필터 세트 및 광대역 변환으로 이루어진 제품(예: 동선, 모뎀, 광대역 전환으로 만든 광대역 액세스 제품)에서 작동할 경우 발생하는 어려움을 상상해 보십시오. 반면에 청구 애플리케이션은 단일 제품/주문 라인만 기대했다. 정보를 잃지 않고 계층적 제품을 비계층적 제품으로 전환하려고 하는 것은 불가능할 것이다. 이러한 방식으로 애플리케이션 간에 공유되는 데이터에 대한 단일 정보 모델은 이 문제에 대한 해결책을 제공한다. 이에 대한 TMF 솔루션을 Shared Information/Data-Model(SID)이라고 한다.
공통 통신 인프라
1980년대 중반까지 컴퓨터 기반 OSS는 독립형 애플리케이션으로 개발되었다. 그러나 1990년대 초에는 이러한 애플리케이션을 순수하게 격리된 애플리케이션으로 사용하는 것이 매우 비효율적이라는 것이 명백해졌다. 예를 들어, 한 시스템에서 주문이 이루어지지만, 관련 네트워크 장비를 구성하기 위해서는 세부 정보를 다른 시스템으로 다시 연결해야 하는 상황이 발생했기 때문이다. 독립형 OSS를 함께 연결함으로써 주요 효율성 이득을 얻을 수 있는 것으로 나타났는데, 이는 주문을 온라인으로 할 수 있고 사람이 개입하지 않아도 장비가 자동으로 공급되는 "Flow-through provisioning"과 같은 기능을 가능하게 하는 것으로 나타났다.
그러나, 수백 개의 개별 OSS가 많은 대형 사업자의 경우, 인터페이스의 확산이 심각한 문제가 되었다. 각 OSS는 다른 많은 OSS와 "대화"할 필요가 있어, OSS의 수의 제곱과 함께 인터페이스의 수가 증가하게 되었다.
Frameworx는 CCI(Common Communications Infrastructure)의 사용을 설명한다. 이 모델에서 OSS는 서로 직접 연결하기 보다는 CCI와 접속한다. 따라서 CCI는 응용 프로그램이 CCI를 사용하여 함께 연동되도록 한다. 이러한 방식으로, 각 애플리케이션은 (다른 애플리케이션에 대한) 많은 인터페이스가 아닌 하나의 인터페이스(CCI에 대한)만 필요로 한다. 따라서 복잡성은 n이2 아닌 n 순서의 하나로 감소한다.
CCI는 보안, 데이터 변환 등을 포함한 다른 서비스도 제공할 수 있다.
계약 정의 인터페이스
CCI에 대한 애플리케이션 인터페이스의 방법에 대한 위의 설명을 고려할 때, 채택된 기술 측면(예: Java/JMS 또는 웹 서비스/SOAP인가?)뿐만 아니라 애플리케이션의 기능, 사용된 데이터, 사전 조건 및 사후 조건 등의 측면에서 이러한 인터페이스를 문서화하는 방법이 필요하다는 것은 명백하다. Frameworx 계약 명세서는 이러한 인터페이스를 문서화할 수 있는 수단을 제공하며, 따라서 이것들은 계약으로 정의된 인터페이스들이다.
프레임웍스 계약은 API(응용프로그램 인터페이스) 규격의 확장으로 볼 수 있다.
결과물
프로세스 모델
eTOM(Enhanced Telecom Operations Map, e-tom 발음)은 Frameworx 비즈니스 프로세스 프레임워크다.
Frameworx 정보는 공유 정보/데이터 모델(SID)이다.
라이프사이클 모델
Frameworx 라이프사이클 모델[1]은 조직 내에서 Frameworx의 사용과 배치를 정의하는 것을 목표로 하며, SID, eTOM 및 Frameworx 아키텍처를 사용하기 위한 프레임워크를 제공한다. 이 모델은 Zachman Framework, Kernighan, Yourdon, 그리고 Object Management Group의 Model Driven Architecture를 포함한 상당한 초기 작업에 기반을 두고 있다. Frameworx 라이프사이클은 시스템 개발을 요구사항, 시스템 설계, 구현 및 운영의 4단계로 나눈다.
계약 사양
앞에서 설명한 바와 같이, 프레임웍스 계약은 프레임웍스 시스템에서 상호운용성의 기본 단위다. 상호운용성은 Frameworx 라이프사이클에 의해 정의된 네 가지 뷰 각각에 중요하다. 예를 들어, 이 계약은 제공될 서비스를 정의하고, 서비스를 구현하는 정보와 코드를 명시하는 데 사용된다. 또한 이 계약은 서비스를 감시, 관리 및 유지하고 계약의 모든 외부 의무(예: SLA(서비스 수준 계약)가 충족되는지 확인하고, 어떤 식으로든 위반될 경우 어떤 조치를 취해야 할지를 정의하는 데에도 사용된다.
텔레콤 어플리케이션 맵
Applications Framework (formal Telecom Application Map (TAM)))는 주요 Frameworx 아티팩트 중 하나이다. OSS(Operations Support System)와 BSS(Business Support System) 역량을 전달하는 다양한 애플리케이션의 역할과 기능을 고려한다.
그렇게 함으로써 조달 문서를 프레임워크를 참조하여 작성할 수 있도록 하여, 주어진 애플리케이션에 필요한 기능성, 식별해야 할 기존 애플리케이션의 기능적 중복에 대한 명확하고 모호하지 않은 진술을 제공하여 합리화와 기능적 격차를 식별하는 것을 용이하게 한다.
기능적 분해의 수준은 이러한 편익이 실현될 수 있지만 지나치게 규범적이지는 않다.
TM 포럼 내에는 프로세스와 데이터에 대한 강력한 정의가 있다. 애플리케이션 프레임워크는 기능과 데이터를 인식된 구성요소로 그룹화하는 공식화된 방법을 제공하며, 이는 애플리케이션 또는 서비스 중 하나로 잠재적으로 실행 가능한 것으로 간주될 수 있다. 애플리케이션이나 서비스(예: 웹 서비스)는 기능/프로세스를 구현하고 데이터에 대해 작용하거나 사용하는 비교적 거친 소프트웨어일 수 있다. 일상 생활에서 우리는 워드 프로세서나 메일 클라이언트와 같은 애플리케이션을 본다; OSS 용어로 우리는 애플리케이션을 CRM 구성 요소, 청구 시스템 또는 재고 솔루션과 같은 것으로 간주할 것이다. 비록 우리는 이것들이 어느 정도 분해될 수 있다는 것을 이해하지만, 예를 들어 청구 시스템에는 다수의 더 작은 애플리케이션이 포함될 것이다.s(예: 등급 엔진).
"응용프로그램"은 잘 정의된 기능, 데이터, 비즈니스 흐름, 규칙 및 인터페이스로 구성된 하나 이상의 소프트웨어 아티팩트의 집합으로 정의된다. 여기에는 애플리케이션과 인터페이스하기 위해 사용되는 데이터, 외부 및 내부 애플리케이션 리소스를 제어하기 위한 정책, 애플리케이션 내부의 기능에 대한 외부 가시적 인터페이스에 대한 애플리케이션 및 계약 사양에 대한 플로우 모델이 포함된다.
애플리케이션은 배포 가능한 패키지로 구현 가능하며 시스템 시장에서 사용할 수 있다.
애플리케이션 프레임워크는 정보 프레임워크나 eTOM(비즈니스 프로세스 프레임워크) 정의의 일부가 아니며, 쉽게 이해할 수 있는 방식으로 둘 다에 연결되며, 이들 간의 매핑도 제공한다.
외부 링크
다른 정보
mTOP는 통신 네트워크의 관리 인터페이스의 정의를 다루는 텔레 매니지먼트 포럼(TM Forum) 내의 프로그램이다. mTOP는 자원과 서비스 관리를 모두 다룬다.
