엔터프라이즈 아키텍처는 정보 기술과 밀접한 관련이 있습니다. 이 문서에서는 SOA (서비스 지향 아키텍처) 환경에서 단순화된 하향식 엔터프라이즈 아키텍처에 대해 설명하고 비즈니스와 IT 간의 최적의 정렬을 위해 정보 기술에 초점을 맞추겠습니다.
나는 소개할 것이다.
하향식 엔터프라이즈 아키텍처에 대한 여러 가지 우려 사항 엔터프라이즈 아키텍처의 목표 방법 및 BEA SOA 영역 모델과의 관계를 요약합니다. 이 문서에서는 비즈니스 전략 및 관련 조직의 고려 사항에 따라 하향식 엔터프라이즈 아키텍처의 장점을 이해할 수 있습니다.
하향식 엔터프라이즈 아키텍처에 대한 다양한 관심 분야 하향식 접근 방식, 비즈니스에서 it 에 이르기까지 다양한 계획에서 비즈니스 및 IT 에 대한 다양한 관심 지점을 분리하여 그 사이에 기반을 마련해야 합니다. 비즈니스 관련 계획의 기초를 비즈니스 프로세스 계획, IT 관련 계획을 애플리케이션 계획, 기능 계획이라고 하며, 비즈니스와 IT 간의 최상의 일치를 제공하도록 설계되었기 때문에 이 접근 방식에서 가장 중요한 부분입니다. 하드웨어, 네트워크, 운영 체제, 애플리케이션 서버, 데이터베이스를 설명하려면 기술 계획의 개념을 도입할 수 있습니다. 기술 계획에 대해 자세히 설명하지 않겠습니다. 제 주된 목적은 공개를 바탕으로 IT 와 비즈니스 간의 최적의 정렬을 위한 방법을 추천하는 것입니다.
도표는 이러한 계획과 그 상호 관계를 설명하며, 나는 그것들을 상세히 소개할 것이다.
하향식 엔터프라이즈 아키텍처의 다양한 관심 분야
비즈니스 프로세스 계획 이 계획은 비즈니스 전략 환경의 비즈니스 프로세스에 중점을 둡니다. 조직의 다양한 업무 라인과 긴밀하게 협력할 수 있는 엔터프라이즈 아키텍처는 비즈니스 전략에 정의된 비즈니스 요구 사항으로 시작할 수 있으며 기업의 주요 비즈니스 프로세스를 모델링할 수 있습니다. 예를 들어 엔터프라이즈 아키텍처는 AQualogic BPM 디자이너를 통해 설계 수준에서 이러한 목표를 달성할 수 있습니다. 이를 통해 설계자는 기업의 전반적인 주요 프로세스를 이해하고 더 많은 작업을 수행할 수 있습니다. 영업 담당자의 참여도 이런 방식으로 추진할 수 있다. AquaLogic BPM Designer 를 통해 비즈니스 분석가는 비즈니스 프로세스를 시뮬레이션하고 프로세스가 반전될 때 최적화 조치를 제공할 수 있습니다. 비즈니스 프로세스 계획은 비즈니스 자체에 속합니다. 모든 설계자의 주요 임무는 비즈니스 요구 사항을 파악하고 조직 내 여러 업무 라인에서 사용할 수 있는 동일한 비즈니스 서비스를 확인하는 것입니다.
은행 업무 환경을 예로 들면, 먼저 다양한 은행 업무 프로세스 (예: 대출 임포트/익스포트 작업) 를 설계해야 한다. 두 은행 업무 프로세스는 완전히 다르지만 일부 * * * * 동일한 서비스를 받을 수 있습니다. * * * 조직 수준에서 프로세스를 설계하여 동일한 서비스를 확인합니다. 어느 정도 승인 시스템과 회계 시스템은 신용장 발행 (LC) 프로세스나 대출 승인 프로세스와 같은 여러 프로세스에서 재사용할 수 있어야 합니다. 두 가지 방법을 사용할 수 있어야 합니다.
조직의 주요 프로세스에 대한 기능 계획 및 설계를 수행한 후 주요 기능 블록을 식별할 수 있습니다. 기능 블록은 서로 다른 업무 프로세스에서 재사용할 수 있는 업무 서비스를 제공합니다. 비즈니스 서비스는 SOA 에 이상적인 빌딩 블록입니다. 또한 이러한 서비스를 재사용하고 재구성하여 업무에 필요한 민첩성을 제공해야 합니다. 이러한 기능 블록과 기능 블록 간에 공유해야 하는 데이터를 선택할 때 업무 라인은 기업 설계자에게 표준화된 데이터 모델 도메인 UML 모델 및 데이터 저장소를 재사용하고 이해할 수 있는 충분한 비즈니스 지식을 제공해야 합니다. 그런 다음 계획에 비즈니스를 추가해야 합니다.
이 일반적인 접근 방식은 조직 전체에서 사용할 수 있는 공통 언어와 분류를 가져와야 하며, 공통 개체 및 공통 도메인 모델의 정의는 해당 의미를 조직 전체에서 공통으로 만들고 다른 업무 라인에서 재사용할 수 있도록 해야 합니다. 이 계획은 조직의 다양한 업무 라인과 관련된 지역 및 구역으로 기능 구성 요소를 구성하는 도시 계획과 같습니다.
공통 언어는 기능 구성요소의 재사용과 구성요소 간의 데이터 공유에 유용합니다. 표준화된 모델은 엔터프라이즈 저장소에서 관리해야 합니다. 이러한 모델에 대한 설계 액세스 검증 및 수정 방법을 정의해야 합니다. 이 기사의 뒷부분에서 이러한 고려 사항을 자세히 설명하겠습니다.
은행의 예로 돌아가면, 이 조직에는 지불, 외화 환전, 담보를 처리하는 업무 라인이 있어야 하고, 또 다른 업무 라인은 대출을 처리하고, 세 번째 업무 라인은 신용장 (LC) 과 수거와 같은 수입/수출 업무를 처리하고, 수평 업무 라인은 승인된 회계 보고 및 위험 관리를 처리해야 한다. 도시계획을 비유하면 각 업무선은 하나의 특구로 볼 수 있다.
수출입 업무 라인을 더 살펴보면 LC 와 수거와 관련된 기능 블록이 LC 가 제공해야 할 다양한 서비스로 세분화될 수 있음을 알 수 있습니다. 이 block 은 신용장 개설, 신용장 수정, 신용장 사용, 상환신용장 등 기능 (또는 서비스) 을 제공해야 하는데, 이것들은 모두 LC block 의 업무 서비스이다. 이러한 서비스는 승인 블록 회계 블록 및 지불 블록에서 제공하는 기능에 따라 달라집니다.
승인 모듈은 고객 상태에 따라 고객에게 신용 한도를 부여합니다. 승인 블록은 위험 관리 블록의 기능에 따라 달라질 수 있습니다. LC 기능은 또한 계정 및 지불 블록에서 제공하는 서비스를 사용하며, 지불 블록은 계정 및 승인 블록의 기능을 사용합니다.
기능 계획에 대한 설명은 비즈니스 용어를 사용하고 세분화하여 응용 프로그램 및 응용 프로그램의 서비스에 매핑할 수 있도록 합니다. 은행 예제의 환경에서는 회계 및 권한 부여 서비스가 조직 수준에서 재사용됩니다.
이러한 기능 빌딩 블록이 확인되면 블록 간의 통신을 정의해야 합니다. 즉, 표준화된 데이터 모델을 형성하기 위해 UML 모델로 설명할 수 있습니다. UML 모델은 조직 전체에서 공유되는 데이터의 XML 표현을 제공합니다.
은행을 예로 들자면, 계좌가 LC 블록에 사용되든 대출 블록에 사용되든 간에 고객은 동일합니다. 계좌와 고객은 조직 간 * * * 공유 비즈니스 모델에 정의된 엔티티입니다. 이러한 엔티티는 두 개의 표준 모델로 표시됩니다. 하나는 계정 데이터용이고 다른 하나는 고객 데이터용입니다. 이러한 모델은 전체 조직 또는 조직 구성 요소의 일부로 대중이 공유할 수 있습니다. 이러한 서비스에 액세스하는 서비스는 CRUD (검색 업데이트 삭제 생성) 일 수 있습니다. 서비스는 조합 서비스가 될 수도 있습니다. 표준 모형을 정의하는 가장 좋은 방법은 산업 표준 은행 시스템을 참조하고 SWIFT 표준을 사용하는 것입니다. SWIFT 표준 설명서에 정의된 MT 메시지는 비즈니스 사용 사례 수준에서 은행 업무를 정의합니다. 이러한 메시지는 조직 전체에서 사용할 수 있는 XML 메시지에 쉽게 매핑할 수 있습니다. 단일 조직에서 사용되는 업무 운영을 여러 조직 간의 B2B 운영으로 확장하는 것이 유용합니다.
Quinton Wall 의 "SOA 의 서비스 수명 주기 설계 이해" 및 "SOA 의 서비스 수명 주기 런타임 이해" 에는 서비스 설계 모델링 및 런타임 관심사에 대한 자세한 정보가 있습니다.
기능 블록과 블록에 사용되는 데이터 모델을 정의한 후 이러한 자산은 엔터프라이즈 저장소의 다양한 업무 라인에서 재사용해야 하며 bea aqualogic enterprise repository 는 * * * 에서 엔터프라이즈 정보 자산을 즐기는 데 사용할 수 있습니다.
응용 프로그램 및 구현 계획 앞서 언급했듯이 기능 빌딩 블록은 SOA 빌딩 블록에 이상적입니다. 하향식 접근 방식을 사용하여 서비스를 결정하면 비즈니스 요구 사항과 IT 간의 일치도가 향상됩니다.
애플리케이션 계획의 서비스 구현은 서비스 유형 및 서비스와 다양한 SOA 계층 간의 관계 (표현 및 조합 계층, 비즈니스 서비스 계층 및 데이터 액세스 계층 또는 접속 계층 포함) 에 따라 달라집니다.
이러한 모듈을 구현할 적절한 제품을 선택할 때 특히 조심해야 하며, 기존 어플리케이션 및 기술 제한과 같은 조직 환경을 고려해야 합니다. 구현을 선택할 때 어플리케이션 계획과 기술 계획은 불가분의 관계입니다. 이상적인 BEA WebLogic Integration 은 시스템 간 프로세스에 적합합니다. BEA AquaL 은 비즈니스 프로세스 계획의 설계 및 프로세스 재설계에 사용됩니다. Ogic BPM 은 수동 구동 프로세스에 적합합니다. BEA WebLogic Portal 은 조직 전체의 WSRP 개발 및 * * * 작업에 적합합니다. 프레젠테이션 계층을 즐기고 프레젠테이션 계층 및 포털 컨소시엄의 재사용을 촉진합니다. AquaLogic Data Services 는 데이터 액세스 계층에 이상적인 도구이며 AquaLogic Service Bus 는 어플리케이션 간 통신에 적합합니다. 실제 환경에서 이러한 선택은 조직의 기존 자산과 요구 사항에 따라 다르며 조직 환경에서 참조 아키텍처를 고려해야 합니다.
조직의 참조 아키텍처는 각 빌딩 블록이 속한 계층 및 서비스를 기반으로 각 빌딩 블록을 구현하는 방법에 대한 모범 사례와 청사진을 제공합니다. 참조 아키텍처에서는 서비스 간의 통신 다이어그램도 정의하고 표시합니다. 조직에 대해 정의된 참조 아키텍처의 예가 제공됩니다. 이 다이어그램은 또한 적절한 제품을 통해 조직의 기능과 블록 서비스를 구축하는 데 필요한 SOA 계층 참조 아키텍처의 정의를 보여 줍니다. 이 모델은 적절한 비즈니스 및 IT 계층과 관련된 프로세스를 통해 조직 환경의 각 SOA 계층을 구축하는 데 사용할 수 있습니다.
그림 구성의 참조 구조
참조 아키텍처는 관리 팀이 정의한 모범 사례 지침 및 설계 원칙을 촉진하는 데 도움이 되어야 합니다. 이 아키텍처는 기능 계획에 정의된 표준화된 모델과 분류를 사용해야 합니다. 나중에 관리팀의 관련 내용에 대해 설명하겠습니다.
엔터프라이즈 아키텍처의 목표는 조직의 비즈니스 요구 사항에서 글로벌 접근 방식을 채택하는 것입니다. 엔터프라이즈 아키텍처의 주요 목표는 다음과 같이 공통 언어를 사용하여 재사용 분위기를 조성하는 것입니다. 이 목표는 과감한 변혁이 아니라 점진적으로 달성해야 한다. 서로 다른 범주, 글로벌 비즈니스 및 전략 범주를 관리하는 관리 팀을 구축해야 하며, 정보 시스템 범주 및 프로젝트 범주는 적절한 도구를 통해 조직 전체에서 재사용을 촉진해야 합니다.
엔터프라이즈 아키텍처의 목표를 설명합니다
관리 팀은 현재 상태에 대한 글로벌 설명이 포함된 기존 기능 모듈과 같이 조직의 현재 상태를 반영하는 자산을 만들고 유지 관리해야 합니다. 이를 통해 현재 정보 시스템의 사일로를 식별하는 데 도움이 되며 목표 상태를 정의할 때 로드맵도 고려해야 합니다.
로드맵을 목표 관리 팀에 적용하기 위해서는 프로젝트 초기에 개입하여 조직 전체에 지침, 시행 규정 및 모범 사례를 제공해야 합니다.
관리 팀이 정의하고 유지 관리해야 하는 지침, 정책 분류, 엔터프라이즈 사양, 데이터 모델, 데이터 저장소, 모범 사례, 재사용 가능한 자산 및 기타 지침에는 모든 업무 라인과 IT 가 포함됩니다.
글로벌 비즈니스 및 전략 범위 엔터프라이즈 아키텍처는 IT 와 조직의 전략을 조율할 수 있어야 하며, 비즈니스 변화에 쉽게 적응할 수 있어야 합니다. 이를 위해서는 비즈니스 아키텍처와 지침이 결국 비즈니스 흐름을 결합하고 분해하는 데 필요한 기능 구성 요소를 형성해야 합니다.
정보 시스템 클래스 엔터프라이즈 아키텍처 팀은 기존 기능 블록을 참조하고 업무 처리에 필요한 새로운 기능 블록을 정의할 수 있습니다. 비즈니스 프로세스 계획의 글로벌 비즈니스 범주에 정의된 대로 정보 시스템 범주는 기능 계획과 관련이 있으며 비즈니스 및 IT 가 이해할 수 있는 언어를 통해 올바른 추상화 수준을 제공할 수 있어야 합니다.
정보 시스템 자산은 기능 수준 애플리케이션 간의 통신, 표준화된 엔터프라이즈 데이터 모델, 공용 언어 분류 및 데이터 저장소를 포함한 기능 계획에서 정의됩니다. 이러한 자산에 대한 액세스를 정의하고 제어해야 합니다.
기능 계획의 작업은 응용 프로그램 계획의 응용 프로그램에 상응해야 하며, 다양한 표준 및 제품 지원은 각 응용 프로그램에서 다루는 측면과 함께 결정해야 합니다.
운영 수준에서 프로젝트의 대부분의 조치는 "지침 원칙 및 규칙" 이 성공적으로 적용되도록 프로젝트 형식으로 구현되어야 합니다. 관리팀의 설계자는 상세한 기술 요구 사항 및 프로젝트 아키텍처가 기업의 지침, 정책 및 공통 언어와 일치하는지 확인해야 합니다. 아키텍처의 청사진이 투자의 초기 단계에서 제공 가능한 프로젝트에 적용될 수 있다면, 수요를 충족시키고 적시에 예산, 고품질로 납품할 가능성이 크게 높아질 것이다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언) 그래야만 프로젝트가 조직 전체에서 재사용할 수 있는 새로운 SOA 빌딩 블록을 제공할 수 있습니다.
글로벌 추진 전략을 새 프로젝트에 적용하는 것은 목표를 달성하는 진화 방안이며, 과정은 폭발성이 아니라 원활하다.
엔터프라이즈 스키마 저장소 관리는 엔터프라이즈 공통 모델 정의에 대한 액세스를 전 세계적으로 사용할 수 있어야 공통 엔터프라이즈 언어를 개발할 수 있습니다. 공통 언어가 없으면 재사용 가능한 정보 시스템 자산을 효과적으로 관리할 수 없습니다. 이 라이브러리는 조직 전체에서 액세스할 수 있어야 하며 관리팀이 관리해야 합니다. 자산과 메타데이터의 확장된 보기를 제공해야 합니다. Bea aqualogic enterprise repository 는 엔터프라이즈 아키텍처를 지원하는 훌륭한 도구입니다.
방법론 개요 엔터프라이즈 아키텍처 설계를 위한 가장 좋은 방법은 그림과 같이 이러한 각 계획의 현재 상태를 설명하는 것입니다. 이를 통해 비즈니스와 IT 간의 격차를 평가하고 짧은 보드를 파악한 다음 목표 달성을 위한 로드맵을 정의할 수 있습니다. 방법론은 실제로 이 문서의 시작 부분에 설명된 여러 계획을 분석하여 현재 상태를 평가하고 목표 상태를 정의하는 것입니다.
차트 방법 개요
현재 상태 (기존) 현재 상태의 평가는 각 계획에서 수행할 수 있는 하향식, 상향식 또는 두 가지 방법의 혼합을 통해 수행할 수 있습니다.
업무 프로세스부터 업무 프로세스의 현재 상태를 정의하기 위해 업무 라인과 IT*** 가 공동 작업을 수행해야 합니다. Aqualogic BPM 디자이너를 사용하여 이러한 프로세스를 모델링하면 설계자와 영업 담당자에게 * * * 공통 기반을 제공할 수 있습니다. AquaLogic BPM bit 비즈니스 프로세스 및 시뮬레이션 가능성을 사용하여 향상된 그래픽을 그릴 수 있습니다.
기존 응용 프로그램부터 중복 기능이 사일로에 나타나고 인식될 수 있도록 기존 기능 블록을 식별합니다.
샤프트 응용 프로그램이 확인되면 대상 상태에서 서비스를 통해 샤프트를 공개적으로 제거하는 방법을 정의해야 합니다.
목표 상태는 비즈니스 요구 사항을 기반으로 하고 재사용 가능한 비즈니스 빌딩 블록을 제공할 수 있으므로 위에서 아래로 정의해야 합니다.
비즈니스 프로세스부터 AQualogic BMP 디자이너를 사용하여 최적화된 향후 상태 프로세스를 모델링하여 기능 블록을 식별하고 비즈니스 프로세스의 조합 및 분할에 필요한 서비스를 제공합니다. 기능 계획에서는 비즈니스와 IT 만 동일한 작업을 함께 수행할 수 있다는 점을 기억하십시오.
로드맵 다음에 로드맵을 정의하여 중간 승인 상태의 목표를 달성합니다. 공용 언어 사양 모델 데이터 저장소를 정의할 때 이 로드맵을 고려해야 합니다. 중간 검증 단계에는 비즈니스 및 IT 가 포함되어야 합니다.
참조 아키텍처는 로드맵의 일부 단계에서 계획됩니다. 물론 참조 아키텍처 계획은 언제든지 수행할 수 있지만 모든 엔터프라이즈 자산이 정의될 때까지 참조 프레임워크를 준비하지 말아야 합니다. 효과적인 자산은 새로운 비즈니스 요구 사항에 따라 지속적으로 조정되어야 합니다 (새로운 기능 블록에는 새로운 구현 방법이 포함됩니다). 앞서 언급했듯이 목표는 기존 기업의 재사용 가능한 자산과 채택해야 할 기술에 따라 어떻게 해야 하는지에 대한 지침을 제공하는 것입니다. 지속적으로 발전함에 따라 시험 아키텍처 사무실은 조직 환경에서 새로운 프로젝트를 달성하는 가장 좋은 방법을 제공하며, 목표는 언제든지 재사용 가능성을 높이는 것입니다.
관리팀은 생성된 자산을 활용하여 전체 신규 프로젝트 프로세스에 참여하고 비즈니스에 필요한 민첩성을 제공하는 데 집중할 수 있기 때문에 로드맵과 관련된 가장 중요한 팀입니다. 관리 팀에는 다양한 전문 배경을 가진 엔터프라이즈 건축가들이 포함되어 있어야 합니다. 관리팀은 기술과 업무에 모두 집중해야 한다. 관리 팀은 서로 다른 업무 라인의 수석 설계자와 IT 의 수석 설계자로 구성될 수 있어 글로벌 리더십에 필요한 자격을 갖추게 됩니다.
관리팀의 임무는 일부 환경에서 달성하기 어렵기 때문에 강력한 협조를 제공해야 한다. 관리팀의 역할은 연금술사와 비슷하다. 그는 적절한 변화를 촉진하기 위해 올바른 공식을 찾기 위해 노력한다. 데이비드 그로브스와 스티브 베넷의' SOA 성공 계획',' SOA 성공 계획',' SOA 로드맵 구축',' 장기 SOA 계획의 성공 계획 SOA' 와 같은 문장 분야가 많다. 로드맵을 적용하기 전에 변경 관리에 유의하십시오.
BEA SOA 도메인 모델과의 관계 여기에 설명된 방식은 비즈니스 정책 및 프로세스로 시작되며, 새로운 프로젝트 및 애플리케이션에 대한 청사진을 제공하는 공통 엔터프라이즈 언어 및 참조 아키텍처를 통해 애플리케이션을 형성하는 기능 빌딩 블록을 통해 시작됩니다. 기능 계획에서는 조직이 구조화된 뷰를 유지하고 기업 전체에서 사용할 수 있는 자산을 성공적으로 공개하기 위해 처리해야 하는 모든 측면을 설명했습니다.
SOA 를 엔터프라이즈 아키텍처로 사용하는 환경에서 선임 SOA 설계자는 비용이 많이 드는 통병을 피해야 합니다. 이들 설계자는 조직의 관리 팀과 협력하여 필요한 기술을 제공하고 관리 팀이 성공적인 SOA 를 구축하는 데 도움을 주어야 합니다. SOA 는 기업 방식으로 전 세계적으로 또는 프로젝트 내에서 로컬로 구동될 수 있으며, 이를 통해 프로젝트에 대한 관리 및 지침을 제공하여 SOA 에 더 높은 일관성과 투자 수익을 제공할 수 있습니다. 이를 통해 운영 환경에서 애플리케이션의 유지 보수 비용을 절감하고 재사용 가능성을 높일 수 있습니다.
BEA 는 엔터프라이즈 아키텍처 처리에 사용할 수 있는 도메인 모델을 제공합니다. 이 모델은 6 가지 측면을 통해 앞서 설명한 계획을 다루고 그림과 같이 SOA 를 성공적으로 구현할 수 있는 방법을 제공합니다.
그래프의 BEA 도메인 모델
BEA SOA 는 정보 기술의 모든 측면을 포함하는 실용적인 엔터프라이즈 아키텍처입니다. BEA 는 6 가지 영역 모두에 대한 서비스 및 교육을 제공하고 조직의 요구에 맞게 SOA 를 구현할 수 있도록 효과적인 조직을 제공합니다.
처음에는 BEA SOA 준비 자산 * * * ENT 보고서를 참조하여 현재 상태를 정의하고 SOA 를 조직에 도입하기에 좋은 출발점이 될 수 있습니다. SOA 리소스 센터 설문 조사에 참여하여 SOA 평가 보고서를 얻을 수 있습니다.
결론적으로 이 문서에서는 하향식 엔터프라이즈 아키텍처, 조직 간 글로벌 재사용 가능성을 달성하는 데 필요한 관리 관심 사항, 조직의 참조 아키텍처의 필요성 강조, 이러한 글로벌 접근 방식을 촉진하기 위한 엔터프라이즈 저장소를 정의합니다.
원본 소스 l
-응? 저자 소개 Gabriel Bechara Gabriel Bechara 는 BEA 컨설팅 서비스에서 2 년 넘게 근무했습니다. 가브리엘은 고객이 WebLogic Server Portal 및 Integration 과 같은 BEA 제품을 사용할 수 있도록 지원합니다. Gabriel 의 관심사는 소프트웨어 아키텍처 방법 정의, 개발 팀에서 제품 사용, 응답할 서비스 제공 등입니다. 프로그램을 생산으로 푸시하는 가장 쉬운 방법은 주로 WebLogic 통합과 SOA 관련 방법에 초점을 맞추고 있습니다. 가브리엘은 이미 소프트웨어 업계에서 1 년 넘게 일했다. 가브리엘은 파리 차이나타운에 사는 리시신/Article/Program/Java/ky/201311/20