엔터프라이즈 아키텍처는 비즈니스 최적화와 관련이 있으며, 후자는 엔터프라이즈 아키텍처, 성과 관리, 조직 구조 및 프로세스 아키텍처와 같은 문제를 해결하는 데 사용됩니다. 여기에는 조직 프로세스의 현재 및 미래 구조와 동작이 포함됩니다. 정보 시스템, 인력 및 사업 단위 위의 단위가 조직의 전략적 개발 방향을 충족할 수 있도록 설명합니다. 엔터프라이즈 아키텍처의 개념은 정보 기술의 범위를 넘어서는 것을 볼 수 있습니다.
아키텍처와 정보 기술은 밀접하게 관련되어 있습니다. 이 기사에서는 비즈니스와 IT 간의 최적의 조정을 목표로 정보 기술에 초점을 맞춘 단순화된 하향식 엔터프라이즈 아키텍처인 SOA(서비스 지향 아키텍처) 환경에 대해 설명합니다.
하향식 엔터프라이즈 아키텍처 접근 방식의 차이점을 소개하겠습니다. 초점: 엔터프라이즈 아키텍처의 대상 방법론 개요 및 BEA SOA 도메인 모델과의 관계
이 기사를 통해 다음을 수행할 수 있습니다. 비즈니스 전략에 따른 하향식 엔터프라이즈 아키텍처 접근 방식의 장점과 관련 측면을 더 잘 이해합니다. 조직적 고려 사항 하향식 엔터프라이즈 아키텍처 접근 방식의 다양한 관심사
비즈니스에서 IT까지의 하향식 접근 방식에서는 비즈니스와 IT의 서로 다른 관심사를 서로 다른 계획으로 분리하는 것이 필요합니다. 그런 다음 둘 사이에 명확한 기반을 마련해야 합니다. 비즈니스 관련 계획을 비즈니스 프로세스 계획이라고 하고, IT 관련 계획을 둘 사이의 계획이라고도 합니다. 이 접근 방식 중 가장 효과적인 것은 이 접근 방식이 비즈니스와 IT 간의 최상의 조정을 목표로 한다는 점입니다. 이를 기능 계획이라고 합니다. 기술 계획에 대해 자세히 설명할 생각은 없습니다. 왜냐하면 제 주요 목적은 공개적으로 IT와 비즈니스 간의 최적의 조정을 달성하는 방법을 추천하는 것이기 때문입니다.
다이어그램은 이러한 계획과 그 관계를 묘사합니다. 상호 관계를 자세히 소개하겠습니다.
다양한 솔루션에 대한 하향식 엔터프라이즈 아키텍처 접근 방식의 다이어그램 비즈니스 프로세스 계획에 중점을 둡니다.
이 계획은 비즈니스 전략의 맥락에서 비즈니스 프로세스에 중점을 둡니다. 엔터프라이즈 아키텍처는 조직의 다양한 비즈니스 라인과 긴밀하게 협력할 수 있습니다. 이는 비즈니스 전략에 의해 정의된 비즈니스 요구 사항에서 시작됩니다. 엔터프라이즈와 같은 주요 기업 비즈니스 프로세스를 모델링할 수 있습니다. 설계자는 AquaLogic BPM Designer를 사용하여 설계 수준에서 이를 달성할 수 있습니다. 이는 설계자가 기업 전체의 주요 프로세스를 이해하는 데 도움이 되며 AquaLogic BPM Designer를 사용하여 더 많은 영업 담당자를 참여시킴으로써 이 접근 방식을 더욱 발전시킬 수 있습니다. 비즈니스 분석가 프로세스를 리버스 엔지니어링할 때 발생하는 최적화 측정값을 제공하기 위해 비즈니스 프로세스를 시뮬레이션할 수 있습니다. 비즈니스 프로세스 계획은 비즈니스 자체에서 담당합니다. 동일한 비즈니스 서비스
은행 비즈니스 환경을 예로 들면, 먼저 각 은행 비즈니스의 프로세스(예: 대출 수입/수출 운영)를 설계해야 합니다. 이 두 은행 업무는 완전히 다른 프로세스를 가지고 있지만 *** *다른 서비스***에 대한 확인은 조직 수준에서 프로세스를 설계하여 어느 정도 달성할 수 있어야 합니다. 신용장(LC) 발행 프로세스와 같은 서로 다른 프로세스에서 서로 다른 작업을 수행합니다. 두 프로세스는 동일한 승인 서비스와 동일한 회계 서비스를 사용할 수 있어야 합니다.
조직의 중요한 프로세스를 설계한 후에는 주요 기능 블록을 결정할 수 있습니다. 기능 블록은 다양한 비즈니스 프로세스에서 재사용할 수 있는 비즈니스 서비스도 SOA의 이상적인 구성 요소입니다. 비즈니스에 필요한 민첩성을 제공하기 위해 재사용 및 재결합이 가능해야 합니다. 표준화된 데이터 모델을 이해합니다.
그런 다음 도메인 UML 모델 및 데이터 저장소를 비즈니스 계획에 추가해야 합니다. 이러한 공통 접근 방식은 전체 조직에서 공유할 수 있는 공통 언어 및 공통 분류법을 생성해야 하며, 공통 엔터티 및 공통 도메인 모델의 정의는 해당 의미를 공통화합니다. 계획은 조직 내 다양한 사업 분야와 관련된 지역 및 구역으로 기능적 빌딩 블록을 구성하는 도시 계획과 같습니다.
공통 언어입니다. 기능적 빌딩 블록의 재사용과 이러한 블록 간의 데이터 공유를 크게 촉진할 것입니다. 기업 저장소 내에서 공유 관리를 위해 표준 모델을 고려해야 하며 이러한 모델을 검증하고 수정하는 방법을 정의해야 합니다. 이러한 고려 사항은 이 기사 뒷부분에서 설명합니다.
은행 예로 돌아가서, 이 조직에는 지불, 외화 환전 및 모기지를 처리하는 또 다른 사업 라인, 즉 세 번째 사업 라인이 있어야 합니다. 사업은 신용장(LC), 추심 등 수입/수출 업무를 담당하고, 인가회계 보고, 리스크 관리 등을 담당하는 수평 사업은 도시계획에 비유하면 각각의 사업은 특수한 사업으로 볼 수 있습니다. zone
수입/수출 사업 라인을 더 살펴보면 LC와 결제에 각각 관련된 기능 블록을 찾을 수 있으며, LC를 대표하는 기능 블록도 제공해야 하는 다양한 서비스로 나눌 수 있습니다. 블록은 LC 발행, LC 수정, LC 사용 및 LC 상환과 같은 기능(또는 서비스)을 제공해야 합니다. 이는 LC 블록의 비즈니스 서비스입니다. 이러한 서비스는 승인 블록, 회계 블록 및 지불 블록에서 제공하는 기능에 따라 달라집니다. /p>
승인 블록은 고객의 상태에 따라 신용 한도를 부여합니다. 승인 블록은 위험 관리 블록의 기능에 따라 달라질 수 있습니다. LC 기능은 회계 블록에서 제공하는 서비스도 사용합니다. 결제 블록은 회계 블록 및 승인 블록의 기능을 사용합니다.
기능 계획에 대한 설명은 비즈니스 용어로 분류되어 애플리케이션 내 서비스에 매핑됩니다. 은행 예의 맥락에서 회계 서비스와 권한 부여 서비스는 조직 수준에서 재사용됩니다.
이러한 기능적 구성 요소를 결정한 후에는 이러한 블록 간의 통신도 정의해야 합니다. 이는 표준 데이터를 형성하는 것을 의미합니다. 이 표준 모델은 UML 모델을 사용하여 설명할 수 있습니다. 이는 데이터의 XML 표현과 함께 제공되는 이 공통 언어를 전체 조직에서 공유해야 합니다. 은행 예에서는 계정이 LC 블록에서 사용되는지 아니면 대출 블록에서 동일한 고객은 동일한 계정이며 고객은 조직 전체에서 공유되는 비즈니스 모델에 정의된 엔터티입니다. 이러한 엔터티는 계정 데이터용과 고객 데이터용으로 구분됩니다. 전체 조직에서 공유할 수 있으며, 블록 액세스의 일부인 공용 서비스는 CRUD(Create Retrieve Update Delete) 서비스 또는 복합 서비스일 수 있습니다. MT 메시지는 SWIFT 표준 매뉴얼에 정의된 SWIFT 표준을 사용하는 산업 표준 뱅킹 시스템을 의미합니다. MT 메시지는 메시지를 사용하여 비즈니스 사용 사례 수준에서 은행 운영을 정의합니다. 표준을 최대한 준수하는 것은 단일 조직 내에서 사용되는 비즈니스 운영을 조직 간의 여러 B B 운영으로 확장하는 데 매우 유용합니다.
서비스 수명 주기 이해에서 서비스 디자인 모델링 및 런타임 문제에 대한 자세한 내용을 확인할 수 있습니다. SOA의 설계 시간 및 Quinton Wall이 작성한 SOA의 서비스 라이프사이클 런타임 이해 추가 정보
블록에 사용되는 기능 블록 및 데이터 모델을 정의한 후에는 이러한 자산을 기업의 다양한 사업 부문에서 재사용할 수 있어야 합니다. BEA AquaLogic Enterprise Repository는 기업 정보 자산을 애플리케이션 및 구현 계획과 공유하는 데 사용할 수 있습니다.
앞서 언급한 바와 같습니다.
기능적 빌딩 블록은 SOA 빌딩 블록에 이상적입니다. 식별된 서비스에 대한 하향식 접근 방식을 사용하면 비즈니스 요구 사항과 IT 간의 더 나은 일치로 이어질 것입니다.
애플리케이션 계획의 서비스 구현은 서비스에 따라 달라집니다. 다양한 SOA 계층에 대한 서비스 유형 및 관계 이러한 계층에는 프레젠테이션 및 복합 계층, 오케스트레이션 계층, 비즈니스 서비스 계층, 데이터 액세스 계층 또는 연결 계층이 포함됩니다. 구현을 선택할 때 기존 애플리케이션 및 기술 제약과 같은 조직 환경을 고려해야 합니다. 이상적으로 BEA WebLogic 통합은 시스템 간 프로세스에 적합합니다. 비즈니스 프로세스 계획의 설계 및 프로세스 재설계에서 인간 중심 프로세스를 위한 BEA WebLogic Portal은 프레젠테이션 레이어와 포털 페더레이션의 재사용을 촉진하기 위해 WSRP를 통해 조직 전체에서 프레젠테이션 레이어를 개발하고 공유하는 데 이상적입니다. AquaLogic Service Bus는 애플리케이션 간 통신에 이상적인 반면, 이러한 선택은 조직 내의 기존 자산과 요구 사항에 따라 달라집니다. 또한 조직 환경 내에서 사용하는 것이 좋습니다. 참조 아키텍처
조직의 참조 아키텍처는 해당 구성 요소가 속한 계층 및 서비스에 따라 각 빌딩 블록을 구현하는 방법에 대한 모범 사례와 청사진을 제공하는 아키텍처입니다. 참조 아키텍처는 조직에 대해 정의된 참조 아키텍처의 예를 제공합니다. 또한 이 다이어그램은 적절한 제품을 통해 조직의 기능적 빌딩 블록 서비스를 구현하는 데 필요한 SOA 계층을 설명합니다. 적절한 비즈니스 및 IT 계층을 사용하여 조직 환경 내의 각 SOA 계층에 대한 빌딩 블록을 구현할 수 있습니다.
그래프 조직을 위한 참조 아키텍처
참조 아키텍처 이 아키텍처는 관리 팀이 정의한 모범 사례 지침과 설계 원칙을 홍보하는 데 도움이 되어야 합니다. 이 아키텍처는 기능 계획에 정의된 표준 모델과 분류를 사용해야 합니다.
그림에서 볼 수 있듯이 엔터프라이즈 아키텍처의 주요 목표는 조직의 비즈니스 요구에서 시작하는 글로벌 접근 방식을 채택하는 것입니다. , 이 목표는 급격한 변화에 의존하기보다는 점진적으로 달성되어야 합니다. 다양한 영역을 관리하는 관리 팀이 있어야 합니다. 글로벌 비즈니스 및 전략 영역 정보 시스템 영역과 프로젝트 영역은 조직 전체에서 재사용을 촉진하기 위한 적절한 도구를 지원해야 합니다.
Figure 엔터프라이즈 아키텍처 목표 관리팀
관리팀은 기존 기능과 같은 조직의 현재 상태를 반영하는 자산을 생성하고 유지해야 합니다. 모듈의 현재 상태에 대한 전반적인 설명이 있으면 현재 정보 시스템의 사일로를 결정하는 데 도움이 됩니다.
로드맵을 적용하려면 목표를 달성하려면 관리팀이 프로젝트 초기에 참여하여 조직 전체가 구현할 지침과 모범 사례를 제공해야 합니다.
지침 원칙, 정책 분류, 기업 사양, 데이터 모델, 데이터 모든 비즈니스 라인과 IT 환경에 영향을 미치며 관리 팀이 정의하고 유지 관리해야 하는 저장소, 모범 사례, 재사용 가능한 자산 및 기타 지침
엔터프라이즈 아키텍처는 다음을 수행할 수 있어야 합니다. IT 및 조직 전략을 조정하려면 비즈니스의 지속적인 변화에 쉽게 적응할 수 있어야 합니다. 이를 위해서는 비즈니스 아키텍처와 지침 원칙이 궁극적으로 비즈니스 흐름을 결합하고 분해하는 데 필요한 것을 형성할 수 있어야 합니다.
엔터프라이즈 아키텍처 팀은 비즈니스 프로세스 계획의 글로벌 비즈니스 범위에서 정의된 대로 비즈니스 처리에 필요한 새로운 기능 빌딩 블록을 정의할 수도 있습니다.
정보 시스템 범주는 기능 계획과 관련된 것으로 정의되며 비즈니스 및 IT가 이해할 수 있는 언어로 올바른 수준의 추상화를 제공할 수 있어야 합니다. 이 정의에는 기능 계획에 대한 적용이 포함됩니다. 프로그램 간 통신과 표준화된 기업 데이터 모델, 공용 언어 분류 및 데이터 저장소는 이러한 자산에 대한 액세스를 정의하고 제어해야 합니다.
기능 계획 작업은 응용 프로그램 계획 표준 및 응용 프로그램과 일치해야 합니다. 제품 지원은 각 애플리케이션에서 다루는 측면과 연계하여 범위를 정해야 합니다.
운영 수준에서 대부분의 이니셔티브는 관리 팀의 설계자가 지침과 규칙을 성공적으로 적용할 수 있도록 프로젝트로 구현되어야 합니다. 세부적인 기술 요구 사항 및 프로젝트 아키텍처는 기업의 지침 원칙, 전략 및 기업의 공통 언어 사용과 일치합니다. 투자 초기에 제공 가능한 프로젝트에 아키텍처 청사진을 적용하면 규정 준수가 크게 향상되고 프로젝트 공통 사항을 더 잘 이해할 수 있습니다. 우수한 재사용 가능성과 적시 및 예산 품질 제공이 가능해야 프로젝트가 조직 전체에서 재사용할 수 있는 새로운 SOA 빌딩 블록을 제공할 수 있습니다.
새 프로젝트에 글로벌 중심 전략 적용 목표는 폭발적이지 않고 원활하게 진행되는 혁신적인 솔루션 프로세스입니다. 엔터프라이즈 아키텍처 저장소 관리
공통 언어를 사용하여 공통 기업 언어를 개발하려면 기업의 공통 모델 정의에 대한 액세스가 전 세계적으로 가능해야 합니다. 분류 재사용된 정보 시스템 자산의 효과적인 관리는 공통 언어 없이는 달성할 수 없습니다. 이는 기업 저장소를 사용하여 달성할 수 있습니다. 이 저장소는 전체 조직이 액세스할 수 있어야 하며 관리 팀에서 관리해야 합니다. BEA AquaLogic Enterprise Repository는 엔터프라이즈 아키텍처를 지원하는 데 사용할 수 있는 훌륭한 도구입니다. 방법론 개요
엔터프라이즈 아키텍처를 설계하는 가장 좋은 방법은 위의 각 계획의 현재 상태를 설명하는 것입니다. 이는 그림에 표시된 대로 비즈니스를 평가하는 데 도움이 됩니다. IT와 IT 간의 격차가 결정되고 목표 달성을 위한 로드맵이 정의될 수 있습니다. 방법론은 실제로 이 문서의 시작 부분에 설명된 다양한 계획을 분석하여 평가하는 것입니다. 현재 상태 및 목표 상태 정의
현재 상태에 대한 그래프 방법론 개요(기존)
현재 상태에 대한 평가는 상단에서 달성할 수 있습니다. 하향식 접근 방식, 상향식 접근 방식 또는 두 접근 방식의 혼합은 계획별로 정의할 수 있습니다.
비즈니스 프로세스부터 시작하여 공통 작업은 사업 부문별로 공동으로 수행해야 합니다. AquaLogic BPM Designer를 사용하면 이러한 프로세스를 모델링하여 AquaLogic BPM을 사용하여 비즈니스 프로세스 및 시뮬레이션 가능성에 대한 향상된 다이어그램을 그릴 수 있는 동일한 기반을 제공할 수 있습니다.
기존 애플리케이션으로 시작하고 IT를 조정하여 이와 같은 기존 기능 블록을 식별합니다. 중복된 기능이 발생할 가능성이 높으며 사일로가 식별됩니다.
사일로가 식별되면 애플리케이션은 사일로를 제거하는 방법을 정의해야 합니다. (되어야 하는 대로) 대상 상태에서 서비스를 통해
대상 상태를 정의하려면 하향식 접근 방식을 취해야 합니다. 이는 비즈니스 요구 사항을 기반으로 하고 재사용 가능한 비즈니스 빌딩 블록을 제공하므로 권장되는 접근 방식입니다. /p>
비즈니스 프로세스에서 AquaLogic BMP Designer를 사용하여 최적화된 미래 상태 프로세스를 모델링하여 LOB(Line of Business) 작업을 시작하십시오. 다음으로 비즈니스 프로세스의 구성 및 분해에 필요한 서비스를 제공하는 기능 블록을 식별하십시오. 기능 계획은 비즈니스와 IT가 협력해야만 달성할 수 있습니다. *** 다양한 작업 로드맵
그런 다음 중간 승인 상태의 목표를 달성하기 위한 로드맵을 정의할 때 이 로드맵을 고려해야 합니다. 공통 언어 사양 모델 데이터 저장소는 비즈니스 및 IT 참조를 포함해야 합니다.
아키텍처는 로드맵의 특정 단계에서 계획됩니다. 물론 참조 아키텍처 계획은 언제든지 발생할 수 있지만 참조 아키텍처 준비를 시작하기 위해 모든 기업 자산이 정의될 때까지 기다려서는 안 됩니다. 비즈니스 요구 사항(새로운 기능 블록에는 새로운 구현 방법이 포함됩니다.) 그 목표는 현재 기존 기업의 재사용 가능한 자산과 채택해야 하는 기술을 기반으로 수행할 작업에 대한 지침을 제공하는 것입니다. 위에서 언급한 참조 아키텍처는 지속적으로 개발되고 있습니다. 향상된 재사용성을 목표로 특정 시점에 조직의 환경에서 새로운 프로젝트를 구현하는 것
관리팀이 로드맵에 참여하는 가장 중요한 팀인 이유는 팀이 전체에서 생성된 자산을 활용할 수 있기 때문입니다. 새로운 프로젝트는 전 세계적으로 참여하고 비즈니스에 필요한 민첩성을 제공하는 데 중점을 두어야 합니다. 관리 팀에는 다양한 전문적 배경을 가진 엔터프라이즈 설계자 그룹이 포함되어 특정 계획에 대해 다양한 수준으로 집중할 수 있어야 합니다. 기술 중심의 아키텍트와 비즈니스 중심의 아키텍트를 모두 포함합니다. 관리팀은 다양한 비즈니스 라인의 수석 아키텍트와 IT의 수석 아키텍트로 구성될 수 있습니다. 따라서 팀은 전반적인 상황을 주도하는 데 필요한 자격을 갖추고 있습니다. >
팀을 관리하는 작업은 일부 환경에서 달성하기 어렵기 때문에 올바른 변화를 촉진하기 위해 팀을 관리하는 역할은 다소 연금술사와 같습니다. 성공적인 SOA를 위한 계획(David Groves 및 Steve Bennett) 등 참조할 수 있는 많은 기사가 있습니다. 성공적인 SOA를 위한 계획 수립 및 성공적인 SOA 계획에 대해서는 다음을 참조하십시오. 로드맵을 적용하기 전에 변경 관리와 BEA SOA 도메인 모델 간의 관계를 고려하십시오.
여기에 설명된 접근 방식은 비즈니스 정책 및 프로세스에서 시작하여 기능적 빌딩 블록을 통해 애플리케이션을 구성합니다. 이 모든 것은 기능 계획에서는 구조화된 보기를 유지하고 성공적으로 노출하기 위해 조직에서 해결해야 하는 다양한 측면을 다룹니다. 기업 전체에서 공유할 수 있는 자산입니다.
사용 중 엔터프라이즈 아키텍처인 SOA의 맥락에서 숙련된 SOA 설계자는 일반적이고 비용이 많이 드는 함정을 피해야 합니다. 이러한 설계자는 조직의 관리 팀과 협력하여 다음을 제공해야 합니다. 필요한 기술과 관리 팀이 성공적인 SOA를 구축하도록 지원하는 것은 전사적인 방식으로 전체적으로 추진될 수도 있고 프로젝트에 대한 관리 및 지침을 제공하기 위한 글로벌 접근 방식을 채택할 수도 있습니다. SOA에 대한 일관성과 더 나은 투자 수익을 제공합니다.
BEA는 이전에 설명한 계획을 다루는 도메인 모델을 제공합니다. more) 6가지 측면을 통해 그림과 같이 SOA를 성공적으로 구현하기 위한 경로를 제공합니다.
그림 BEA 도메인 모델
BEA SOA 접근 방식은 다음과 같습니다. BEA는 정보 기술의 모든 측면을 다루는 실용적인 엔터프라이즈 아키텍처 접근 방식을 제공합니다. 6개 영역 모두에서 서비스와 교육이 효과적으로 구성되어 조직의 요구 사항을 충족하는 SOA를 구현할 수 있습니다.
시작하려면 BEA를 고려하세요. SOA 준비 상태 평가 *** 현재 상태를 정의하는 데 도움이 되는 보고서는 SOA 리소스 센터에서 설문조사에 참여하여 SOA 평가 보고서를 받아볼 수 있습니다.
이 문서에서는 엔터프라이즈 아키텍처는 조직 전체에서 글로벌 재사용성을 달성하는 데 필요한 관리 초점을 소개하고 조직의 참조 아키텍처의 필요성을 강조하며 이러한 글로벌 접근 방식을 촉진하기 위한 엔터프라이즈 저장소를 정의합니다. p>원본 출처 l 저자 소개G ?
abriel Bechara Gabriel Bechara는 BEA Consulting Services에서 2년 이상 근무했으며, Gabriel은 소프트웨어 아키텍처 정의, 개발 팀 내 제품 사용 방법, 애플리케이션 가져오기 솔루션 제공 등의 BEA 제품을 지원하고 있습니다. 가장 쉬운 생산 방법은 WebLogic 통합 및 SOA 관련 방법에 중점을 두고 있습니다. Gabriel은 아내와 두 자녀와 함께 파리 차이나타운에 거주하고 있습니다. 자바/ky/201311/28398