엔터프라이즈 아키텍처 도구 선택 가이드
엔터프라이즈 아키텍처 도구를 용도별로 비교하고, 프로세스 데이터가 아키텍처의 정확성을 어떻게 확인하는지 살펴보세요.
엔터프라이즈 아키텍처 도구를 사용하면 역량, 애플리케이션, 데이터와 프로세스를 매핑하고 이들 간의 관계를 파악할 수 있습니다. 적합한 도구는 자산 목록과 표준 및 로드맵을 관리하려는지, 실제 업무 실행에 관한 근거를 확인하려는지에 따라 달라집니다.
저장소를 통해 보유 자산과 각 요소의 연계 방식을 확인할 수 있습니다. 하지만 사용자가 시스템과 프로세스를 이용할 때 실제로 어떤 일이 일어나는지까지 보여주지는 않을 수 있습니다.
이러한 차이는 아키텍처를 관리하는 사람의 잘못이 아닙니다. 업무는 계속 바뀌고 문서는 낡습니다. 운영 시스템에는 정적인 모델만으로는 알 수 없는 근거가 쌓입니다.
엔터프라이즈 아키텍처 도구는 어떤 용도로 사용하나요?
엔터프라이즈 아키텍처 도구는 조직과 구성 요소 간의 관계를 설명하는 데 도움이 됩니다. 대부분 다음 세 가지 목적을 지원합니다.
- 자산 목록: 역량, 프로세스, 애플리케이션, 데이터, 담당자와 의존 관계를 기록합니다.
- 표준과 로드맵: TOGAF나 ArchiMate 같은 프레임워크를 적용해 변경안을 평가하고 현재 상태에서 목표 상태로 전환할 계획을 세웁니다.
- 분석: 조직의 운영 방식과 변경이 미칠 수 있는 영향을 파악합니다.
저장소를 활용하면 특정 역량을 지원하는 애플리케이션이나 특정 시스템에 의존하는 프로세스를 확인할 수 있습니다. 또한 팀이 변경 사항을 논의할 때 공통 용어를 사용할 수 있습니다.
하지만 아키텍처 저장소만으로는 실제 업무가 어떻게 진행되는지 알 수 없습니다. 프로세스 이름과 담당자, 설명만으로는 사례가 예외 경로를 얼마나 자주 따르는지, 어디서 대기하는지, 승인 절차를 몇 번 거치는지 알 수 없습니다.
이 차이를 염두에 두고 나머지 도구를 비교해야 합니다. 저장소 도구는 보유 자산과 계획을 설명하고, ProcessMind는 시스템에 기록된 실제 실행을 살펴보도록 지원합니다.
엔터프라이즈 아키텍처 소프트웨어를 비교할 때 무엇을 확인해야 하나요?
공급업체 웹페이지에 나열된 기능만 보지 말고, 필요한 업무를 지원하는지 기준으로 엔터프라이즈 아키텍처 소프트웨어를 비교하세요.
- 저장소와 메타모델: 별도의 우회 방법 없이 역량, 여러 수준의 프로세스, 애플리케이션, 데이터와 관계를 표현할 수 있나요?
- 프레임워크 지원: 제품에서 ArchiMate와 TOGAF를 지원하나요, 아니면 주로 다이어그램 요소만 제공하나요?
- 프로세스 상세 수준: 상위 프로세스에서 하위 프로세스, 활동, 게이트웨이와 변형 흐름까지 살펴볼 수 있나요? 여러 수준으로 표현한 프로세스를 보여 달라고 요청하세요.
- 데이터 연계: 수작업 갱신에만 의존하지 않고 아키텍처의 일부를 운영 데이터로 갱신하거나 검증할 수 있나요?
- 협업과 권한: 팀이 작업에 참여하고 검토할 수 있나요? 편집자 라이선스 없이 저장소를 열람할 수 있나요?
- 호스팅과 데이터 저장 위치: 데이터는 어디에 저장되며 누가 접근할 수 있나요? 요구사항을 충족하나요?
- 상호운용성: 아키텍처를 내보내고 API나 개방형 형식을 사용할 수 있나요? 작업 결과를 다른 곳으로 가져갈 수 있어야 합니다.
- 라이선스: 편집자, 검토자, 읽기 전용 열람자의 라이선스는 어떻게 책정되나요? 핵심 팀뿐 아니라 접근이 필요한 모든 사용자를 고려해 총비용을 비교하세요.
프로세스 상세 수준과 데이터 연계를 특히 살펴보세요. 역량 맵은 계획 수립에 유용하지만, 실제 업무 프로세스와 연결할 수 없다면 실행으로 옮기기 어렵습니다.
공급업체에 모델을 어떻게 관리하는지, 프로세스 계층을 어느 수준까지 살펴볼 수 있는지, 정보를 데이터와 대조할 수 있는지 시연해 달라고 요청하세요. 답변을 보면 도구가 프로세스 계층을 지원하는지, 아니면 단순히 기록만 하는지 알 수 있습니다.
이 기준을 활용하면 엔터프라이즈 아키텍처 저장소가 필요한지, 프로세스 실행 근거를 보여주는 계층이 필요한지, 아니면 둘 다 필요한지 판단할 수 있습니다.
용도에 맞는 엔터프라이즈 아키텍처 도구는 무엇인가요?
엔터프라이즈 아키텍처 도구는 유형마다 지원하는 업무가 다릅니다. 도구를 비교할 때는 기능 수보다 용도부터 살펴보세요. 아래 표는 8가지 기준을 유형별로 비교하며 ProcessMind는 마지막 열에 정리했습니다.
| 기준 | 저장소 중심 EA 제품군 | EA 관리 플랫폼 | 다이어그램 및 ArchiMate 도구 | ITSM 및 플랫폼 모듈 | ProcessMind |
|---|---|---|---|---|---|
| 저장소와 메타모델 | 폭넓은 아키텍처 저장소 | 애플리케이션 및 역량 목록 | 모델과 다이어그램 | 광범위한 플랫폼 내 아키텍처 뷰 | 가치 흐름부터 활동까지 설정 가능한 수준으로 관리하는 프로세스 아키텍처 |
| 프레임워크 지원 | 프레임워크와 거버넌스 관행 | 아키텍처 관리 기능 | 다이어그램 표준에 초점을 두는 경우가 많음 | 플랫폼 모듈에 따라 다름 | 실제 업무 흐름에 맞춰 가치 흐름과 프로세스 수준을 매핑 |
| 프로세스 상세 수준 | 설정에 따라 저장소 기능이 다름 | 애플리케이션과 역량 중심인 경우가 많음 | 다이어그램 수준의 상세 정보 | 모듈에 따라 다름 | 각 수준에서 활동, 게이트웨이와 변형 흐름을 표현하는 BPMN 2.0 모델 |
| 데이터 연계 | 연동과 구현 방식에 따라 다름 | 자산 목록 관리 지원, 데이터 요구사항 확인 필요 | 일반적으로 모델을 직접 갱신해야 함 | 플랫폼과 설정에 따라 다름 | 모델에 이벤트 데이터를 연결해 프로세스 흐름을 검증 |
| 협업과 권한 | 아키텍처 팀과 거버넌스를 위해 설계 | 엔터프라이즈 아키텍처 관리 지원 | 도구와 배포 방식에 따라 다름 | 플랫폼 권한 사용 | RACI 담당자 지정, 거버넌스 워크플로와 열람자 포털 |
| 호스팅과 데이터 저장 위치 | 공급업체와 배포 방식에 따라 다름 | SaaS 방식 | 도구에 따라 다름 | 플랫폼에 따라 다름 | 프랑크푸르트 리전에 호스팅 |
| 상호운용성 | 내보내기와 연동 요구사항 확인 필요 | 내보내기와 연동 요구사항 확인 필요 | 지원 형식 확인 필요 | 플랫폼 연동 옵션 확인 필요 | BPMN 2.0 가져오기 및 내보내기, 모델을 표준 XML 형식으로 이동 가능 |
| 라이선스 | 역할과 접근 요건 비교 | 역할과 접근 요건 비교 | 도구에 따라 다름 | 플랫폼 라이선스에 포함되는 경우가 많음 | 사용자별 요금제 공개, Process Individual 플랜, Architecture 또는 Intelligence 라이선스당 무료 포털 열람자 10명 |
Software AG ARIS, Bizzdesign, MEGA HOPEX, Orbus iServer, Sparx EA와 같은 저장소 중심 EA 제품군은 아키텍처 저장소, 프레임워크, 거버넌스와 포트폴리오 관리를 위해 설계되었습니다. 정식 아키텍처 프로그램을 운영할 권한과 역량을 갖춘 조직에 적합합니다.
SAP LeanIX와 같은 EA 관리 플랫폼은 애플리케이션 및 역량 목록을 SaaS 방식으로 관리합니다. 애플리케이션 환경을 파악하고 체계적으로 엔터프라이즈 아키텍처를 관리하려는 조직에 적합할 수 있습니다.
다이어그램 및 ArchiMate 도구는 주로 모델을 만들고 공유하려는 경우 실용적인 선택입니다. Archi는 무료 오픈소스 ArchiMate 전용 도구입니다. Visio를 활용해 아키텍처를 문서화할 수도 있습니다. 저장소, 협업, 거버넌스 기능이 요구사항에 맞는지 확인하세요.
ITSM 및 플랫폼 모듈은 기존에 사용하는 시스템과 함께 아키텍처 뷰를 관리해야 할 때 적합할 수 있습니다. 모듈의 모델링 수준과 저장소 기능이 아키텍처 업무에 맞는지 확인하세요.
ProcessMind는 다른 질문을 다룹니다. 실제 업무는 어떻게 진행되며 운영 데이터에는 무엇이 나타날까요? 조직의 시스템에 이미 기록된 이벤트 데이터에 가치 흐름과 프로세스 수준을 연결하므로, 아키텍처를 실제 활동 수준까지 살펴보고 실제 실행과 대조할 수 있습니다.
모든 유형에 두루 적합한 단일 도구는 없습니다. 먼저 수행해야 하는 업무에 맞춰 선택하세요. 주된 관심사가 프로세스 실행 방식이라면 프로세스 계층의 근거부터 살펴보고, 아키텍처 프로그램에 필요할 때 저장소를 추가하면 됩니다.
엔터프라이즈 아키텍처는 왜 현실과 달라지나요?
저장소를 수작업으로 갱신하고 모델이 실제 업무와 동떨어져 있으면 엔터프라이즈 아키텍처가 현실과 달라질 수 있습니다.
다음 세 가지 구조적 요인으로 이런 차이가 생기기 쉽습니다.
- 저장소를 수작업으로 관리합니다. 프로세스, 애플리케이션, 담당자가 바뀌면 내용을 입력하고 검토해야 합니다.
- 효과는 나중에 나타날 수 있습니다. 팀은 향후 감사나 영향 분석을 위해 정확한 목록이 필요할 수 있지만, 갱신 작업은 지금 해야 합니다.
- 모델은 실제 실행이 아니라 의도를 설명합니다. 문서화된 프로세스에는 실제 사례에서 발생하는 재작업, 예외, 인계, 대기 과정이 나타나지 않을 수 있습니다.
역량 맵과 애플리케이션 목록은 조직을 상위 수준에서 파악하는 데 유용합니다. 하지만 모델이 역량이나 애플리케이션 수준에서 멈추면 실제 업무를 담당하는 사람이 자신의 일상적인 프로세스를 알아보기 어려울 수 있습니다.
차이는 프로세스 변형, 인계, 반복 승인, 대기 시간 같은 세부 사항에서 드러나는 경우가 많습니다. 저장소에 의도한 프로세스를 기록할 수는 있지만, 그 설명이 실제 운영 방식과 일치하는지 확인하려면 별도의 근거가 필요합니다.
아무도 실제 업무와 연결하지 못하는 아키텍처는 두 가지 방식으로 실패합니다. 모델에는 승인 단계가 하나라고 되어 있지만 팀은 세 번이라는 사실을 알고 있어 모델을 참고하지 않게 됩니다. 또는 감사 전에 갱신하고 그 사이에는 무시하는 규정 준수 문서로 남습니다. 두 경우 모두 도구의 문제가 아니라 모델과 실제 업무 사이의 간극에서 비롯됩니다.
거버넌스를 개선하면 저장소를 계속 관리하는 데 도움이 될 수 있습니다. 하지만 거버넌스만으로 모델이 실제 상황과 일치한다는 독립적인 근거를 확보할 수는 없습니다. 프로세스 모델을 운영 데이터에 연결하면 해당 계층을 검증할 수 있습니다.
아키텍처를 실제 업무와 어떻게 연결할 수 있나요?
실제 업무에서 얻은 상세 정보는 팀이 아키텍처를 이해하는 데 도움이 되며, 운영 데이터와 대조할 근거도 제공합니다.
역량 맵은 조직이 수행해야 하는 업무를 설명합니다. 프로세스 모델은 업무 수행 방식과 담당자, 하위 프로세스 간의 관계를 보여줄 수 있습니다. 각 수준을 명확하게 연결할수록 아키텍처 뷰와 실제 업무 사이를 쉽게 오갈 수 있습니다.
이벤트 로그는 완료된 사례에 관한 근거를 더합니다. 어떤 활동이 어떤 순서로 진행되었는지, 사례 처리에 얼마나 걸렸는지 확인할 수 있습니다. 이 정보를 프로세스 모델과 비교하면 실제 실행이 문서화된 흐름과 다른 지점을 찾을 수 있습니다.
그렇다고 엔터프라이즈 아키텍처의 모든 부분을 이벤트 데이터에서 도출할 수 있다는 뜻은 아닙니다. 포트폴리오 결정, 표준, 목표 상태는 여전히 아키텍처 실무와 거버넌스가 필요합니다. 데이터는 프로세스 계층을 검증할 근거가 될 수 있지만 전체 저장소를 대체하지는 않습니다.
실제 업무에서 얻은 프로세스 상세 정보는 두 가지 실패를 모두 막는 데 도움이 됩니다. 아키텍처에 활동, 인계, 대기 시간이 나타나면 팀은 모델에서 자신의 업무를 확인할 수 있고, 담당자는 자신이 책임지는 의사결정을 파악할 수 있습니다. EA 도구는 포트폴리오를 관리할 수 있습니다. 포트폴리오를 실제로 구현하는 사람과 연결하는 것은 업무 자체입니다.
근거가 있으면 검토자가 확인할 수 있는 기준으로 연결을 검증할 수 있습니다. 모델에 표시된 대기 시간이 이벤트 로그의 대기 시간과 일치해야 합니다. 다르다면 다이어그램이 아니라 프로세스를 두고 논의할 수 있습니다. 이는 모델을 다시 갱신하는 것보다 생산적인 논의입니다.
업무 순서도 달라집니다. 저장소를 먼저 완성한 뒤 나중에 세부 정보를 채우기를 기다리는 대신, 프로세스 하나를 측정하고 상위 수준에 연결한 다음 검증 가능한 모델부터 신뢰를 쌓을 수 있습니다. 첫 단계는 완료할 수 있을 만큼 범위가 작고, 아키텍처 프로그램에 계획이 아닌 실제 사례를 제공합니다.
프로세스 수준과 관계를 표현하는 방법은 프로세스 아키텍처 문서화에서 확인할 수 있습니다. 데이터 관련 내용은 process mining 이벤트 로그 생성 방법을 참고하세요.
가치 흐름 매핑은 TOGAF를 실무에 적용하는 방법인가요?
TOGAF는 가치 흐름과 역량 맵을 포함한 비즈니스 아키텍처를 요구합니다. 가치 흐름 매핑은 이 계층을 구축하는 방법입니다. 가치 흐름을 매핑하고 그 아래에 프로세스를 연결한 다음, 실제 업무를 측정해 전체 내용을 검증합니다. Process Architecture 등급에서 가치 흐름을 먼저 다루는 이유는 조직 안에서 가치가 어떻게 이동하는지와 아키텍처를 연결하는 데 도움이 되기 때문입니다. TOGAF를 전면 도입하려면 표준 위원회와 거버넌스 일정도 필요하지만, 모델은 여기서 시작할 수 있습니다.
ProcessMind는 왜 다른 방식으로 아키텍처를 다루나요?
ProcessMind는 데이터로 검증할 수 있는 부분부터 아키텍처를 다룹니다. 이는 저장소 기능을 축소한 버전이 아니라 의도적으로 다른 접근 방식입니다.
TOGAF를 검토했지만 데이터에 기반해 유지하기는 쉽지 않습니다. 우선 측정하고 검증할 수 있는 부분에 집중하기로 했습니다. 프로세스를 최적화해 가장 큰 가치를 얻을 수 있는 영역이기도 합니다.
포트폴리오 관리, 애플리케이션 수명 주기, 표준 거버넌스는 저장소 도구가 주로 다루는 영역입니다. ARIS, SAP LeanIX, Bizzdesign, MEGA HOPEX, Orbus, Sparx는 이러한 업무를 잘 지원합니다. ProcessMind는 프로세스 계층을 다룹니다.
ProcessMind는 가치 흐름, 설정 가능한 프로세스 수준, RACI 담당자 지정, 거버넌스 워크플로와 열람자 포털을 이벤트 데이터에 연결해 프로세스 계층을 지원합니다. 프로세스 관련 질문에는 이 계층만으로도 활용할 수 있으며, 아키텍처 프로그램에 저장소가 필요하다면 함께 사용할 수 있습니다.
엔터프라이즈 아키텍처 도구는 어떻게 선택해야 하나요?
팀이 답을 얻어야 하는 질문과 관리해야 하는 아키텍처 업무를 기준으로 선택하세요.
- 포트폴리오 관리, 표준, 로드맵이 필요합니다: 전체 EA 제품군을 후보로 두고 저장소를 관리하는 데 필요한 인력과 프로세스를 계획하세요.
- 애플리케이션과 역량을 SaaS 방식으로 관리하고 싶습니다: SAP LeanIX 같은 EA 관리 플랫폼이 자산 목록 및 거버넌스 요건에 맞는지 평가하세요.
- 프로세스 실행 방식에 관한 답이 필요합니다: 프로세스 모델과 운영 데이터부터 살펴본 뒤 더 폭넓은 저장소도 필요한지 결정하세요.
- 아직 결정하지 못했습니다: 팀에서 자주 묻는 질문을 파악하세요. 저장소, 프로세스 실행 근거, 또는 두 가지 모두 중 어디서 시작할지 결정하는 데 도움이 됩니다.
저장소 중심 도구를 비교하고 있다면 ARIS 대안 비교를 확인하세요. 모델과 데이터의 연계 방식을 살펴보려면 프로세스 모델링과 process mining의 상호 보완 방식을 참고하세요.
근거를 확보할 수 있는 곳에서 시작하세요. 아키텍처 프로그램에 더 폭넓은 거버넌스와 포트폴리오 관리 기능이 필요할 때 저장소를 추가하면 됩니다.
ProcessMind는 어떤 역할을 하나요?
ProcessMind는 프로세스와 가치 흐름을 다루는 계층으로, 아키텍처를 실제 업무 실행 근거와 연결합니다.
저장소가 포트폴리오와 표준을 관리한다면 ProcessMind는 프로세스 계층과 그에 관한 근거를 관리합니다. 두 도구를 함께 사용하는 팀은 프로세스 상세 정보를 검증할 수 있습니다. 프로세스 계층만 필요한 팀은 ProcessMind만 사용할 수 있습니다.
프로세스를 설정 가능한 수준으로 구성하고 BPMN 2.0으로 모델링할 수 있으며, RACI 담당자를 지정하고 거버넌스 워크플로와 열람자 포털을 사용할 수 있습니다. 프로세스 모델을 이벤트 데이터에 연결해 문서화된 프로세스와 실제 실행을 비교할 수도 있습니다. 프로세스 시뮬레이션으로 운영 환경의 프로세스를 변경하기 전에 모델에서 변경안을 검토할 수 있습니다.
제품의 프로세스 아키텍처 기능을 자세히 알아보려면 엔터프라이즈 프로세스 아키텍처 페이지를 방문하세요. 프로세스 거버넌스와 process mining이란도 확인할 수 있습니다.
Where to Go From Here
팀이 실제로 일하는 수준까지 살펴보고 운영 데이터와 대조할 수 있는 프로세스 아키텍처가 필요합니다.
