KR20090009813A - 패키지 생성 방법 및 컴퓨터 판독가능 매체 - Google Patents

Abstract

프로세스들의 인코딩들을 포함하는 이식 가능 패키지들이 설명된다. 패키지들은 이식 가능하며, 기술 스택과 다르다. 패키지들은 기술 스택을 구성하기 위한 선언 코드의 형태일 수 있으며, 기술 스택에 플러그 인되어 기술 스택이 패키지들을 실행하여 패키지들에 의해 인코딩된 프로세스들을 자동화하는 것을 가능하게 할 수 있다. 또한, 패키지들을 생성하기 위한 방법들, 패키지들을 실행하기 위한 기술 스택들, 패키지들을 로딩("플러그 인")하고, 또한 아마도 패키지들의 실행을 제어하기 위한 애플리케이션이 설명된다.

프로세스 인코딩, 이식 가능 패키지, 기술 스택, 선언 코드, 플러그 인

Description

패키지 생성 방법 및 컴퓨터 판독가능 매체{PROCESS ENCODING}

다수의 상이한 엔티티가 정보 기술(IT) 관리 프로세스들에 관한 안내서들을 편찬하였다. 예를 들어, IBM은 레드북 시리즈를 발간하였다. 영국의 IT 정보 도서관(ITIL)은 IT 서비스들을 관리하기 위한 벤더 독립적인 선호되는 실무들을 기술하고 있다. 마이크로소프트는 ITIL 지침들을 특정 소프트웨어 제품들에 적용하는 마이크로소프트 운영 프레임워크(MOF)를 제공하고 있다. 몇몇 조직은 인간 활동 및 자동화 양자를 종종 포함하는 그들 자신의 커스텀 IT 실무들 및 절차들을 가질 수 있다. 일반적으로, IT 시스템들 및 서비스들을 관리하기 위한 많은 상이한 선호되는 실무들이 존재한다. 이러한 실무들 중 일부는 예를 들어 IT 시스템의 변화를 관리하고, IT 사건들을 보고하고 그에 대응하는 것 등에 관한 것이다.

많은 IT 부서는 형식적인 IT 관리 프로세스들을 실무에 적용하는 데 문제들을 갖고 있음이 판명되었다. 몇몇 IT 부서는 ITIL 프로세스를 구현하는 데 수년을 소비할 수 있다. 프로세스 자동화를 지원하는 데 필요한 기반구조의 결여와 같은 기술적 문제들이 있을 수 있다. 구성 관리 데이터베이스(CMDB)가 필요하거나, 새로운 애플리케이션이 사용자의 컴퓨터 상에 배치되는 것이 필요할 수 있다. 또한, 새로운 프로세스의 학습, 직원의 재교육, 정보의 배포, 구현 상세들의 결정 등과 같은 인간적인 문제들이 존재할 수 있다. 일반적으로, 이러한 종류의 문제들은 IT 산업이 선호되는 또는 형식적인 IT 관리 실무들을 적합화하고 자동화하는 데 느렸던 이유를 부분적으로 설명할 수 있다.

물론, 많은 상이한 회사 또는 조직의 IT 부서들이 이러한 동일 문제들에 직면할 수 있다. 상당한 노력의 중복이 있을 수 있다. 2개의 상이한 IT 부서가 그들 각각의 IT 시스템 상에 동일한 비즈니스 프로세스 또는 IT 관리 프로세스, 예를 들어 자산 취득 프로세스를 구현하기를 원하는 시나리오를 고려한다. 이 부서들은 취득 프로세스(예를 들어, 회계 상세들, 승인 사슬, 통신 등)를 학습하고 이해하고, 새로운 프로세스를 수용하도록 그들의 기술을 구성하고, IT 사용자들 및 IT 관리자들에게 프로세스가 어떻게 구현되는지에 대한 지식을 제공하는 등의 대략 동일한 단계들을 거쳐야 한다. 현재는, IT 부서가 선호되는 IT 관리 프로세스를 효율적으로 또는 자동으로 구현할 수 있는 방법이 존재하지 않는다. 또한, 사람들이 IT 또는 비즈니스 프로세스들을 자동화하기 위한 기반 기술과 구별되는 방식으로 이러한 프로세스들의 인코딩들을 공유할 수 있는 방법이 존재하지 않는다.

<발명의 요약>

다음 요약은 단지, 아래의 상세한 설명에서 설명되는 소정의 개념들을 소개하기 위해 포함된다. 이 요약은 포괄적이 아니며, 끝에 제공되는 청구범위에 의해 설명되는 보호 가능한 내용의 범위를 기술하고자 하는 의도는 없다.

프로세스들의 인코딩들을 포함하는 이식 가능 패키지들이 설명된다. 패키지들은 이식 가능하며 기술 스택과 다르다. 패키지들은 기술 스택을 구성하기 위한 선언 코드의 형태일 수 있으며, 기술 스택에 플러그 인되어, 기술 스택이 패키지들 을 실행할 수 있게 함으로써, 패키지들에 의해 인코딩된 프로세스들을 자동화할 수 있다. 또한, 패키지들을 작성하는 방법들, 패키지들을 실행하는 기술 스택들, 패키지들을 로딩("플러그 인")하고, 또한 아마도 패키지들의 실행을 제어하는 애플리케이션이 설명된다.

많은 부수적인 특징들은 첨부 도면들과 관련하여 고려되는 아래의 상세한 설명을 참조함으로써 보다 쉽게 인식될 것이다.

첨부 도면들에서 동일 참조 번호들은 동일 부분들을 지시하는 데 사용된다.

도 l은 예시적인 IT 시스템을 나타내는 도면이다.

도 2는 패키지를 나타내는 도면이다.

도 3은 어떻게 패키지들이 프로세스들을 공유하는 데 사용될 수 있는지를 나타내는 도면이다.

도 4는 예시적인 패키지를 나타내는 도면이다.

도 5는 애플리케이션이 패키지를 기술 스택에 로딩하기 위해 수행할 수 있는 프로세스를 나타내는 도면이다.

도 6은 패키지를 플러그 인하기 위한 다른 프로세스를 나타내는 도면이다.

도 7은 기술 스택이 예시적인 패키지를 실행할 때의 예시적인 프로세스 흐름을 나타내는 도면이다.

도 8은 구성 관리 데이터베이스(CMDB)를 나타내는 도면이다.

도 9는 예시적인 작업 흐름 엔진을 나타내는 도면이다.

도 10은 사건들을 처리하기 위한 예시적인 작업 흐름을 나타내는 도면이다.

도 11은 작업 흐름을 선언적으로 정의하기 위한 마크업을 나타내는 도면이다.

도 12는 링크 서버 또는 링크 프레임워크에 의해 링크될 수 있는 작업 항목들, 아티팩트들, 경보들 등의 예를 나타내는 도면이다.

개요

아래의 설명은 통상적인 IT 시스템에 대한 설명, 및 IT 시스템 상에서 이용가능한 소프트웨어 서비스들 또는 컴포넌트들의 스택에 대한 간단한 설명으로 시작된다. 이어서, 프로세스 패키지, 및 프로세스 패키지가 어떻게 기술 스택 상에서 "실행"될 수 있는지, 즉 IT 기반구조 상에서 비즈니스 또는 IT 프로세스를 자동화하는 데 사용될 수 있는지가 설명된다. 이어서, 소프트웨어 서비스 스택의 컴포넌트들 및 이들의 특성들이 더 상세히 설명된다. 이어서, 패키지들의 다른 양태들이 설명된다.

IT 시스템 또는 기반구조

정보 기술(IT)이라는 용어는 특히 커다란 조직들에서 정보를 관리하고 처리하는 기술 및 특히 양태들에 광범위하게 관련된다. IT는 정보를 저장, 처리, 전송 및 검색하기 위해 컴퓨터들 및 컴퓨터 소프트웨어의 사용을 필요로 한다. 조직의 IT 기반구조 또는 시스템은 자산, 주로 조직에 제공되는 IT 서비스들은 물론, IT 서비스들을 조직에 제공하는 데 사용되는 하드웨어 및 소프트웨어(아티팩트들)를 지칭한다. 통상적으로, 큰 IT 기반구조는 전담 직원 또는 부서에 의해 관리될 것이다.

도 1은 예시적인 IT 시스템(100)을 나타낸다. IT 시스템(100)은 다수의 하드웨어 및 소프트웨어 아티팩트(102)를 구비한다. 하드웨어 아티팩트의 예는 서버, 라우터, 브리지, 백본, 케이블과 같은 네트워크 장비, 워크스테이션, 이동 장치, PC, 프린터와 같은 주변 장치, 아마도 전화 장비 등이며, 너무 많아서 다 열거할 수 없다. 소프트웨어 아티팩트의 예는 데이터베이스 서버, 데스크톱 애플리케이션, 웹 서버, 웹 포탈, 파일 서버, 이메일 서버, IT 관리 소프트웨어, 프로덕티비티 스위트(productivity suite), 회계 패키지, 및 종종 IT 부서에 의해 배치되어 관리되는 거의 제한 없는 다양한 다른 소프트웨어 서비스이다.

도 1은 또한 예시적인 기술 스택(104)을 도시한다. 기술 스택은, 느슨하게 링크되어, 전반적인 IT 서비스를 제공하고 전반적인 IT 서비스를 관리하고 유지하기 위해 서로 협력하고 통신할 수 있는 IT 기반구조 내의 소프트웨어 서비스들 또는 제품들로 간주될 수 있다. 즉, 기술 스택은 IT 기반구조 내의 유틸리티 및 기능을 제공한다. 도 1에 도시된 예시적인 기술 스택(104)에서, 기술 스택(104)은 IT 기반구조(100) 전반에 분포되는 다수의 컴포넌트(106-116)를 구비한다. 중요도의 순서 없이, 이들 컴포넌트는 아래에 일반적으로 설명되며, 더 아래에 보다 상세히 설명된다("기술 스택"이라는 제목의 섹션 참조).

예시적인 기술 스택(104)은 조직의 고용인들이 조직 정보 및 애플리케이션들에 액세스하는 시작 포인트 또는 게이트웨이로서 통상적으로 기능하는 셀프 서비스 포탈(self-service portal; 106)을 구비한다. 셀프 서비스 포탈(106)은 통상적으로는 웹 포탈로서 구현되지만, 다른 형태도 취할 수 있다. 셀프 서비스 포탈(106)은 임의의 다양한 소프트웨어 벤더로부터의 제품들을 이용하여 구현될 수 있다. 예를 들어, 마이크로소프트의 쉐어포인트 포탈 서버의 현재 또는 미래 버전이 코어 포탈 기능을 위해 사용될 수 있다. SQL 서버와 같은 다른 제품들도 보고 서비스 등을 제공하는 데 사용될 수 있다. IBM의 웹스피어 포탈은 셀프 서비스 포탈(106)을 위해 사용될 수 있는 제품의 다른 예이다.

기술 스택(104)은 또한 서식 프레임워크(108)를 포함한다. 서식 프레임워크(108)는 IT 시스템(100) 전반에서 널리 사용되는 소정의 프레임워크이다. 그 명칭이 의미하듯이, 서식 프레임워크(108)는 아티팩트, 태스크 등과 같은 소정의 작업 항목에 대한 정보를 서식과 같은 방식으로 채우기 위한 것이다. 매우 기본적인 서식은 통상적으로, 아마도 크기가 조절되고 정형화된 필드들을 구비하며, 서식 필드들을 저장하거나 다시 채우기 위한 소정의 백엔드 데이터소스에 결합될 수 있다. 서식 프레임워크(108) 내의 서식은 또한 상호작용할 수 있는데, 즉 필드 서식들을 단순히 채우는 것 이상을 수반할 수 있다. 데이터 무결성을 위한 경량 로직 또는 규칙들도 서식 내에 존재할 수 있다. 서식 프레임워크(108)를 구현하기 위해 다양한 기성 제품이 사용될 수 있다. 예를 들어, 마이크로소프트사의 오피스 12, 또는 IBM의 워크플레이스 서식 등이 사용될 수 있다. 바람직하게는, 서식 프레임워크(108)는 서식들이 다양한 방식으로 표시될 수 있게 하는데, 예를 들어 서식은 직접 사용자 인터페이스(예를 들어, 쉐어포인트 또는 인포패스 서식)이거나, 서식은 마이크로소프트 아웃룩, 워드 프로세서 등과 같은 애플리케이션에서 팝업될 수 있다. 서식 프레임워크(108)를 통해 사용자에 의해 입력되는 데이터는 대개, 아마도 하나 이상의 데이터베이스에 또는 전용 아티팩트 스토어(110)(후술함)에 유지될 것이다. 서식 프레임워크(108) 내의 서식들은 기술 스택(104) 내의 다른 컴포넌트들에 의해 구동될 수 있으며, 서식 프레임워크(108)를 통해 입력되는 데이터는 기술 스택(104) 내의 다른 컴포넌트들에 영향을 미칠 수 있다.

기술 스택(104)은 또한 지식 소스, 저장소 또는 프레임워크(112)를 구비할 수 있다. 지식 프레임워크(112)는 지식을 관리하는 데 사용되는 서비스 또는 애플리케이션들의 세트이다. 지식 프레임워크(112)는 기사들 및 문서들의 저장 및 인덱싱, 지식 검색, 관련 문서들의 상호 참조 또는 링크, 메타데이터 태깅, 카탈로깅 등과 같은 기능들을 제공할 수 있다. 지식 프레임워크(112)는 조직의 지식의 진행 캡처 및 그에 대한 액세스를 허가하는 시스템으로 간주될 수 있다. 바람직하게는, 사용자들은 구조화되거나 구조화되지 않은 정보일 수 있는 저장된 지식을 쿼리 및 브라우징할 수 있다. 지식의 어드레스 가능 부분들이 바람직할 수 있다(예를 들어, 문서들의 URI들). 문제 해결 안내서, 기사, 백서, 사용자 매뉴얼, 절차 문서 등은 지식 프레임워크(112)에서 발견될 수 있는 소정 지식 유형들의 예이다. 지식 프레임워크(112)에 사용될 수 있는 제품들의 예는 마이크로소프트의 오피스 12, 팩티바, 인터우븐의 워크사이트 스위트 등을 포함한다.

작업 흐름 엔진 또는 프레임워크(114)도 IT 시스템(100)의 기술 스택(104)의 일부이다. 작업 흐름 프레임워크(114)는 자동화된 작업 흐름들의 생성, 실행 및 모니터링을 허가한다. 대부분의 작업 흐름 제품들에서, 작업 흐름들은 다양한 개별 활동들 간의 아마도 조건부인 흐름으로 구성된다. 활동의 코스는 조건부 이벤트들에 의존할 수 있다. 작업 흐름들은 간단한 사건 처리 자동화에서 사용자에 의해 정의되는, 장기 실행되고 복잡한 작업 흐름들까지의 범위일 수 있다. 작업 흐름은 통상적으로, 무엇이 작업 흐름의 특정 인스턴스를 트리거하는지, 어떻게 작업이 진행되는지, 및 작업 흐름을 수행하는 활동들에 대한 소정의 기술이다. 후술하는 바와 같이, 작업 흐름들은 다른 접속된 시스템 또는 기술 스택 컴포넌트에서의 상태 변경 이벤트에 의해 트리거될 수 있다. 또한, 아티팩트들은 링크 프레임워크(116)(후술함)에 의해 제공되는 링크들에 의해 링크될 수 있으므로, 작업 흐름 활동들(작업 흐름 내의 "노드들")은 이러한 아티팩트들을 처리하거나, 인터페이스, 예를 들어 웹 서비스를 통해 이러한 아티팩트들에 액세스할 수 있다. 이것은 IT 관리 시스템 경보가 IT 사건의 라이프 사이클을 처리하는 사건 작업 흐름을 생성하는 것과 같은 시나리오들을 가능하게 할 수 있다.

작업 흐름 프레임워크(114)에 사용될 수 있는 많은 상용 제품이 존재한다. 예를 들어, 윈도우 워크플로우 파운데이션(WWF)은 작업 흐름들을 실행하기 위한 윈도우 기반 작업 흐름 엔진을 제공하며, 마이크로소프트 오피스(비지오)는 작업 흐름들의 그래픽 구성을 허가한다. 스켈타는 .Net 기반 작업 흐름 프레임워크를 판매한다. 자바 기반 오픈 소스 작업 흐름 엔진도 사용될 수 있다(JBoss jBPM 참조).

예시적인 기술 스택(104) 내의 또 하나의 컴포넌트는 링크 서비스 또는 링크 프레임워크(116)이다. 링크 프레임워크(116)는 기술 스택(104) 내의 다양한 컴포넌트들을 함께 결합하는 것을 돕는다. 링크 프레임워크(116)는 아티팩트들의 링크, 교환 또는 동기화 및 맵핑을 허가한다. 예를 들어, 링크 프레임워크(116)는 개발 플랫폼들과, 마이크로소프트 운영 관리(MOM) 또는 시스템 관리 서버(SMS)와 같은 IT 관리 플랫폼들을 링크할 수 있다. 링크 프레임워크(116) 내의 링크들은 자동화된 작업 흐름들이 링크된 시스템들 내의 관련 아티팩트들에 의해 트리거되어 이들을 처리하는 것을 허가한다. 사용될 수 있는 링크 제품의 일례는 마이크로소 프트의 팀 파운데이션 서버(TFS)인데, 이는 스택 컴포넌트들이 그들의 아티팩트들 및 링크 서버와의 관계들을 등록하는 것을 허가한다. TFS가 사용되는 경우, 예를 들어 웹 서비스를 통해 이용 가능한 아티팩트들은 이들 아티팩트의 관계들 및 위치들을 유지할 수 있는 링크 프레임워크(116)에 의해 사용될 수 있다.

기술 스택(104)은 바람직하게는 아티팩트 스토어(110), 통상적으로 구성 관리 데이터베이스(CMDB)를 포함한다. CMDB는 주로 IT 항목들의 레코드를 유지하는 기능을 제공하며, 이들 서로의 관계들을 추적한다. 대부분의 IT 관리 활동은, 결정을 내리고 IT 시스템(100) 내의 항목들에 대한 정보를 공유하기 위해 아티팩트 스토어(110)를 통해 판단한다. 바람직하게는, 아티팩트 스토어(110)는 시스템 정의 모델(SDM) 언어에 기초하는데, 이는 아티팩트들의 유형들 및 이들 사이의 관계들의 모델링을 돕고, 또한 MOM 및 SMS와 같은 다른 SDM 기반 컴포넌트들과의 상호 작용을 돕는다. CMDB 유형의 아티팩트 스토어(110)가 아래에 더 상세히 설명된다.

기술 스택(104)은 IT 시스템이 가질 수 있는 하나의 가능한 기술 스택의 일례일 뿐이다. 다른 IT 시스템들은 상이한 세트의 컴포넌트들을 가질 수 있다. 또한, 컴포넌트들은 임의의 벤더로부터의 임의의 다양한 상용 소프트웨어 제품들로 구현될 수 있다. 컴포넌트들은 IT 시스템 내의 많은 상이한 컴퓨터(예를 들어, 서식 프레임워크(108), 셀프 서비스 포탈(106) 등)에 분산될 수 있다. 소정의 컴포넌트들은 하나의 컴퓨터 또는 서버(예를 들어, 지식 프레임워크(112), 아티팩트 스토어(100) 등) 상에 설치되어 실행될 수 있다. 소정의 컴포넌트들은 동일 서버 상에서 호스트될 수 있다. 설치 구성은 중요하지 않다. 오히려, 중요한 것은 다양한 기술 컴포넌트들의 가용성 및 이들이 서로 통신할 수 있는 능력이다. 또한, 컴포넌트들은 그들 각각의 기능들의 독립적인 운영이 가능할 수 있다. 즉, 예를 들어 작업 흐름 프레임워크(114)는 기술 스택(104) 내의 다른 컴포넌트들을 필요로 하지 않고 사용자들에게 작업 흐름 기능을 제공할 수 있다. 또는, 서식 프레임워크(108)는 다른 컴포넌트들과 별개로 존재하고 동작하는 서식들을 가질 수 있으며, 동시에 후술하는 바와 같이 다른 기술 스택(104) 컴포넌트들과 연동하는 서식들을 가질 수 있다. 기술 스택(104)은 느슨하게 연결되거나 연동할 수 있지만(아마도 간접적이거나 또는 링크 프레임워크(116)에 의해 도움을 받음), 또한 독립 기능을 제공하는 독립 컴포넌트들의 집합이다.

패키지들

도 2는 패키지(130)를 나타낸다. 예시적인 기술 스택(104)과 같은 임의의 기술 스택이 주어지면, 패키지(130)는 기술 스택을 제어하는 데 사용될 수 있다. 패키지(130)는 기술 스택의 구성의 바람직하게는 선언적인 인코딩을 포함하며, 패 키지는 기술 스택에 의해 해석되어 기술 스택을 제어한다. 구체적으로, 패키지(130)는 프로세스의 인코딩이며, 프로세스를 구현하기 위해 스택에 의해 사용되는 메타데이터와 같은 관련 정보를 포함한다. 패키지(130)는 사실상 기술 스택에 "플러그 인"되고 기술 스택에 의해 "실행"될 수 있다. 패키지(130)는 DVD와 대략 유사하며, 실행기(기술 스택)에 플러그 인될 수 있고, 그의 프로세스는 기술 스택에 의해 실행될 수 있다.

배경 기술에서 설명된 바와 같이, 문서 또는 인간의 지식으로부터의 IT 또는 비즈니스 프로세스들의 해석은 에러가 발생하기 쉬우며, 프로세스들이 기존의 관리 도구들과 함께 동작하도록 하는 프로세스 자동화는 매우 복잡하여, 구현하는 데 수년이 걸리고 유지에 많은 비용이 들 수 있다. 패키지(130)는 기술 중립 IT 또는 비즈니즈 프로세스가 이식 가능하고 기계가 사용 가능하고 확장 가능한 형태로 인코딩되는 것을 허가한다. 따라서, 상이한 IT 시스템들(및 상이한 각각의 기술 스택들)이 동일 패키지를 갖는 경우, 그 패키지에 인코딩된 프로세스는 상이한 IT 시스템들에서 구현(자동화)될 수 있다. 패키지 접근법은 패키지의 프로세스를 수행하도록 기술 스택을 구성하는 패키지 내의 정보로부터 (프로세스를 구현하는) 기술 스택을 분리하는 것을 가능하게 한다. 후술하는 바와 같이, 패키지는 바람직하게는 프로세스를 협력하여 수행하도록 스택 컴포넌트들을 구성하고 제어하는 선언 정보를 포함한다. 예를 들어, 패키지는 패키지의 프로세스 내의 다양한 인간 또는 자동 단계들을 정의하는 작업 흐름 정보; 아티팩트 스토어(110)에 플러그 인하기 위한 아티팩트 스키마 및 관계 유형들; 프로세스에 관련된 사람들에게 의도되고 지식 프레임워크(112)에 저장될 수 있는 지식 기사들 또는 지시들; 역할 정의들; 뷰들, 서식들 및 보고서들; 서비스, 자산, 사용자, 위치, 조직과 같은 개체들을 표현하는 구성 항목들 등을 포함할 수 있다.

패키지(130)의 내용은 바람직하게는 선언적 구성 정보 및 메타데이터이며, 이들의 일부는 기술 스택(104) 내의 다양한 대응 컴포넌트들로 지향되어 그들에 의해 해석될 수 있다(도 5 참조). 패키지(130)의 내용의 형태와 관계없이, 프로그램 또는 애플리케이션(132)은 패키지(130)를 판독하고, 이를 기술 스택(104)에 플러그 인한다. 플러그 인된 경우(도 2의 아랫부분), 기술 스택은 패키지(130) 내에 인코딩된 비즈니스 또는 IT 프로세스의 자동화, 즉 패키지의 "실행"을 시작할 수 있다.

도 3은 어떻게 패키지들이 프로세스들을 공유하는 데 사용될 수 있는지를 나타낸다. 다수의 상이한 조직들, 사람들 또는 엔티티들(150a, 150b, 150c)이 프로세스들(152a, 152b, 152c)을 패키지들(154a, 154b, 154c) 내에 인코딩할 수 있다. 엔티티(150a, 150b, 150c)는 비즈니스 또는 IT 프로세스들의 자동화를 전문으로 하는 회사일 수 있다. 엔티티는 IT 부서 또는 그의 직원일 수 있으며, 그 부서의 IT 관리 프로세스를 인코딩하고 있을 수 있다. 프로세스(152a)와 같은 하나의 프로세스는 비공식적으로 이해되거나 부분적으로 문서화된 프로세스일 수 있으며, 이 프로세스의 많은 부분은 하나 이상의 사람에 대한 개인 지식이고, 프로세스의 다른 부분은 대략 문서화될 수 있다. 프로세스(152b)와 같은 다른 프로세스는 ITIL, MOF, IBM 레드북 시리즈, IT 부서 문서 등에서 통상적으로 발견되는 유형의 문서화된 프로세스일 수 있다. 프로세스(152c)와 같은 또 다른 프로세스는 패키지(154c) 내에 인코딩되는 동안에 즉흥적으로 개발되거나 설계될 수 있다. 어느 경우에나, 패키지들(154a, 154b, 154c)은 상이한 조직들 사이에 공유될 수 있는 프로세스들 또는 절차들의 바람직하게는 선언적인 이식 가능한 인코딩들이다.

도 3은 상이한 조직들, 비즈니스들, 회사들 등에 아마도 대응하는 2개의 개별적이고 독립적인 IT 시스템(156a, 156b)을 또한 도시하고 있다. 각각의 IT 시스템(156a, 156b)은 대응 기술 스택(158a, 158b)을 갖는다. 기술 스택들(158a, 158b)은 전술한 바와 같은 기술 스택(104)과 유사하지만, 다양한 스택 컴포넌트와 유사한 기능들을 수행하거나 그들을 대신하는 상이한 컴포넌트들의 세트들 및 아마도 상이한 제품들을 구비할 수 있다. 예를 들어, 기술 스택(158a)은 작업 흐름 관리를 위해 마이크로소프트의 WWF를 사용할 수 있으며, 기술 스택(158b)은 오픈 소스 작업 흐름 엔진을 사용할 수 있다.

도 3에 도시된 바와 같이, 패키지들(154a, 154b, 154c)은 기술 스택들(158a, 158b, 158c)이 프로세스들(152a, 152b, 152c)을 수행할 수 있게 하기 위하여 상이한 IT 시스템들(156a, 156b, 156c)에 배포, 공유 및 실행될 수 있다. 패키지들(154a, 154b, 154c)은 예를 들어 네트워크 전송에 의해 전자적으로, 물리적 저장 매체의 배포에 의해 물리적으로 배포되거나, IT 관리 시스템의 일부로서 사전 설치될 수 있다. 어느 방법으로든, 패키지가 수신되면, 패키지는 수신기의 기술 스택에 플러그 인되어 실행될 수 있으며, 따라서 대응 프로세스가 자동화될 수 있다. 도 3의 예에서, 기술 스택(158a)은 패키지들(154a, 154b, 154c)을 실행하고 있다. 기술 스택(158b)은 패키지들(154b, 154c)을 실행하고 있다. 상이한 프로세스들이 하나의 엔티티에 의해 인코딩될 수 있지만, 많은 상이한 엔티티에 의해 효율적으로 공유 및 자동화("실행")될 수 있음을 알 수 있다. 또한, 도 4와 관련하여 후술되는 바와 같이, 필요한 경우에, 패키지들(154a, 154b, 154c) 중 임의 패키지는 임의의 다른 패키지(154a, 154b, 154c)를 참조할 수 있으며, 따라서 상호 참조되는 패키지로부터 도출되는 작업 항목들, 또는 클래스들, 또는 데이터 파일들(예를 들어, 지식 기사들), 또는 임의의 정보를 이용할 수 있다.

각각의 IT 시스템(156a, 156b)은 임의의 패키지들을 그들 각각의 기술 스택들(158a, 158b)에 플러그 인할 수 있는 능력을 가져야 한다는 점에 유의한다. 애플리케이션(132)과 같은 독립 프로그램이 사용될 수 있지만, 기술 스택들(158a, 158b)의 컴포넌트의 일부로서 유사한 기능이 제공될 수 있다. 통합 서비스 데스크(CSD)가 그러한 기능을 제공하기 위한 이상적인 장소이다. 사실상, 애플리케이션(132)은 CSD 애플리케이션일 수 있다.

도 4는 예시적인 패키지(170)를 나타낸다. 일 실시예에서, 패키지(170)는 기술 스택 내의 각각의 컴포넌트에 대응하는 코드 부분들(172a-172f)을 갖는다. 예를 들어, 코드 부분들(172a-172f)은 기술 스택(104; 도 2) 내의 컴포넌트들(106-116)에 대응할 수 있다. 그러나, 패키지는 그 패키지에 의해 인코딩된 프로세스에 의해 사용되는 스택 컴포넌트들의 서브세트에만 대응하는 코드 부분들을 가질 수 있으며, 패키지는 기술 스택 내의 각각의 컴포넌트를 사용할 필요는 없다. 더 복잡하고 구조화된 프로세스들은 다수의 스택 컴포넌트들과 접촉하는 경향이 있는 인코딩 패키지들을 갖는다. 예시적인 패키지(170)가 기술 스택(104)으로 지향되는 것으로 가정하면, 각각의 코드 부분(172a-172f)은 그의 대응 기술 스택 컴포넌트에 플러그 인될 수 있는 코드를 가질 것이다. 예를 들어, 패키지(170)에 인코딩된 프로세스가 IT 자산 취득 프로세스인 경우, 코드 부분(172a)은 요청의 상태를 조사하거나 요청을 개시하기 위해 셀프 서비스 포탈 개체들의 유형들/클래스들 및 인스턴스들을 선언할 수 있다. 코드 부분(172b)은 사용자가 요청과 관련된 데이터를 입력하기 위한 서식들, 예를 들어 요청을 승인하기 위한 승인 서식을 선언적으로 기술할 수 있다. 코드 부분(172c)은 아티팩트 스토어(110)에 대해, 인스턴스들이 아티팩트 스토어(110)에 저장될 수 있는 요청에 관련된 개체들의 클래스들을 정의할 수 있다. 예를 들어, 작업 항목 또는 작업 순서, 요청되고 있는 아티팩트(예를 들어, 소프트웨어 패키지, 컴퓨터 등), 또는 "요청자", "승인자", "회계 부서" 등과 같은 역할들. 코드 부분(174d)은 패키지(170)에 첨부된 소정의 지식(174)의 포함을 지시할 수 있다. 지식(174)은 전자 문서들, 교육 비디오, 또는 심지어 지식(174), 새로운 텍스트 또는 다른 유사한 정보에 대한 새로운 하이퍼링크들과 같은 지식 프레임워크(112) 내의 기존 문서에 대한 수정들 또는 갱신들을 포함할 수 있다.

예시적인 패키지(170)에서, 코드 부분(172e)은 프로세스의 전체 작업 흐름, 예를 들어 자산 취득 작업 흐름을 정의할 것이다. 코드 부분(172e)은 활동들, 및 활동들 간의 흐름에 대한 이벤트들 및/또는 조건들을 선언할 것이다. 코드 부분(172f)은 링크 프레임워크(116)에 추가될 링크들을 선언할 것이다. 예를 들어, 이것은 IT 관리 시스템(예를 들어, MOM)으로부터의 경보가 아티팩트 스토어(110)에 저장된 문제 또는 아티팩트에 링크됨을 선언할 수 있다. 임의의 스택 컴포넌트 내의 임의의 데이터는 잠재적으로 다른 스택 컴포넌트 내의 다른 데이터 항목에 링크될 수 있다.

도 4에서 점선들(176)로 지시되는 바와 같이, 코드 부분들(172a-172f) 중 임의의 코드 부분은 다른 부분(172a-172f)에서 선언된 클래스들 또는 개체들 또는 다른 정보를 참조할 수 있다. 전술한 바와 같이, 코드 부분은 지식(174)과 같이 패키지(170)에 첨부되거나 포함된 소정의 비트들 또는 하드 데이터에 대한 링크 또는 참조(177)를 가질 수도 있다. 이러한 하드 데이터는 소프트웨어 라이브러리들, 소스 코드 또는 보조 로직을 코드 부분들(172a-172f) 중 하나에 추가하는 "코드 병행(code-beside)", 또는 심지어 패키지(170) 또는 하나 이상의 코드 부분들(172a-172f)과 호환되도록 기술 스택 컴포넌트들을 업그레이드하기 위한 업그레이드 팩들을 포함할 수도 있다.

패키지(170)와 같은 패키지는 바람직하게는 전체 패키지(170)에 적용 가능한 소정의 정보를 포함하는데, 이러한 정보는 글로벌 데이터 또는 패키지 데이터(178)로서 참조된다. 패키지 데이터(178)는 패키지들(154a, 154b, 154c) 및 패키지(170)와 같은 패키지들의 포맷을 정의하는 마스터 또는 컨테이너 스키마를 지시할 수 있다. 패키지 데이터(178)는 명칭 또는 전역적으로 고유한 식별자 또는 다른 식별 정보를 제공함으로써 패키지(170)를 식별할 수 있다. 패키지 데이터(178)는 패키지(170)에 대한 명칭 공간을 정의하고, 패키지(170)의 버전을 식별하고, 패키지(170)의 발행자 또는 저자를 식별하고, 신빙성 및 무결성 정보(예를 들어, 암호화된 체크섬, 공개 키 또는 신빙성 증명서 등) 또는 글로벌 특성의 다른 정보를 포함할 수 있다. 패키지 데이터(178)는 다른 패키지(180)에 대한 종속성(179), 요구되는 플랫폼들, 필요한 스택 컴포넌트들 및 이들의 버전들 등과 같은 종속성 정보도 포함할 수 있다. 패키지 데이터(178)는 배포 데이터(181) 또는 설치 데이터(182)와 같은 패키지(170)의 명백한 리스트 부분들로서도 기능할 수 있다. 일 실시예에서, 옵션으로서, 패키지(170)는 캐비닛 파일(즉, CAB 파일), 마이크로소프트 윈도우 인스톨러(MSI) 패키지, 또는 소정의 다른 배포 패키지 포맷으로서 형성될 수 있다.

일 실시예에서, 패키지(170)는 XML 스키마 정의 파일(XSD 파일) 또는 소정의 다른 유형의 스키마 파일일 수 있는, 패키지 스키마(184)에 따라 포맷된 구조화된 문서이다. 전술한 바와 같이, 패키지 스키마(184)는 패키지(170)에 첨부되거나 포함될 수 있으나, 이것은 요구되는 것은 아니다. XML 기반 실시예에서, 코드 부분들(172a-172f) 및 패키지 데이터(178)는 패키지 스키마(184)에 따라 포맷되고 배열된 XML 마크업 또는 태그들(185)로 구성된다. 이 실시예에서, 코드 부분들(172a-172f)은 로딩 애플리케이션(132)에 의해 컴포넌트 고유 코드로 변환될 수 있다.

다른 실시예에서, 패키지(170)는 또한 패키지 스키마(184)에 따라 포맷된 구조화된 문서이다. 그러나, 코드 부분들(172a-172f)은 대응하는 기술 스택 컴포넌트들에 고유한 코드의 부분들이며, 매크로 확장(즉, 컴파일러형의 전처리)이 파라미터들, 매크로들, 명명된 개체들 등이 패키지(170) 또는 패키지가 실행되는 기술 스택에 고유한 것을 보장하는 것을 도울 수 있지만, 코드 부분들은 변환될 필요가 없을 수 있다.

임의의 실시예들에서, 패키지들은 확장성 마크업 언어(XML), 그의 파생어 또는 다른 언어들과 같은 언어를 이용하여 구현될 수 있다. 소정 부분들, 예를 들어 아티팩트 스토어에 저장될 아티팩트들의 정의들은 시스템 정의 모델링 언어(SDM)를 이용하여 구현될 수 있다. 기술 스택 컴포넌트들이 선언 코드를 통해 액세스될 수 있는 API들 및/또는 개체 모델들을 갖는 경우에, 패키지의 코드 부분들은 대응 스택 컴포넌트들에 직접 플러그 인될 수 있다. 기술 스택이 표준화된 선언 액세스(예를 들어, 컴포넌트 고유 XML 스키마)를 제공하지 않는 컴포넌트를 갖는 경우에, 그 컴포넌트에 대한 패키지 코드는 그 컴포넌트에 고유하게 작성되거나, 모델링 언어(예를 들어, SDM) 또는 아마도 패키지 스키마(184)에 의해 정의되는 다른 언어로 작성될 수 있다. 이러한 코드는 애플리케이션(132)에 의해 대응 컴포넌트에 고유한 코드로 변환될 수 있다.

패키지 내에 캡처된 정보의 특성과 관련하여, 많은 유형의 프로세스들이 패키지 내에 인코딩될 수 있다는 점에 유의해야 한다. 구조화되지 않은 프로세스들(예를 들어, 단일 또는 배열되지 않은 활동들을 갖는 프로세스들), 예를 들어 통신 및 협동 프로세스들; 지식 및 훈련의 이용, 등급화 및 갱신; 진단 및 디버깅 애플리케이션들의 브라우징; IT 문제들을 해결하는 동안의 최종 사용자들과의 채팅; 웹 기반 셀프 서비스들; 보고; IT 사건들 및 IT 사건들의 서비스 상태의 탐색; IT 시스템 변경들의 통지; 조사표의 작성; 이용, 가용성 및 서비스 레벨 협약(SLA)의 준수에 관한 계속적인 보고 등이 인코딩될 수 있다. 연장된 상태 지속성(예를 들어, 수일, 수주, 수개월, 심지어 수년), 아마도 활동들 간의 긴 간격들, 및 활동들 간의 고도로 구조화된 흐름을 갖는 구조화된 프로세스들도 인코딩될 수 있다. 구조화된 프로세스들의 예는 라우팅 및 에스컬레이션과 같은 작업 항목 라이프 사이클; 아마도 회계 활동들을 포함하는 허가 및 승인; 수령, 테스트, 전개 및 회수와 같은 자산 라이프 사이클 프로세스들; 변화 관리 라이프 사이클 프로세스들; 지식 라이프 사이클 등을 포함한다. IT 관리 프로세스들은 종종, 다양한 IT 자원들이 이용 가능하다는 것을 가정하여 설계되므로 패키징에 적합하지만, 다른 비 IT 프로세스들도 패키징될 수 있다. 회계 프로세스들, 보험 청구 처리 프로세스들 및 다른 비즈니스 프로세스들도 패키징될 수 있다.

로더/컨트롤러 애플리케이션

도 2와 관련하여 전술한 바와 같이, 애플리케이션(132)은 패키지를 이후에 실행하는 기술 스택에 패키지를 로딩하는 데 사용될 수 있다. 도 5는 애플리케이션(132)이 패키지(202)를 기술 스택(204)에 로딩하기 위해 수행할 수 있는 프로세스(200)를 나타낸다. 먼저, 애플리케이션(132)은 패키지(202)를 판독하고(단계 206), 글로벌 또는 패키지 데이터(예를 들어, 패키지 데이터(178))를 검사한다. 패키지 데이터에 기초하여, 애플리케이션(132)은 패키지(202)의 종속성이 만족되는지를 판정할 수 있다. 예를 들어, 애플리케이션(132)은 기술 스택 컴포넌트들이 존재하는지 그리고/또는 충분한 버전 레벨인 지를 검증할 수 있다. 애플리케이션(132)은 또한 임의의 상호 참조 패키지들이 기술 스택(204)에 설치되어 있는지 또는 설치에 이용 가능한지를 검증하기 위해 검사할 수 있다. 초기 판독 단계(206)에서, 애플리케이션은 또한 임의의 필요한 스키마들을 로딩하거나, 명칭 공간들을 검사하거나, 다른 방식으로 패키지(202)의 플러그 인을 준비할 수 있다.

글로벌 패키지 데이터가 판독(단계 206)되어 처리된 후, 애플리케이션(132)은 기술 스택 컴포넌트로 지향되는 패키지(202)의 일부를 식별한다(단계 208). 예를 들어, 애플리케이션(132)은 패키지(202)를 파싱할 때 코드 부분, 예를 들어 코드 부분들(172a-172f) 중 하나를 식별하거나 디마크(demark)하는 태그를 판독할 수 있다. 필요한 경우에, 식별된(단계 208) 노드, 요소 또는 코드 부분은 코드 부분이 지향되는 스택 컴포넌트에 의해 지시되는 포맷 또는 언어로 변환될 수 있다(단계 210). 전술한 바와 같이, 표준 선언 언어(예를 들어, SDM, XAML 등)를 이용하여 직접 프로그래밍/구성될 수 있는 기술 스택들에 대해, 그러한 스택들에 대한 패키지들의 코드 부분들은 대응 스택 컴포넌트들에 직접 플러그 인될 수 있다. 어느 경우에나, 이어서, 식별되고(단계 208) 아마도 변환된(단계 210) 코드 부분은 적절한 기술 스택 컴포넌트를 구성(단계 212)하는 데 사용된다. 즉, 패키지(202)의 일부는 그의 기술 스택 컴포넌트에 플러그 인된다. 예를 들어, 식별된(단계 208) 부분이 작업 흐름 정의인 경우, 작업 흐름 정의를 이용하여 작업 흐름 프레임워크(114)가 구성된다(단계 212). 식별된(단계 208) 부분이 아티팩트 스토어(110)에 대한 것이고 개체들의 클래스들 및/또는 인스턴스들을 정의하는 경우, 아티팩트 스토어는 그 부분을 이용하여 구성(단계 212)될 때 정의된 클래스들 또는 유형들의 개체들을 저장할 수 있게 될 수 있다. 식별된(단계 208) 부분이 패키지(202)에 대한 포탈을 정의하는 포탈 정보(214)인 경우, 정의된 포탈을 제공하기 위해 포탈 컴포넌트(216)가 구성될 수 있다(단계 212). 또한, 코드 부분의 부분들은 둘 이상의 컴포넌트에 플러그 인되어, 예를 들어 필요한 유형들의 개체 클래스들, 작업 항목들, 링크들 또는 다른 데이터를 갖도록 이들을 구성할 수 있다.

식별하고(단계 208), 아마도 변환하고(단계 210), 구성하는(단계 212) 프로 세스들은 전체 패키지(202)가 파싱될 때까지 반복된다(단계 218). 패키지(202)가 어떠한 치명적인 에러도 없이 로딩 또는 플러그 인된 것으로 가정하면, 이어서 애플리케이션(132)은 기술 스택(204) 상에서 패키지(202)를 활성화함으로써(단계 220) 패키지(202)의 "실행"을 개시할 수 있다. 이것은 패키지(202) 또는 코드 부분들이 모두 성공적으로 로딩되었는지를 검증하고, 작업 흐름 프레임워크가 패키지(202)에 의해 정의되는 작업 흐름의 인스턴스들의 처리를 시작하는 것을 가능하게 하고, 그리고 아마도 스택 컴포넌트들의 재시작, 리셋팅 또는 리부팅을 위해 시그널링하는 단계를 수반할 수 있다.

흐름도들에는 도시되지 않지만, 애플리케이션(132)은 다른 주요 기능들을 가질 수 있다. 예를 들어, 애플리케이션은 또한 그들의 작업 흐름들을 디스에이블시키거나, 스택 컴포넌트들로부터 인에이블링 코드를 언로딩함으로써 패키지들의 "실행"을 중지시킬 수 있다. 애플리케이션(132)은 또한 다양한 스택 컴포넌트들의 에러 메시지들 또는 에러 로그들을 분석함으로써 패키지의 상태를 모니터링할 수 있다. 또한, 예시적인 애플리케이션(132)의 기능은 어느 곳에나 존재할 수 있으며, 전담 프로그램에 맡겨질 필요가 없을 수 있다. 애플리케이션(132)은 범용 통합 서비스 데스크 애플리케이션으로도 기능할 수 있다.

도 6은 패키지를 플러그 인하기 위한 다른 프로세스를 나타낸다. 임의의 소스로부터의 임의의 패키지가 수신된다(단계 230). 패키지는, 단계 234에서 각각 설치 또는 플러그 인되거나, 수신된(단계 230) 패키지에 포함되거나, 기술 스택 상에서 현재 "실행"되고 있는 것으로 검증될 수 있는 다른 패키지들에 대한 참조에 대해 검색된다(단계 232). 이어서, 패키지가 활성화되고(단계 236), 이후 스택 컴포넌트들이 패키지로부터 그들 각각의 내용 부분들을 실행하고(단계 238), 필요에 따라 연동한다.

기술 스택

기술 스택이 패키지를 이용하여 구성되면, 기술 스택은 패키지에 의해 인코딩된 프로세스의 자동화, 즉 패키지의 수행 또는 실행을 개시한다. 기술 스택의 자동 컴포넌트들은 그들의 유용한 기능들을 수행하지만, 컴포넌트들은 이제 이들 기능이 함께 패키지에 의해 인코딩된 프로세스를 자동화하도록 구성된다. 컴포넌트들은 다른 컴포넌트들을 알 필요가 없다. 예를 들어, 작업 흐름 엔진은 특정 작업 흐름이 예를 들어 서식 프레임워크 내의 서식에 의해 영향을 받는다는 것을 알 필요가 없다.

간단한 또는 구조화되지 않은 프로세스에서는, 기술 스택 컴포넌트들 상에서 최소량의 활동이 발생할 수 있다. 예를 들어, 사용자들에게 IT 시스템에 대한 변경을 통지하는 간단한 패키지 인코딩 프로세스는 사용자가 셀프 서비스 포탈에서 변경 통지를 개시하는 정도를 포함할 수 있는데, 이는 포탈에 대한 데이터소스인 백엔드 데이터베이스 서버에서 트리거를 호출할 수 있다. 트리거는 포탈 이벤트가 아티팩트 스토어 내의 작업 항목에 링크되는지를 판정할 수 있는 링크 프레임워크로 갈 수 있다. 결과적으로, 링크 서버는 아티팩트 스토어에게 변경 통지에 대한 작업 항목을 저장하도록 지시할 수 있으며, 서식 프레임워크에게 새로운 변경 통지 작업 흐름을 개시하도록 지시할 수 있다. 이어서, 작업 흐름 엔진은 작업 항목의 상세들(변경 통지의 상세들)을 채우기 위한 서식을 사용자에게 전송함으로써 작업 흐름의 초기 활동을 수행할 수 있다. 사용자는 서식을 수신하고, 서식을 채우고, 변경 통지를 채울 수 있다. 변경 통지의 채움은 아티팩트 스토어가 링크 프레임워크에게 변경 통지가 갱신되었음을 통지하게 할 수 있다. 이어서, 링크 서버는 변경 통지 프로세스가 완료될 때까지 작업 흐름 엔진 등에게 지시한다. 알 수 있듯이, 스택 컴포넌트들은 다른 컴포넌트들과 독립적으로 설치되고 사용될 수 있는 독립 또는 자동 컴포넌트들일 수 있지만, 이들은 하나의 결합 단위로서 패키지를 수행 또는 실행한다.

도 7은 기술 스택이 예시적인 패키지를 실행할 때의 예시적인 프로세스 흐름을 나타낸다. 패키지가 실행 또는 활성화되면(단계 250), 사용자 활동 또는 시스템 이벤트는 예를 들어 작업 항목 또는 다른 아티팩트 표현을 생성한다(단계 252). 사용자 활동의 소정 예는 패키지에 의해 구성되는 이메일 어드레스로의 이메일 전송, 포탈 페이지에 대한 액세스 또는 서식에 입력된(아마도 패키지에 의해 정의된) 데이터의 제출 등이다. 시스템 활동의 예는 MOM 또는 SMS와 같은 관리 시스템들로부터의 경보들, 또는 작업 흐름 활동에 의해 생성되는 메시지들, 또는 IT 시스템의 기술 스택에 의해 수신되거나 인식되는 IT 시스템 상의 다른 자동화된 사건들이다. 작업 항목의 생성(단계 252)은 작업 항목이 CMDB 또는 다른 아티팩트 스토어에 저장되는(단계 254) 것으로 귀착된다. 기술 스택 내의 컴포넌트가 작업 흐름 활성화를 유발한다. 이어서, 작업 흐름 엔진은 트리거링 작업 항목에 따라 링크된 작업 흐름 인스턴스에서 활동을 수행한다. 기술 스택이 패키지를 이용하여 구성되면, 기술 스택 내의 상이한 컴포넌트들이 패키지에 의해 인코딩된 프로세스를 수행하기 위해 협동할 수 있는 방법의 몇 가지 예만이 존재한다.

도 8은 구성 관리 데이터베이스(CMDB; 280)를 나타낸다. 전술한 바와 같이, CMDB는 아티팩트 스토어(110)로서 기능하기 위한 선호되는(그러나 요구되지 않는) 유형의 데이터베이스이다. CMDB는 구성 항목들 또는 CI들의 표현들을 저장한다(편의상, CI의 표현 및 CI 자체는 교환 가능하게 사용된다). 통상적으로, CI는 IT 구성 관리 제어를 받는 소정의 IT 컴포넌트이다. ITIL 하에서, CI는 몇 가지 예로서 서비스, 자산, 사용자, 장소 및 조직과 같은 개체들을 나타낸다. CI의 라이프 사이클은 종종 주문 변경(change order)들(다음 섹션에서 설명됨)에 의해 구동된다. 저자들이 컴퓨터 또는 애플리케이션과 같은 일반 아티팩트들에 대한 CI들을 사용하는 패키지들을 작성하는 것을 쉽게 하기 위해 저자들에게 아웃-오브-더-박스 아티팩트 템플릿들이 제공될 수 있다. 저자들은 새로운 유형들을 추가하거나 기존 유형들을 확장할 수 있다.

통상적으로, 관계들도 CMDB에서 발견된다. 작업 항목들 및 CI들은 포함, 소유, 서비스 종속, 인과 관계 등과 같은 다양한 유형의 관계들에 의해 서로 또는 그들 사이에 연관될 수 있다. CMDB에서, CI는 다른 CI들을 포함할 수 있다. CI들은 복잡성 및 유형에서 크게 다를 수 있으며, 전체 시스템(하드웨어, 소프트웨어 및 문서를 포함함)에서 단일 소프트웨어 모듈 또는 사소한 하드웨어 컴포넌트까지의 범위일 수 있다. CI는 CI의 명칭, 기술, 위치, 상세한 기술 구성 설정들, 옵션들 등과 같은 속성들을 가질 수 있다. 요컨대, CMDB는 각각의 CI의 관련 상세들 및 CI들 사이의 관계들의 상세들을 포함하는 데이터베이스이다. 데이터베이스는 몇 가지 예로서 CI의 사본 및 일련 번호, 카테고리, 상태, 버전, 모델, 위치, 신뢰도 또는 항목에 대한 이력 정보와 같은 CI에 대한 정보를 포함할 수 있다.

CMDB가 선호될 수 있는 이유는 많은 IT 프로세스가 CMDB에 편리하게 저장되는 IT 아티팩트들 및 관계들을 처리하기 때문이다. 도 8에 도시된 바와 같이, 사건 관리, 변경 관리, 릴리스 관리 등과 같은 IT 관리 기능들(282)은 IT 기반구조(284)를 관리하는 동안 정보 교환 및 유지의 포인트로서 CMDB(280)를 이용할 수 있다. 또한, IT 관리 기능(282)에서의 대부분의 결정은 이러한 아티팩트들 및 관계들을 통해 판단되며, 프로세스의 자동화는 통상적으로 이러한 아티팩트들 및 관계들의 표현들을 처리할 것이다. 또한, CMDB는 이식 가능하고 확장 가능한 잘 정의된 기준 시스템 모델을 제공할 수 있다. 또한, 시간이 지남에 따라, 보다 많은 관리 제품들이 CMDB들, 특히 다른 제품들 또는 스택 컴포넌트들과의 상호 접속을 쉽게 할 수 있는 SDM 기반 CMDB들을 사용하기 시작할 것이다.

CMDB가 사용되는지의 여부에 관계없이, 아티팩트 스토어(110)는 바람직하게 소정의 특성들을 갖는다. 바람직하게는, 이것은 개체 관계형이어야 한다. 즉, 클래스, 관계, 구성, 그룹 및 제한의 개념이 이로울 것이다. 또한, 패키지들이 사실상 기존 기술 스택을 확장하는 경우, 아티팩트 스토어(110)가 확장성 및 상속성을 허가하는 경우에 도움이 된다. 따라서, 새로운 패키지들의 저자들은 아마도 다른 패키지들 또는 템플릿들에서 정의된 것들에 기초하여 새로운 클래스들 및 관계 유형들을 계속 정의할 수 있다. 또한, 구성 항목(CI), 관리되는 엔티티, 서비스, 자산 및 네트워크 장치 또는 클라이언트-서버와 같은 관계 유형과 같은 사전 정의 추상 클래스들로부터의 서브 클래싱이 패키지를 생성하는 데 필요한 작업을 줄일 수 있다.

도 9는 예시적인 작업 흐름 엔진(300)을 나타낸다. 전술한 바와 같이, 작업 흐름 프레임워크(114)는 임의의 다양한 기존 작업 흐름 엔진을 이용하여 구현될 수 있다. 도 9의 작업 흐름 엔진(300)은 소정의 작업 흐름 엔진들이 배열되고 기능하는 방법의 일례를 제공하는 것을 의도할 뿐이다. 작업 흐름 엔진(300)은 새로운 작업 흐름 정의(304)를 파싱하는 파서(302)를 구비한다. 컨트롤러(306)는 작업 흐름(304)의 인스턴스들을 실행하는 유닛이다. 컨트롤러(306)는 작업 흐름의 주제를 관리하고, 작업 흐름의 활동을 실행하고, 청취자를 호출하고, 이벤트를 청취하고, 타임아웃을 처리하고, 로깅을 수행하는 것 등을 행한다. 청취자(308)는 동기 활동으로서 구현될 수 있으며, 그의 사전 조건들이 만족될 때 컨트롤러(306)에 의해 호출된다. 청취자(308)는 작업 흐름의 착신 이벤트들을 청취한다. 로더(310)는 CMDB(280)와 같은 영구 스토어로부터 id에 의해 작업 흐름의 주제들을 로딩한다.

도 10은 사건들을 처리하기 위한 예시적인 작업 흐름(330)을 나타낸다. 작업 흐름(330)은 패키지를 이용하여 구현될 수 있는 구조화된 프로세스의 유형을 대표한다. 활동들(332)(패키지의 작업 흐름 부분에서 정의됨)은 작업 흐름(330)의 노드들이다. 작업 흐름(330)의 주제들은 작업 항목, 사용자, 이메일 등을 포함한다. 임의의 활동(332)은 기술 스택의 소정의 다른 컴포넌트에 의해 트리거될 수 있다. 다른 유형의 활동은 태스크 전송, 서비스 호출, 사람들에 대한 통지의 전송, 아티팩트 처리, 또는 (아티팩트를 참조할 수 있는) 링크 서버를 통한 다른 스택 컴포넌트의 아티팩트의 처리를 포함할 수 있다. 패키지의 작업 흐름 코드 부분은 또한, 무엇이 작업 흐름의 특정 인스턴스를 트리거하는지를 정의 또는 기술하는 정보를 포함할 수 있다. 또한, 패키지의 작업 흐름 코드 부분은 흐름 로직, 즉 활동들 간의 흐름에 대한 경로들 및 상태들을 기술해야 한다. 작업 흐름이 다른 스택 컴포넌트들과 상호작용할 수 있는 방법의 몇 가지 예를 고려한다. 작업 흐름은 CMDB 내의 작업 항목들 및 아티팩트들을 검색, 생성, 갱신 또는 삭제할 수 있다. 작업 흐름은 링크 프레임워크를 통해 외부 시스템들과 상호작용할 수 있으며, 예를 들어 관리 컴포넌트(예를 들어, MOM)에 의해 모니터링되는 서비스 상의 태스크를 실행할 수 있다. 또한, 작업 흐름은 이메일 또는 다른 수단을 통해 통지를 전송할 수 있다. 작업 흐름은 심지어 지식 기사에 특정 정보를 주석으로 첨부할 수 있다.

전술한 바와 같이, 패키지는 패키지 내에 기술되는 작업 흐름이 자동으로 생성, 실행 및 모니터링될 수 있도록 작업 흐름 엔진을 구성할 수 있어야 한다. 작업 흐름은 간단한 사건 처리 자동화에서 사용자에 의해 정의되고 장기 실행되는 복잡한 작업 흐름들에 이르는 임의의 것을 수반할 수 있다. 다음 섹션에서 설명되는 바와 같이, 패키지 저자들은 변경 허가, 에스컬레이션, 통지, 사건 처리, 자산 라이프 사이클 관리 등과 같은 IT 프로세스들에 대한 작업 흐름들을 정의할 수 있다. 기준 또는 표준 패키지(대부분의 생성된 패키지들에 의해 사용됨)는 예를 들어 MOF에서 발견되는 표준 동작들에 기초하여 템플릿들을 제공할 수 있다.

또한, 전술한 바와 같이, WWF는 작업 흐름 프레임워크로서 사용될 수 있다. 그러나, 코드를 작성해야 하는 것을 피하기 위해, 저작은 비주얼 스튜디오 작업 흐름 설계자에서 수행될 수 있다. 작업 흐름 유형들은 작업 항목 또는 아티팩트의 상태 변경 이벤트에 관련될 수 있다. 특정 상태 변경, 예를 들어 문제의 상태를 "해결됨"으로 설정하는 것은 문제 해결을 처리하기 위해 작업 흐름의 새로운 인스턴스를 개시할 수 있다. 작업 흐름의 컨텍스트는 작업 항목을 포함할 수 있으며, 따라서 작업 흐름 내의 로직은 그의 특성들 또는 관련 아티팩트들의 특성들, 예를 들어 문제의 의해 영향을 받는 서비스의 소유자의 이메일 어드레스에 액세스할 수 있다. 아웃-오브-더-박스 표준 작업 흐름 활동들의 라이브러리가 사건-해결, 사건-에스컬레이션, 사건-갱신, CMDB-갱신 등과 같은 활동들을 포함하는 아티팩트들을 처리하기 위해 제공될 수 있다. 표준 작업 흐름 활동들의 팔레트가 WWF 설계자 내에 제공될 수 있다. 이들은 이메일 전송, 버그 에스컬레이션, 또는 MOM, SMS, 익스체인지, 쉐어포인트 또는 TFS와 같은 링크된 제품들의 호출을 통한 소프트웨어의 전개와 같은 활동들을 포함할 수 있다. 이러한 접근법에서, 패키지 저자들은 코드를 작성할 필요 없이 활동들을 드래그 앤 드롭하여 사전 정의 프로세스들을 생성할 수 있다.

도 11은 작업 흐름을 선언적으로 정의하기 위한 마크업(350)을 나타낸다. 이예에서의 마크업(350)은 확장성 애플리케이션 마크업 언어(XAML)로 작성된다. 마크업(350)은 패키지로부터 추출되어 작업 흐름 프레임워크에 플러그 인되는 코드 부분일 수 있는 코드의 유형의 일례이다.

전술한 바와 같이, 기술 스택은 패키지들이 관련 지식으로 프로세스를 보조하는 데 사용할 수 있는 지식 프레임워크를 포함할 수 있다. 지식 프레임워크는 이상적으로는 문서들의 단순한 집합 이상이며, 오히려 지식 프레임워크는 인덱스를 생성하고, 검색들을 허가하고, 관련 기사들을 연관시키는 것 등과 같은 지식 관리 기능들을 가져야 한다. 특정 패키지의 컨텍스트와 같은 소정의 컨텍스트에서 기사들 간의 관계를 추적하고, 소정 기사에 어떤 기사들이 관련되는지를 알 수 있는 능력이 있어야 한다. 버그 보고, 사건 또는 문제와 같은 작업 항목들은 목적 또는 컨텍스트를 지시하는 분류를 가질 수 있다. 예를 들어, 작업 항목은 작업 항목이 패스워드 리셋에 대한 요청임을 지시하는 필드를 가질 수 있다. 소정의 관련 지식이 존재함을 지시하는 작업 항목의 패키지 내의 소정 정보가 존재할 수 있다. 이 정보는 작업 항목을 분류에 링크하는 링크일 수 있다. 사용자가 패스워드 변경을 요청하는 방법에 대해 아는 것이 필요한 경우, 사용자는 예를 들어 패스워드를 요청할 때 사용자의 관리자에게 이메일이 전송되는 것이 필요하거나, 인코딩된 프로세스에 따라 어떠한 단계들이라도 취해지는 것이 필요함을 지시하는 지식을 취득할 수 있다. 지식 집약 사용 시나리오들에서는, 지식의 라이프 사이클을 정의하는 작업 흐름 또는 패키지가 존재할 수 있는데, 예를 들어 소정의 사람 또는 역할이 화제에 대한 기사가 필요한 것으로 결정하고, 소정의 사람 또는 역할이 초안을 작성하고, 누군가가 그것을 검토하고, 누군가가 그것을 제품 내에 넣는 것 등이 행해진다. 지식 프레임워크는 마이크로소프트 쉐어 포인트, 웹 프론트 엔드들을 갖는 데이터베이스들, 팩티바, 애스크미, 사이트스케이프 등과 같은 상용 제품들을 이용하여 구현될 수 있다.

도 12는 링크 서버 또는 링크 프레임워크에 의해 링크될 수 있는 작업 항목들, 아티팩트들, 경보들 및 다른 것들의 예(370)를 나타낸다. 링크 프레임워크는 새로운 데이터 유형들 또는 클래스들 간의 새로운 커넥터들을 생성하는 데 사용될 수 있다. 솔루션 공간에 따라, 다른 외부 스토어들이 접속 또는 링크될 수 있다. 링크는 또한 스택 컴포넌트의 상부에 위치하는 웹 서비스가 존재할 때 가능할 수 있다. 이 경우, 링크된 항목들 간의 소정의 링크 및 변환들을 선언적으로 표현하는 것이 용이할 수 있다. 즉, 링크 프레임워크는 다른 컴포넌트(또는 MOM 또는 SMS와 같은 IT 관리 플랫폼)에 대응하는 아티팩트들을 갖는 하나의 컴포넌트에 대응하는 아티팩트들을 링크, 교환/동기화, 및 맵핑할 수 있는 능력을 제공할 수 있다. TFS 링크 및 라우터 서버(전술하였음)는 시스템들을 접속하는 데 사용될 수 있다. 아티팩트들 및 이들의 관계는 링크 서버에 등록된다. 일 실시예에서, 이러한 아티팩트들이 웹 서비스를 통해 이용 가능할 때, 링크 서버는 이러한 아티팩트들의 관계들 및 위치들을 유지할 수 있을 것이다. MOM, SMS 및 TFS 접속을 위한 커넥터들은 표준 템플릿 라이브러리에서 제공되는 바와 같이 생성 또는 사용될 수 있다. 간단한 실시예에서, 링크는 제1 개체/아티팩트에 대한 제1 고유 식별자와 제2 개체/아티팩트에 대한 제2 고유 식별자 사이의 연관일 수 있다. 이 실시예에서, 예들(370) 사이의 링크들은 예들(370)에 대응하는 고유 식별자들의 쌍들 간의 연관들의 세트일 것이다.

전술한 바와 같이, 일 실시예에서, 기술 스택은 확장 가능하다. 따라서, 새로운 패키지가 새로운 클래스들, 새로운 아티팩트들, 새로운 유형의 활동들, 아티팩들 간의 링크들, 새로운 작업 흐름들 등을 정의하는 경우, 스택 컴포넌트들은 이 새로운 정보를 학습하고 그에 적응할 수 있다. 스택 컴포넌트들은 패키지로부터의 새로운 정보에 따라 재구성 또는 확장된다. 스택 컴포넌트들은 바람직하게는 그들의 기능을 확장하는 데 사용될 수 있는 확장성 API들 및 추상화 계층들을 갖는다. 이러한 기술 스택의 특징들은 패키지가 프로세스, 및 프로세스의 정의가 프로세스를 자동화하는 기술 스택으로부터 명확히 분리되는 것을 가능하게 하는 관련 메타데이터의 독립식 인코딩으로 기능하는 것을 더 쉽게 할 수 있다.

패키지 특징들 및 프로세스들의 예들

패키지는 운영 환경 또는 기술 스택에 플러그 인될 수 있는 프로세스의 외부 표현 또는 모델로서 기능할 수 있으며, 스택 기술 및 생성 환경과 패키지 자체 사이에 차이가 존재한다는 점에 유의한다. 동일 패키지가 상이한 IT 시스템들의 상이한 기술 스택들에 플러그 인될 수 있다. 패키지는 새로운 링크들, 스택 내의 상이한 장소들에서 발생하는 작업을 갖는 새로운 작업 흐름들, 새로운 문서들 및 그들에 대한 링크들, 및 새로운 서식들을 수용할 수 있다. 또한, 이러한 정보는 선언적인 방식으로 인코딩될 수 있다. 즉, 저자는 패키지 내에 서식을 선언할 수 있는데, 예를 들어 블로그 내에 드롭다운 메뉴의 배치를 정의하고, 다른 장소에 텍스트 필드를 정의하고, 다른 장소에 박스를 정의하고, 드롭다운이 선언된 선택들의 리스트로부터 선택된 데이터 소스에 첨부될 것임을 선언하고, 인터페이스 요소들이 이들이 선택에 따라 표시할 것을 제한할 것임을 선언하는 것 등을 행할 수 있다. 이러한 유형의 정보는 스택 또는 그것을 수행할 운영 환경 내에 표현될 수 있다. 유사하게, 보고들은 하드코딩되는 것이 아니라 초록 내에 선언될 수 있다.

소정의 실시예들에서, 패키지들은 메타데이터 구동 솔루션들이다. 솔루션이 개발될 기술 스택이 주어질 때, 스택 컴포넌트에 새로운 데이터 유형을 추가하는 것이 가능할 수 있다. 그러나, 이 단계는 단독으로는 유효하지 않은데, 이는 이제 예를 들어 작업 흐름이 올바른 데이터 유형들을 갖지 않을 것이므로 동작하지 않을 수 있고, 저자가 새로운 데이터 유형을 처리할 수 있도록 작업 흐름의 데이터 유형들을 수정하기 위해, 예를 들어 추가된 새로운 속성에 대하여 알기 위해 기존 작업 흐름을 검토해야 할 수도 있기 때문이다. 유사하게, 기존 서식들은 서식 저자가 속성에 대해조차 몰랐기 때문에 그러한 데이터 유형을 바로 "실행"하지 못할 수 있다. 따라서, 패키지 내에서 이러한 것들을 함께 시도함으로써 패키지는 프로세스의 독립식 인코딩일 수 있으며, 패키지는 기술 스택 내에 넣어질 수 있고, 그가 기술하는 기능 및 데이터는 기술 스택 전반에서 활성화된다. 이것은 기술 스택의 부분들이 패키지 내의 메타데이터 언어를 이해하고, 따라서 하나의 결합 단위로서 함께 패키지를 "실행"할 수 있는 경우에 특히 가능하다. 더 설명하면, 패키지는 새로운 속성들 등을 갖는 새로운 것들이 존재함을 스택에게 알릴 수 있고, 패키지는 이러한 새로운 것들을 시스템의 다양한 부분들 내의 다른 것들에 링크할 수 있다. 이어서, 스택 레벨에서, 패키지는 이러한 링크 가능한 새로운 것들이 기술 스택 전반에서 처리될 수 있다는 가정하에 생성될 수 있다. 예를 들어, 활동들을 갖는 새로운 작업 흐름이 새로운 것들을 처리하거나, 새로운 것이 소정의 방식으로 변경될 때 컴포넌트 내의 트리거들이 호출될 수 있다.

더욱 더 설명하기 위해, 아티팩트 스토어들(예를 들어, 개체 지향 데이터베이스들, CMDB들 등), 서식 프레임워크들(예를 들어, 오피스 12), 작업 흐름 엔진들(예를 들어, WWF), 정보 작업자 프로덕티비티 스위트들, 및 전술한 다른 것들과 같은 다양한 이용 가능 소프트웨어 제품이 존재하는 것을 고려한다. 이러한 종류의 제품들(스택 컴포넌트들)은 소정의 방식들로 수렴될 수 있다. 예를 들어, 많은 제품은 SDM 또는 다른 XML 기반 모델링 언어들과 같은 선언 코드를 이용하여 확장될 수 있는 개체 모델들 및 기능을 갖거나 가질 것이다. 즉, 이들은 상이한 컴포넌트들에 대해 동일 언어일 수 있는 선언 코드에 의해 구성될 수 있다. 그러나, 조직의 기술 스택의 이러한 상이한 컴포넌트들은 이전에는 하나의 결합 단위로서 프로그래밍(구성) 또는 확장되지 않았다. 본 명세서에 설명되는 소정 실시예들에 따르면, 이식 가능 패키지들은 이제,이러한 컴포넌트들의 개체 모델들을, 표준이거나 표준이 아니든, XML, SDM 또는 다른 언어들과 같은 모델링 언어를 이용하여 선언적으로 확장하는 이들의 공통 능력을 이용함으로써 이들을 "함께 와이어링"하는 데 사용될 수 있다.

프로그래밍 언어가 한 세트의 표준 라이브러리들을 가질 수 있는 것처럼, 기술 스택은 다른 패키지들이 참조하고, 사용하거나 확장할 수 있는 한 세트의 표준 패키지들을 가질 수 있다. 이러한 표준 패키지들은 특정 시나리오들에 집중될 수 있으며, 후술하는 그러한 시나리오들과 관련된 기본 아티팩트들, 활동들, 링크들 등을 정의할 수 있다.

IT 관리의 분야에서, 서비스 관리 시나리오들은 패키지화된 이식 가능 솔루션들을 이용하여 자동화될 수 있다. 많은 스택 컴포넌트를 터치할 수 있는 호출 관리를 위한 프로세스들이 인코딩될 수 있으며, 전화, 채팅, 이메일 또는 심지어 웹을 통한 착신 "호출들"은 호출 큐 관리, 컴퓨터 전화 통합(CTI), 지능형 음성 응답(IVR), 자동 서식 팝퓰레이션, 및 프레전스와 통합될 수 있다. 사건 관리 시나리오들, 예를 들어 사건의 라이프 사이클을 통한 사건의 상태 변화 및 소유권의 관리를 수반하는 사건 추적이 또한 인코딩될 수 있다. 사건 관리 프로세스는 분류의 자동 팝퓰레이션, 서비스 및 자산의 지식의 문제 및 가시성과의 연관, 자산 데이터의 사전 발견, 및 변화 이력을 포함할 수 있다. 요청 관리 프로세스들도 패키지들 내에 인코딩될 수 있다. 프로세스들은 정보 및 하드웨어 또는 소프트웨어 업그레이드들에 대한 요청들의 처리를 포함할 수 있다. 서비스 관리 프로세스 패키지들은 예를 들어 MOM 또는 외부 서비스 데스크와 같은 이벤트 또는 성능 관리 시스템으로부터 사건들을 자동 생성함으로써 서비스 모니터링 프로세스들과 통합될 수 있다. 문제 관리 솔루션들도 자동화될 수 있다. 이러한 패키지들은 사건들을 근본적인 문제의 전조들로서 인식하고, 구성, 토폴로지, 지식의 가시성, 및 사건들 간의 공통성을 제공하는 것을 수반하여, 그들이 문제들을 해결하는 것을 도울 수 있다. 또 하나의 서비스 관리 프로세스 유형은 근본 원인 분석이다. 이러한 유형의 프로세스들은 CMDB 내의 상호 종속성 맵들, 및 서비스 및 자산의 현재 상태들을 이용하여 근본적인 진정한 문제들을 자동으로 인식한다. 서비스 레벨 관리 프로세스들이 패키지 내에 인코딩될 수 있다. 이들은 서비스 레벨 협약(SLA)들에 아마도 결합되는 사건 우선 순위화, 에스컬레이션, 통지, 또는 서비스 및 문제 유형에 의한 미세한 SLA들의 설정을 자동화할 수 있다. 통지 및 저서 보존 솔루션들이 패키지 내에 저장될 수 있다. 예를 들어, 이러한 패키지는 사건들의 처리시에 기록을 보존하고 적절한 시간에 이해 관계자들에게 필요한 통지들을 전송하는 프로세스를 자동화할 수 있다. 다른 예는 버그로 간주된 문제가 TFS와 같은 버그 추적 시스템을 통해 에스컬레이트되는 버그 에스컬레이션이다. 솔루션 패키지의 서비스 관리 유형의 또 하나의 유형은 사건 분류 및 사전 수집된 구성 데이터에 기초하여, 아마도 지식 기반의 등급들에 기초하여, 적절한 대응 지식을 이용하여 분석이 제공되는 지식 사용 및 유지와 관련된다. 보다 높은 계층의 분석자들은 대형 문제들을 방지하기 위해 지식을 규칙적으로 갱신할 수 있다.

변경 관리는 패키지들 내에 인코딩될 수 있는 프로세스들을 갖는 또 하나의 영역이다. 잘못 관리된 IT 변경은 IT 시스템의 사건들 및 고장 시간의 주요 원인이다. 변경 관리 프로세스들은 고장 시간을 최소화하기 위해 변경들을 제어 방식으로 도입하는 데 사용되는 프로세스들이다. 변경의 기본 항목은 종종 주문 변경으로서 참조되며, 변경들을 통해 추적되는 항목의 기본 단위는 구성 항목 또는 CI(전술하였음)라고 한다. CI는 모델 기반 관리 접근법의 부분들인 관리되는 엔티티 또는 관계일 수 있다. 그러나, CI는 정책, 사용자 그룹, 또는 계약 및 관련 관계들일 수도 있다. 소정의 특정 인코딩 가능 변경 관리 시나리오들 또는 프로세스들은 다음을 포함한다. 변경 허가 및 승인은 주문 변경의 생성에서 완료까지의 작업 흐름을 구동하고, 이해 관계자들(예를 들어, 위험 관리자, 예산 관리자, 스케쥴러, 서비스 소유자 및 최종 사용자)로부터 필요한 허가 및 승인을 확보함으로써 구조화될 수 있다. 변경 관리를 위한 프로세스들이 생성되거나 맞춤화될 수 있다. 이메일, 포탈 등을 통해 피영향자들이 임박한 변경에 대하여 통지받게 유지할 수 있는 변경 통지 프로세스들이 생성될 수 있다. 위험 관리자들이 하나 이상의 서비스에서 요청된 변경을 행하는 것의 영향(또는 위험)을 평가하는 것을 돕기 위한 영향 분석 프로세스들이 인코딩될 수 있다. 이러한 프로세스는 CMDB 내의 관계들을 이용하여 자동화될 수 있다. 스케쥴러들이 아마도 변경 윈도우들, 서비스 스케쥴들 및 필요한 직원의 가용성에 기초하여 변경에 최소한의 악영향을 미치는 적절한 기회들을 발견하는 것을 돕는 것을 포함할 수 있는 변경 스케쥴링 프로세스가 생성될 수 있다. 구성 감사 프로세스들도 패키지화될 수 있으며, 이러한 프로세스들은 예를 들어 SMS 요구 구성 관리(DCM) 및 물리적 목록 도구들을 이용하여 조사된 실세계 정보와 구성 정보를 비교하는 것을 포함할 수 있다.

성능 관리 및 보안 관리를 위한 프로세스들도 프로세스 패키지 내에 캡처될 수 있다. 보안 관리 프로세스들의 예는 조사 및 통지 활동들과 결합된 경보들, 권장되는 지식이 관리자에게 제공되게 하는 자동화된 분석 등을 포함한다.

자산 관리와 관련된 프로세스들도 이식 가능 스택 플러그 가능 패키지들 내에 캡처될 수 있다. 자본 설비 결정들은 종종 서비스 정보를 고려하는 소유 총 비용(TCO) 보고들에 기초한다. 이러한 결정들은 변경 관리를 통해 변경들을 구동할 수 있다. 구체적으로, 자산 및 구성 추적 프로세스가 서비스, 자산, 사용자, 구성, 정책 및 이들 서로의 연관성과 같은 CI들을 경시적으로 추적하는 데 사용될 수 있다. 이것은 자산의 소유권, 자산이 어디에 책정되어 있는지, 자산이 어느 서비스에 참여하고 있는지, 또는 파산의 경우에 누구를 호출해야 하는지에 대해 쿼리하는 것과 같은 종속 프로세스들을 허가할 수 있다. 주문 변경들의 자동화된 실행은 바람직하게는 기업 아티팩트 스토어 내에 이러한 데이터를 최신으로 유지한다. 또 하나의 인코딩 가능 자산 관리 프로세스는 환경 내의 소프트웨어의 존재 및 사용을 자동 검사하고, 비용 및 라이센스 위험을 줄이기 위한 액션을 취하는 것을 포함하는 소프트웨어 라이센스 준수 관리이다. TCO 추적 프로세스는 특정 서비스 또는 자산에 대해 경시적으로 서비스 및 변경 비용을 보고할 수 있다. 이 정보는 빌링, 아웃소싱, 자본 상품 및 벤더 선택에 관한 결정들을 행하는 데 이용될 수 있다.

결론

요컨대, 하나 이상의 실시예에서, 단일 플러그 앤 플레이 패키지(다른 플러그 앤 플레이 패키지들을 참조할 수 있고, 따라서 논리적으로 이들을 포함할 수 있다)는 다른 접속된 제품들(스택 외부)에 관련된 사람들 및 자동화를 수반하는 완전한 IT/비즈니스 프로세스의 통합을 전달하도록 컴포넌트들의 스택을 일관된 방식으로 구동하는 능력을 가질 수 있다. 스택의 컴포넌트들은 컴포넌트들의 특성이 주어질 때 서로 직접 통신하거나 통신하지 않을 수 있다. 그러나, 관련 컴포넌트들 모두는 협동할 수 있다. 특히, 스택 컴포넌트(예를 들어, 서식, 작업 흐름, 아티팩트의 클래스)의 선언적 구성은 기반 선언 구성들, 예를 들어 스키마 및 작업 흐름 활동들에 대한 지식으로 인해, 이들이 마침 동일 플러그 앤 플레이 패키지 내에 있으므로, 기반 컴포넌트(예를 들어, CMDB 또는 작업 흐름 엔진)의 거동에 대한 지식을 이용하여 표현될 수 있다.

이 분야의 전문가들은 프로그램 명령어를 저장하는 데 사용되는 저장 장치들이 네트워크 전반에 분산될 수 있다는 것을 이해할 것이다. 예를 들어, 원격 컴퓨터는 소프트웨어로서 기술되는 프로세스의 일례를 저장할 수 있다. 로컬 또는 단말 컴퓨터는 원격 컴퓨터에 액세스하고, 소프트웨어의 일부 또는 전부를 다운로드하여 프로그램을 실행할 수 있다. 대안으로, 로컬 컴퓨터는 필요에 따라 소프트웨어의 부분들을 다운로드하거나, 일부 소프트웨어 명령어를 로컬 단말기에서 실행하고 일부를 원격 컴퓨터(또는 컴퓨터 네트워크)에서 실행함으로써 분산 처리할 수 있다. 이 분야의 전문가들은 또한, 이 분야의 전문가들에게 공지된 통상의 기술들을 이용하여 소프트웨어 명령어의 전부 또는 일부가 DSP, 프로그래머블 로직 어레이 등과 같은 전용 회로에 의해 실행될 수 있다는 것을 이해할 것이다.

상기 설명된 실시예들 및 특징들 모두는 휘발성 및/또는 비휘발성 컴퓨터 또는 장치 판독가능 매체에 저장된 정보의 형태로 구현될 수 있다. 이것은 기계 실행가능 명령어(실행 전, 실행 중, 또는 이들 양자), 또는 소스 코드, 또는 컴퓨팅 장치들이 상기 설명된 다양한 실시예를 수행할 수 있게 하거나 구성하는 데 사용될 수 있는 임의의 다른 정보를 저장하는 CD-ROM, 자기 매체, 플래시 ROM 등과 같은 매체를 적어도 포함하는 것으로 간주된다. 이것은 또한, 일 실시예를 수행하는 프로그램의 실행 중에 CPU 명령어와 같은 정보를 저장하는 RAM과 같은 휘발성 메모리를 적어도 포함하는 것으로 간주된다.

Claims (34)

1. 패키지를 저장하는 하나 이상의 휘발성 및/또는 비휘발성 컴퓨터 판독가능 매체로서,

   상기 패키지는,

   상기 패키지에 의해 정의되는 비즈니스 프로세스를 협동하여 자동하도록 기업 기술 스택의 개별 컴포넌트들을 구성하기 위한 구성 정보 - 상기 기업 기술 스택 컴포넌트들은 확장성 아티팩트 스토어, 확장성 작업 흐름 엔진 및 확장성 서식 프레임워크를 포함함 -

   를 포함하고,

   상기 구성 정보는,

   상기 패키지의 비즈니스 프로세스에 포함된 인간의 역할들의 유형들 및 상기 패키지의 비즈니스 프로세스에 포함된 컴퓨팅 장치들 및/또는 소프트웨어 서비스들의 유형들을 적어도 포함하는, 상기 패키지의 비즈니스 프로세스의 일부인 기업 아티팩트들의 하나 이상의 유형들을 정의하는 아티팩트 정의 정보;

   상기 패키지의 비즈니스 프로세스와 관련된 정보를 입력하고 그리고/또는 보기 위한 하나 이상의 상호작용 서식을 정의하는 서식 정의 정보; 및

   상기 패키지의 비즈니스 프로세스의 하나 이상의 작업 흐름을 정의하는 작업 흐름 정의 정보

   를 포함하고,

   상기 작업 흐름 정의 정보는 상기 아티팩트 정의 정보에 의해 정의되는 기업 아티팩트들의 유형들에 대한 참조들 또는 링크들 및 상기 서식 정의 정보에 의해 정의되는 하나 이상의 서식에 대한 링크들 또는 참조들을 포함하는 하나 이상의 컴퓨터 판독가능 매체.
2. 제1항에 있어서, 상기 아티팩트 정의 정보는 상기 아티팩트 정보에 의해 정의되는 하나 이상의 유형의 기업 아티팩트들의 표현들을 인스턴스화하고 저장하도록 상기 아티팩트 스토어를 구성하는 데 사용될 수 있는 하나 이상의 컴퓨터 판독가능 매체.
3. 제2항에 있어서, 상기 작업 흐름 정의 정보는 상기 작업 흐름 엔진이 상기 작업 흐름 정보에 의해 정의되는 작업 흐름의 작업 흐름 인스턴스들을 인스턴스화하는 것을 가능하게 하는 데 사용될 수 있는 하나 이상의 컴퓨터 판독가능 매체.
4. 제3항에 있어서, 상기 서식 정의 정보는 기업 전반의 디스플레이들이 정보를 입력하고 보기 위한 상호작용 서식들을 표시하는 것을 가능하게 하는 데 사용될 수 있는 하나 이상의 컴퓨터 판독가능 매체.
5. 제1항에 있어서, 상기 구성 정보의 적어도 일부가 시스템 정의 모델링(SDM) 언어의 형태이거나, 그로부터 컴파일되는 하나 이상의 컴퓨터 판독가능 매체.
6. 제5항에 있어서, 상기 SDM 언어는 표준 마크업 언어에 기초하는 하나 이상의 컴퓨터 판독가능 매체.
7. 제6항에 있어서, 상기 표준 마크업 언어는 XML을 포함하는 하나 이상의 컴퓨터 판독가능 매체.
8. 제1항에 있어서, 상기 패키지는 이식 가능하며, 따라서 상이한 애플리케이션들이 상기 패키지를 이용하여, 상기 패키지에 의해 정의되는 비즈니스 프로세스를 수행하도록 기업 기술 스택들의 상이한 인스턴스들을 구성할 수 있는 하나 이상의 컴퓨터 판독가능 매체.
9. 제1항에 있어서, 상기 패키지는 하나 이상의 다른 패키지에 대한 하나 이상의 참조를 더 포함하는 하나 이상의 컴퓨터 판독가능 매체.
10. 제1항에 있어서, 상기 구성 정보는 선언 코드를 포함하는 하나 이상의 컴퓨터 판독가능 매체.
11. 제10항에 있어서, 상기 선언 코드는 XML 기반 언어를 포함하는 하나 이상의 컴퓨터 판독가능 매체.
12. 제1항에 있어서, 상기 패키지에 의해 정의되는 비즈니스 프로세스는 정보 기술(IT) 관리 프로세스를 포함하는 하나 이상의 컴퓨터 판독가능 매체.
13. 제12항에 있어서, 상기 IT 관리 프로세스는 변경 관리 프로세스를 포함하는 하나 이상의 컴퓨터 판독가능 매체.
14. 제12항에 있어서, 상기 IT 관리 프로세스는 사건 관리 프로세스를 포함하는 하나 이상의 컴퓨터 판독가능 매체.
15. 제12항에 있어서, 상기 IT 관리 프로세스는 릴리스 관리 프로세스를 포함하는 하나 이상의 컴퓨터 판독가능 매체.
16. 제10항에 있어서, 상기 프로세스는 정보 기술 기반구조 라이브러리(ITIL)에 정의되는 프로세스에 대응하는 하나 이상의 컴퓨터 판독가능 매체.
17. 제1항에 있어서, 상기 패키지는 상기 패키지의 제공자를 인증하는 데 사용될 수 있는 상기 패키지의 디지털 서명을 더 포함하는 하나 이상의 컴퓨터 판독가능 매체.
18. 제1항에 있어서, 상기 패키지는 상기 패키지의 버전을 지시하는 버전 정보를 더 포함하는 하나 이상의 컴퓨터 판독가능 매체.
19. 프로세스를 기술하는 패키지를 생성하는 방법으로서,

    이식 가능 패키지에 프로세스 정의 정보를 저장하는 단계

    를 포함하고,

    상기 프로세스 정의 정보는,

    상기 프로세스에 대응하는 작업 흐름을 정의하는 작업 흐름 정의 정보 - 상기 작업 흐름 정의는 작업 흐름 엔진에 플러그 인되는 경우에 상기 작업 흐름 엔진이 상기 작업 흐름의 인스턴스들을 인스턴스화하고 실행하는 것을 가능하게 함 - ;

    서식, 및 상기 서식을 상기 작업 흐름 정의 정보에 의해 정의되는 작업 흐름에 링크하는 정보를 정의하는 서식 정의 정보 - 상기 서식 정의 정보는 서식 프레임워크에 플러그 인되는 경우에 상기 서식 프레임워크가 상기 서식을 사용자들에게 표시하는 것을 가능하게 함 - ; 및

    아티팩트들의 하나 이상의 클래스, 및 상기 아티팩트들을 상기 작업 흐름 정의에 링크하는 정보를 정의하는 아티팩트 정의 정보 - 상기 아티팩트 정의 정보는 아티팩트 스토어에 플러그 인되는 경우에 상기 아티팩트 스토어가 상기 아티팩트 정의 정보에 의해 정의되는 유형의 아티팩트들을 저장하는 것을 가능하게 함 -

    를 포함하는 패키지 생성 방법.
20. 제19항에 있어서, 상기 저장 단계는 상기 패키지의 저자를 식별하는 정보, 상기 패키지의 다른 패키지에 대한 종속성 및 상기 패키지가 따르는 패키징 스키마를 포함하는 패키지 정보를 상기 패키지 내에 저장하는 단계를 더 포함하는 패키지 생성 방법.
21. 제19항에 있어서, 링크 프레임워크에 플러그 인되는 경우에 상기 링크 프레임워크가 상기 작업 흐름 엔진, 상기 서식 프레임워크 또는 상기 아티팩트 스토어 중 어느 하나 내의 항목들을 상기 작업 흐름 엔진, 상기 서식 프레임워크 또는 상기 아티팩트 스토어 중 다른 하나 내의 항목들과 링크하는 것을 가능하게 하는 링크 정보를 상기 패키지 내에 저장하는 단계를 더 포함하는 패키지 생성 방법.
22. 제19항에 있어서, 상기 프로세스 정의 정보를 저장하는 단계는 상기 프로세스 정의 정보를 선언 코드로서 형성하는 단계를 포함하고, 상기 작업 흐름 정의 정보, 상기 서식 정의 정보 및 상기 아티팩트 정의 정보는 상기 작업 흐름 엔진, 상기 서식 프레임워크 및 상기 아티팩트 스토어에 의해 각각 구현되는 언어의 코드의 각각의 부분들을 포함하는 패키지 생성 방법.
23. 제22항에 있어서, 다른 프로세스 정의 정보를 포함하는 다른 패키지에 대한 참조를 상기 패키지 내에 저장하는 단계를 더 포함하는 패키지 생성 방법.
24. 제19항에 있어서, 상기 프로세스 정의 정보는 링크 프레임워크에 플러그 인되는 경우에 상기 링크 프레임워크가 상기 작업 흐름 엔진, 상기 서식 프레임워크 및 상기 아티팩트 스토어의 상이한 부분들에 저장되는 상기 프로세스 정의 정보의 상이한 부분들에 의해 정의되는 상이한 항목들을 링크하는 것을 가능하게 하는 링크 정보를 더 포함하는 패키지 생성 방법.
25. 제19항에 있어서, 상기 프로세스 정의 정보는 포탈 프레임워크에 플러그 인되는 경우에 상기 포탈 프레임워크가 상기 프로세스 정의 정보에 의해 정의되는 프로세스의 일부인 포탈을 표시하는 것을 가능하게 하는 포탈 정보를 더 포함하는 패키지 생성 방법.
26. 제25항에 있어서, 상기 프로세스 정의 정보는 지식 프레임워크에 플러그 인되는 경우에 상기 지식 프레임워크가 상기 프로세스 정의 정보에 의해 정의되는 프로세스와 관련된 지식을 사용자들에게 제공하는 것을 가능하게 하는 지식 정보를 더 포함하는 패키지 생성 방법.
27. 패키지를 저장하는 하나 이상의 휘발성 또는 비휘발성 컴퓨터 판독가능 매체로서,

    상기 패키지는,

    비즈니스 또는 IT 관리 프로세스를 정의하고, 상기 프로세스의 작업 흐름, 상기 프로세스의 아티팩트들의 유형들, 및 상기 프로세스의 형태들을 포함하는 선언 코드 - 상기 선언 코드는 정보 기술(IT) 스택에 플러그 인되어 상기 IT 스택이 상기 선언 코드에 의해 정의되는 프로세스를 실행하는 것을 가능하게 할 수 있음 - ;

    상기 패키지를 식별하는 패키지 식별 정보; 및

    상기 패키지를 포맷하는 스키마, 또는 상기 스키마에 대한 참조를 포함하는 스키마 정의

    를 포함하는 하나 이상의 컴퓨터 판독가능 매체.
28. 제27항에 있어서, 상기 패키지 식별 정보는 상기 패키지의 제작자 또는 저자, 상기 패키지의 버전 번호, 상기 패키지가 종속하는 다른 패키지, 또는 상기 패키지를 인증하기 위한 보안 인증서 중 둘 이상을 포함하는 하나 이상의 컴퓨터 판독가능 매체.
29. 제27항에 있어서, 상기 선언 코드는 시스템 정의 모델링 언어에 따르는 하나 이상의 컴퓨터 판독가능 매체.
30. 제27항에 있어서, 상기 비즈니스 또는 IT 관리 프로세스를 정의하는 선언 코드는 상기 IT 스택 내의 작업 흐름 프레임워크에 의해 사용될 수 있는 부분, 상기 IT 스택 내의 서식 프레임워크에 의해 사용될 수 있는 부분, 및 상기 IT 스택 내의 아티팩트 스토어에 의해 사용될 수 있는 부분을 포함하는 하나 이상의 컴퓨터 판독가능 매체.
31. 제30항에 있어서, 상기 작업 흐름 프레임워크, 상기 서식 프레임워크 및 상기 아티팩트 스토어는 다른 컴포넌트들과 무관하게 설치되고 사용될 수 있는 상기 IT 스택의 개별적이고 자동적인 컴포넌트들인 하나 이상의 컴퓨터 판독가능 매체.
32. 제31항에 있어서, 상기 아티팩트 스토어는 구성 항목들 및 그들 간의 관계들을 저장하는 하나 이상의 컴퓨터 판독가능 매체.
33. 제32항에 있어서, 상기 아티팩트 스토어는 구성 관리 데이터베이스(CMDB)를 포함하는 하나 이상의 컴퓨터 판독가능 매체.
34. 제27항에 있어서, 상기 비즈니스 또는 IT 프로세스를 정의하는 선언 코드는 상기 프로세스에 포함된 사람들 또는 역할들, 및 상기 IT 스택을 통한 상기 사람들 또는 역할들로의 그리고/또는 그들로부터의 활동 흐름을 지정하는 하나 이상의 컴퓨터 판독가능 매체.

Images