 |
|
난이도 : 중급 Jean Wang, 선임 비즈니스 분석가 겸 SOA 컨설턴트, IBM
2008 년 6 월 03 일 의료기관들은 현재 IT 솔루션에 SOA를 적용하는 변화를 시도하고 있습니다. 하지만 비즈니스 사용자의 필요에 맞는 솔루션을 도입하는 것은 분명 어려운 일입니다. 비즈니스 비전과 요구사항을 분석해 이를 기술과 접목시키는 것은 SOA 구현의 가장 핵심적인 순서입니다. 본 글은 의료 정보 교환 네트워크를 예로 들어 이 요구사항들을 관리하는 방법론과 베스트 프랙티스를 설명하고 소프트웨어를 도구화해 SOA를 채택하는 동안 비즈니스 목표에 부합하는 기술 투자가 이뤄지도록 합니다.
도전 과제: IT와 의료 정보 교환의 통합
미국 정부가 오는 2014년까지 EMR(electronic medical records: 전자 의료 기록)을 전국적으로 채택하겠다는 전략적 목표를 세움에 따라 의료 정보 공유 요구가 급물살을 타고 있다(참고자료에서 "Bush Touts Plan for Electronic Medicine"를 읽어보자). 개별 의료기관 내의 의료 정보 교환은 환자의 요구와 적절한 공공 의료기관의 필요를 충족시키는 데 턱없이 부족하다. 환자 간호의 질을 향상시키고 비용을 줄이고 간호의 생산성과 효율성을 높이려면 지역 병원은 물론 전국 의료기관 간의 의료 데이터를 교환할 수 있어야 한다. 질병 관리와 전염병 통제가 필요한 지역에서 전국적인 공공 의료 서비스를 향상시키려면 그림 1에서 볼 수 있는 것처럼 전국적 수준에서, 더 나아가 전 세계적 수준에서 의료 정보 공유가 쉽게 이뤄져야 한다. 몇 년 전 전 세계를 강타한 사스(SARS)는 의료 정보가 온 디맨드로 필요하다는 구체적인 예가 될 수 있겠다(참고자료의 World Health Organization 링크를 참조하자).
그림 1. 의료 정보 교환 네트워크
하지만 위에 언급한 수준으로 의료 정보 네트워크를 구축하는 것이 얼마나 어려운지 간과해서는 안 된다. 이 네트워크는 환자, 의료 제공자, 의료보험 업체, 정부 및 다른 참여단체 등 모든 참여자의 요구사항을 만족시킬 수 있는 효과적인 정보 교환 네트워크를 필요로 한다. 이와 함께 모든 관여자들이 다른 관여자들의 네트워크에서도 서비스를 받아 업계 표준을 채택함으로써 의료 데이터 통합과 사용을 가능케 해야 한다.
진정한 의료 정보 교환을 위한 기술과 비즈니스 요구 사이에는 엄연히 벽이 존재한다.
- IT 관점에서 보면, 의료 정보 공유 범위를 확대하는 동안 많은 IT 그룹이 내외부적으로 필요한 컴포넌트나 자산을 개발해 왔을 것이다. 즉, 기술적 자산의 양은 지속적으로 늘어날 것이지만 모든 가능한 컴포넌트와 자산을 모으고 관리할 일반적인 라이브러리가 없다는 게 문제다. 이를 해결하려면 기술을 재발견해야 한다.
- 비즈니스 전략 관점에서 의료 정보 네트워크 필요성은 비즈니스 사용자의 일방적인 필요에 의해 제기됐다. 하지만 SOA 버전 지원에 대한 기술적 지식은 미비한 상태다. 이 때문에 비즈니스 전략과 기본 기술 사이에 격차가 발생했고 이는 의료 전환을 위한 SOA 목표에 지속적으로 주요 장애가 되고 있다.
- 의료 정보 공유 프로젝트에 대한 많은 일반적인 비즈니스 요구사항은 프로젝트 수준과 네트워크에 따라 달라 이를 수집하고 유지하는 데 반복된 노력을 하고 있다.
필요한 요구사항을 설명하는 예를 살펴보자. 의료 정보 교환 네트워크는 환자를 등록, 식별해야 하고 환자 데이터를 저장, 등록해야 한다. 공유 가능한 요구사항 풀이 없다면 이를 식별, 수집하기 위해 추가 단계와 업무가 필요하다(그렇지 않다면 주요 데이터가 빠질 수 있다). 여기에 더해 이 업무들을 효율적으로 해결할 시스템 같은 IT 요구사항 역시 비즈니스 요구사항을 충족시키는 데 꼭 필요하다.
수많은 연구물과 조사를 통해 보고됐듯이 요구사항을 정의하고 관리하는 데 실패한다면 소프트웨어 솔루션 개발 프로젝트 역시 실패할 수밖에 없다(참고자료의 "Why Software Fails"와 "Improving time-to-market using SDL tools and techniques"를 읽어보자). 소프트웨어 툴링이 발전함에 따라(IBM® Rational® RequisitePro® 같은) 요구사항에 맞는 엔지니어링 능력을 갖출 수 있게 됐고, 의료 솔루션 개발 분야에서 특히 장점이 있다는 점이 인식되고 있음에도 많은 복잡한 프로젝트에서 이 요구사항들은 고비용 노동력과 잠재성 채우기 부족으로 수동으로 관리되는 실정이다(참고자료의 "Software Technology in the Health Care Industry"을 읽어보자). 의료 비즈니스 요구사항과 기술 요구사항 간의 차이는 그림 2에서 보여준다. 구조적으로 요구사항을 찾아 분석하고 이 요구사항을 자산과 결합시키며 이들 간의 역동적 관계를 관리하는 것은 솔루션 개발 주기에서 무시할 수 없는 노력이자 SOA가 해결하려 했던 어려움이다.
그림 2. 의료 비즈니스 목표와 기존 의료 IT 자산 간의 격차
본 글은 필요한 엔지니어링 방법론과 도구를 사용해 이 격차를 줄이는 해결책을 소개한다.
비즈니스 요구사항 관리와 SOA 구현
열악한 요구사항 관리 때문에 많은 IT 프로젝트가 실패를 경험한다(참고자료의 "Why Software Fails"와 "Managing emerging software technologies: a technology transfer framework"를 읽어보자). 요구사항 관리 실패의 가장 일반적인 요인은 비현실적이거나 불분명한 프로젝트 목표와 잘못 정의된 시스템 요구사항이다. 비즈니스 필요에 맞는 시스템을 구현하는 대신 "기술을 쫓는 것"이 훨씬 쉽다. 엔지니어링 요구사항은 최근 소프트웨어 엔지니어링 분야로 진화하고 있으며 이는 연구 분야에도 같이 적용된다(참고자료의 책, "The fundamental nature of requirements engineering activities as a decision-making process"와 "Requirement acquisition for rapid application development"를 읽어보자). 시스템 개발을 위한 요구 프로세스를 지원하는 COTS(commercial-off-the-shelf) 소프트웨어 제품이 점점 늘어나고 있다(참고자료의 "Requirements engineering for COTS based systems"을 읽어보자). 솔루션 개발의 이점을 위해 SOA에 대한 관심과 채택률이 높아지긴 하지만 의료업계의 SOA 솔루션을 위한 시스템적 관리 요구사항 실행은 그만큼 이뤄지지 않고 있다. 의료 비즈니스 프로세스와 프로세스 기간 중 의료 데이터 교환의 복잡성 때문에 요구사항을 받아들이고 분석하는 것이 매우 어렵다.
SOA는 IT 아키텍처적 스타일로 서비스 지향을 지원하고 비즈니스 프로세스를 서비스와 결합해 비즈니스 신속성을 지원하도록 통합할 수 있다. SOA의 가장 기본적인 목표는 조직이 새 비즈니스 전략을 채택하는 데 있어 즉시적인 반응과 유연성이 있어야 하며 새 서비스를 만들어 지금의 역동적인 비즈니스 변화 환경으로 야기되는 어려움을 극복할 수 있도록 하는 것이다(참고자료의 "Service-oriented Architecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap"을 읽어보자). SOA의 생명주기는 비즈니스 서비스 개발 프로세스에 해당 전문가를 불러옴으로써 비즈니스 목표와 요구사항을 이해하는 것에서 시작한다. 현재 SOA 구현 프로세스에서 핵심은 비즈니스 주도의 완전히 반복적인 프로세스를 비즈니스 필요를 개발하는 것으로 바꾸는 것이므로 말이 된다.
비즈니스 요구사항 관리는 SOA 생명주기의 첫 단계다. 이는 또한 의료 정보 교환 시스템을 만드는 주요 시작점이기도 하다. 이 요구사항들은 의료 정보 네트워크 전반에서 상호운용적인 서비스를 위한 의료 목표와 요구사항이 모든 투자자에게 공유되고 제대로 실행되도록 지원한다.
의료 정보 교환 요구사항과 IT를 연결하는 모델 만들기
비즈니스 요구사항과 SOA 솔루션을 제공하는 기본적인 기술을 매핑하는 단계를 살펴보자.
1단계. 의료 정보 교환의 비즈니스 가능성과 IT 자산을 연결하는 재사용 레이어 만들기
본 글에서 설명하는 방법은 요구사항 관리 소프트웨어인 Rational RequisitePro를 요구사항 저장소, 분석, 엔지니어링 도구로 사용한다.
- Rational RequisitePro에서 호환성을 확보하는 데 필요한 모든 의료와 관련된 기능적, 비기능적 가능성을 수집, 정리하고 우선순위를 매기자.
- 솔루션 컴포넌트, 제품, 서비스를 포함하는 기존 IT 자산을 모으고 정리하자. 이 자산은 다른 엔터티로 개발됐으며 오픈 소스 자산, 업계 표준, 사내 자산, 비즈니스 파트너로부터의 자산, 일반적인 IT 자산 같은 다양한 소스로 전개된다.
- Rational RequisitePro가 제공하는 이력추적관리(traceability)를 사용해 각각의 가능성 있는 컴포넌트를 적절한 IT 자산과 매핑한다.
RequisitePro는 모든 기능적, 비기능적 가능성과 의료 정보 교환 네트워크를 위한 기본 자산을 가지는 관계형 저장소 역할을 한다. 이를 통해 윗 부분의 비즈니스 요구사항을 기술 자산과 연결하는 데 사용하는 중간 레이어를 만든다. 이 레이어가 만들어지면 의료에 특화된 자산이 다양한 프로젝트에서 재사용될 수 있다.
2단계. 의료 정보 교환에 참여하는 엔터티로부터 비즈니스 요구사항 모으기
많은 의료 정보 교환 정책이 이미 수립돼 있거나 확대 적용되고 있다. 이를 진두 지휘하는 조직에는 RHIO(Regional Health Information Organization), NHIN(National Health Information Network)이 있으며 기업의 도움으로 진행되는 의료 정보 교환 프로젝트도 많이 있다. 이 프로젝트들은 같은 요구사항을 공유하므로 같은 기술을 원한다. 예를 들어 환자 데이터를 안전하게 전자적으로 공유하는 것은 모든 정책이 필요로 하는 부분이다. 주요 환자 색인을 사용해 환자를 식별하는 것은 또 다른 예다. 하지만 조직들은 여전히 다양한 의료 솔루션을 위해 전통적인 방법으로 자주 사용되는 요구사항을 만들어내기 위해 엄청난 노력을 하고 있다. 문제는 누군가가 이미 그 솔루션을 만들어냈을 수도 있거나 요구사항을 공유하는 데 있어 더 나은 방법이 있을 수도 있는데 이를 인식하지 못하고 있다는 것이다. 그러므로 의료 정보 네트워크에 있어 소프트웨어 엔지니어링 도구를 사용해 일반적인 요구사항 풀을 만들어 요구사항이 재사용될 수 있게 하는 것은 매우 가치있는 일이다.
의료 솔루션 개발 프로세스 중 비즈니스 목표는 대체로 전략을 만들어내는 이들에 의해 높은 수준으로 정의되며 세세한 비즈니스 요구사항은 도메인 전문가, 비즈니스 분석가, 프로세스 소유자가 정의한다. 이렇게 되면 비즈니스 목표와 실행 가능한 요구사항이 서로 연결되지 않을 수 있다. 이 정책들을 위한 솔루션이 비즈니스 필요와 맞으려면 요구사항이 관리돼 각각이 더 높은 수준의 비즈니스 목표와 맞아야 하고 추적이 가능해야 한다. 그림 3은 Rational RequisitePro를 사용해 의료 정보 교환을 위한 비즈니스 요구사항을 통합하고 우선순위를 매기는 방법을 보여준다.
이 방법을 사용하려면 요구사항을 수집, 평가, 중재하는 데 그치지 않고 수정 기록과 팀 토론을 추적할 수 있게 해주는 변경 관리 기능을 운영해야 한다.
이런 노력을 통해 정책 방향성에 부합하는, 재사용 가능한 요구사항 기반을 만들 수 있다. 그림 3은 이것을 설명한다.
그림 3. 비즈니스 요구사항은 의료 정보 교환을 위해 통합되고 우선순위가 매겨진다.
3단계. 요구사항과 기능 매핑하기
1단계에서 만든 재사용 가능한 기술 레이어와 2단계에서 만든 비즈니스 요구사항 레이어로 비즈니스와 기술을 연관짓는 것이 더 쉬워졌다. 이제 요구사항을 만족시키는 IT 기능과 각각의 요구사항을 매핑해야 한다. 예를 들어 비즈니스 기능으로 환자 기록을 질의해야 한다면 비즈니스 아키텍트는 이를 질의에 적합한 데이터 소스인 의료 문서 저장소와 연계하기 쉽다. 하지만 동시에 이 비즈니스 기능을 규정에 맞게 수행하려면 의료 문서를 질의할 때 감사 서비스가 필요하다. 그림 4는 요구사항과 의료 IT 기능이 매핑되는 것을 보여준다.
그림 4. 비즈니스 요구사항과 의료 IT 기능의 결합은 비즈니스와 기술의 연결을 나타낸다.
4단계. 비즈니스 목표와 요구사항을 기술 자산에 명확히 연결하기
요구사항과 IT 기능의 관계가 성립되면 그림 6에서 설명하는 것처럼 비즈니스와 기술 레이어를 자연스럽게 이어야 한다. 새롭게 만들어진 계층을 통해 어떤 목표가 어떤 비즈니스 요구사항으로 지원되고 어떤 기술로 충족되며 어떤 자산으로 가능해지는지 쉽게 볼 수 있다(그림 5를 보자).
그림 5. 각 레이어 간의 관계를 성립하면 비즈니스 뷰에서 의료 IT 뷰까지 명확히 추적할 수 있다.
그림 6은 높은 수준의 전염병 포착 목표가 기술 레벨에서부터 비즈니스 레벨을 통해 어떻게 지원되고 가능해지는지를 트리 뷰 형태로 보여준다. 이 기술 자산 중 OHF ATNA(Open Health Framework Audit Trail and Node Authentication) 클라이언트로부터 IHE ATNA(Integrating the Healthcare Enterprise Audit Trail and Node Authentication) 클라이언트로 소개되는 Audit Trail and Node Authentication Profile 같은 오픈 소스 아이템은 쉽게 식별된다.
그림 6. Rational RequisitePro에서 의료 정보 교환을 위한 비즈니스 목표는 의료 IT 자산으로 추적된다.
본 글에서 설명한 요구사항 모델과 방법론을 사용해 복잡성을 아주 간단하게 만들어주는 도구와 개발 주기 전반에서 확장될 수 있는 요구사항 추출 수준을 높임으로써 획기적인 차이를 만들 수 있다. 이를 통해 비즈니스 소유자와 기술 전문가들이 더 효율적으로 소통하여 요구사항을 정확하게 전달, 실행함으로써 정확한 제품을 생산해낼 수 있다(참고자료의 "Aligning Information Technology with Health Information Exchange"를 읽어보자). 또한 SOA 원칙 하에서 요구사항을 설계함으로써 전체 개발 주기에서 시스템 디자인, 낮은 비용으로 효율적인 솔루션을 만들고 테스트하기, 전반적인 개발 시간 단축을 이뤄낼 수 있다.
결론
의료 서비스와 IT 기술 간의 격차를 메우는 것은 의료업계가 해결해야 할 가장 중요한 문제다. SOA는 효과적인 접근을 제공해 이 문제에 직면하는 동시에 의료 정보 교환 시스템을 만든다. 비즈니스 주도 SOA는 의료 비즈니스 목표, 문제점, 현실을 반영하는 훌륭한 접근이다. SOA가 가능한 시스템은 어떤 기술을 어떻게 사용해 비즈니스 필요를 충족시키는지를 이해하는 것에서 시작한다. 이 글에서 제시한 COTS 소프트웨어 툴링과 방법론으로 비즈니스 요구사항과 관련 기술을 연결하고 이를 시스템적으로 관리하는 것까지 쉽게 해결할 수 있다. 비즈니스 요구사항을 IT 능력과 매핑하고 요구사항을 만족시키는 자산과 제품으로 이것들을 관련 지을 수 있다. 또한 이 모델에서 수집한 요구사항과 자산은 정보 공유가 중요한 많은 의료 프로젝트에서 재사용할 수 있다. 이 접근은 가능한 의료 IT 리소스를 사용해 비용을 절감하는 동시에 비즈니스 필요에서부터 프로젝트 개발을 시작해 의료업계 변화에 솔루션을 전달함으로써 비즈니스 목표를 더 성공적으로 달성할 수 있게 해 준다.
감사의 말
미래의 전략과 비전을 설정하는 데 도움을 준 Dr. Ben Amaba, Richard Adams, Dr. Anne Aldous, Ed Macko, Dr. Ajay Asthana, Leonard Lee, Houton Aghili, Dr. Prasanna Athma의 도움에 감사한다.
참고자료 교육
-
워싱턴 포스트의 "Bush Touts Plan for Electronic Medicine"은 의료 정보 교환 계획의 좋은 개요다.
- World Health Organization 카달로그의 "WHO coordinates international effort to identify and treat SARS"에서 의료 정보를 조정하려는 노력을 보인다.
- R.N. Charette의 "Why Software Fails"[PDF]를 읽자.
- N.N. Mansurov와 R.L. Probert의 "Improving time-to-market using SDL tools and techniques"[PDF]를 확인하자.
- A. Asthana, H. Wang, B. Amaba의 "Software Technology in the Health Care Industry"을 읽자.
- T.D. Korson과 V.K. Vaishnavi의 "Managing emerging software technologies: a technology transfer framework"를 읽자.
- Aybu¨ke Aurum과 Claes Wohlin의 "The fundamental nature of requirements engineering activities as a decision-making process"에 대해 더 배워보자.
- M. Eva의 "Requirements acquisition for rapid applications development"를 확인하자.
- C. Rolland의 "Requirements engineering for COTS based systems"에 대해 더 자세히 알아보자.
- N. Bieberstein, S. Bose, M. Fiammante, K. Jones, R. Shah의 "Service-oriented Architecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap"을 읽자.
- 한국 IBM developerWorks의 SOA와 웹 서비스 존은 수많은 정보가 가득한 글과 웹 서비스 애플리케이션을 개발하는 방법에 대한 초급, 중급, 고급 수준의 튜토리얼을 제공한다.
-
IBM SOA Sandbox에서 놀아보자! IBM SOA 엔트리 포인트와 실용서 및 실전 경험을 통해 SOA 기술을 향상시키자.
-
IBM SOA 웹 사이트는 SOA에 대한 개요와 IBM이 SOA를 어떻게 지원하는지를 설명한다.
-
developerWorks 기술 행사와 웹 캐스트를 통해 최신 기술을 얻자. 특히 다음의 SOA와 웹 서비스 기술을 확인하자.
-
Safari 서점에서 다양한 기술 주제에 관련된 책을 찾아보자.
-
웹 서비스 온 디맨드 데모를 확인하자.
제품 및 기술 얻기
토론
필자소개 | | | Dr. Jean Wang은 생명공학과 IT 분야에서 일해왔고 과학 연구와 개발, 소프트웨어 개발, 교육, 컨설팅의 기능적 분야에 학문적 초점을 맞춰왔다. 현재 IBM의 수석 SOA 비즈니스 아키텍트이자 SOA 컨설턴트로 일하며 혁신적 솔루션과 방법론을 개발, SOA를 사용해 고객들이 자신의 비즈니스를 더 반응적이고 효율적인 기업으로 탈바꿈할 수 있도록 지원하고 있다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
