데이터아키텍트가 비즈니스 업무 부서와 협업하기 위해 알아야 할...

데이터 아키텍트가 비즈니스 업무 부서와

협업하기 위해 알아야 할 5 가지

작성자 : 캐런 로페즈 (InfoAdvisors, Inc. 수석 프로젝트 매니저/아키텍트)

2014 년

본 백서는 InfoAdvisors 에서 제작한 문서로 엠바카데로 테크놀러지의 후원을 받아 작성되었습니다.

Americas Headquarters

100 California Street, 12th

Floor

San Francisco, California

94111

EMEA Headquarters

York House

18 York Road

Maidenhead, Berkshire

SL6 1SF, United Kingdom

Devgear

서울특별시 반포 1 동 746-14

3 층 ㈜데브기어

(T) 02.595. 4288

DA

가

알아야

할 5

가지

InfoAdvisors 제작 Sponsored by Embarcadero Technologies

데이터 아키텍트가 알아야 할 5가지

데브기어 기술자료 tech.devgear.co.kr 데브기어 홈페이지 www.devgear.co.kr 문의 [email protected]

모든 것이 오직 비즈니스를 지원하기 위해서.

아키텍트는 비즈니스를 분석하고 해법을 제시한다. 하지만, 제시된 해법을 잘 들여다보면 가끔은 주객이 전도된

경우도 발견된다. 즉 해법 안에 기술적인 요소 그리고 이와 관련된 상세한 사항들이 가득 담겨있지만, 그

기술들이 사용되어야 하는 진정한 이유인 비즈니스 업무 수행이 뒷전으로 밀리기도 하는 것이다. 본론을

시작하기에 앞서 다시 한번 짚고 넘어가고자 하는 바는 바로 “기술이란 성공적인 비즈니스 업무 수행을 돕기

위해 필요하다” 라는 사실이다.

이와 같은 기술의 진정한 목표는 프로젝트 전반에 걸쳐 항상 마음 속을 비추고 있어야 한다. 그리고 우리는

비즈니스 요구사항을 수준 높게 확인할 수 있어야 한다. 이것을 가능하게 하는 중요한 성공 요소는 “비즈니스

부서와의 긴밀한 관계” 그 자체이다.

“DBA 와 개발자의 밀접한 협업을 통해 프로젝트를 더 쉽게, 제품을 더 좋게, 팀워크를 더욱 강하게 하는 7 단계

접근법” 이라는 지난 기술 백서에서는 IT 부서의 팀원들 모두가 동일한 목표를 지향하고 올바른 방식을 사용할

수 있도록 만들기 위해 아키텍트가 수행할 수 있는 7 단계 접근법을 제시하였다.

IT 팀만의 내부 협업은 매우 쉽고 익숙하다. 즉 IT 팀 내부에는 우리만의 절차와 언어가 잘 통하므로 서로를

이해하고, 또 이해시키는 것이 매우 자연스럽다.

하지만, 비즈니스 업무 부서와 협업할 때에는 “협업이 과연 효과적인가” 하는 근본적인 문제가 발생한다. 그런데,

바로 이 협업의 효과야말로 프로젝트의 품질을 높이기 위한 매우 중요한 요소이다. 이러한 요소가 부족한 경우,

구현할 기능 목록 정의서가 비즈니스 니즈(Needs)를 알맞게 반영하고 있지 못하는 경우가 발생될 수 있고,

기술적인 구현 과정에서 비즈니스 부서의 요구사항이 유실되기도 한다.

비즈니스 업무 사용자들과의 상호 교감을 향상시키는 것 또한 필요하다. 교감이 깊어질수록 비즈니스

부서에서는, 우리 IT 팀이 만들어 내는 것들이 자신들의 임무 즉 비즈니스가 보다 앞서갈 수 있도록 도와 준다는

점을 더욱 확신할 것이다. 이 백서에서는 여러분이 비즈니스 업무 사용자들과의 협업을 향상시키기 위해 지금

당장 적용할 수 있는 5 가지 방안을 제시하고자 한다.

협업을 장려한다

어떻게 하면 우리 회사의 비즈니스 업무부서의 사람들과 보다 견고한 관계를 유지하고 협업을 강화할 수

있을까?

모델을 작성할 때, 비즈니스 차원의 실제 가치를 담은 모델을 만들어 보자. 이 모델에는 비즈니스

사용자들로부터 받은 피드백이 잘 담겨 있어야 한다. 비즈니스 사용자들은 주로 자신들의 업무에 맞는 해법을

찾는 일에 대해서 도움을 주는 경향이 있다. 하지만 이를 위해서는 선행되어야 할 것이 있다. 즉 IT 부서와 비 IT

부서의 관계자들 간의 커뮤니케이션 환경이 보다 간편해져야 원활한 의사소통이 시작되고 지속될 수 있다.

우리는 비즈니스 차원의 협업을 장려하기 위해 팀원들에게 다음과 같은 사항을 권장해오고 있다.

보편적인 도구를 사용할 것. 비즈니스 사용자와 IT 전문가가 서로 다른 도구를 사용하면, 모델에 대해

함께 작업하는 것이 어려워진다. 비즈니스 사용자들이 전달하는 정보가 오로지 종이에 출력된 것으로

만 제공된다고 상상해보자. 항목이 모두 수 천 개가 되더라고, 결국 전부 다시 키보드를 통해 입력해야

InfoAdvisors 제작 Sponsored by Embarcadero Technologies - 3 -


1.

마스터

데이터

도메인


DA

가

알아야

할 5

가지

할 것이다. 거꾸로 아키텍트가 모델을 항상 종이로 출력해서 전달한다면, 비즈니스 사용자들 또한 같은

수고를 하게 된다.

받아들이는 사람에게 알맞게 정리된 산출물을 만들 것. IT 전문가라면 DBA나 개발자들이 사용하는 것

과 동일한 산출물을 비즈니스 사용자들 또한 쓸 수 있다고 가정하면 안 된다. 비즈니스 사용자들이 모

델을 검토하는 목표 자체가 우리와 다르다. 이들은 자신들의 요구사항이 완벽하게 반영 또는, 변경 되

었는지를 확인하기 위해 모델을 검토한다. 비즈니스와 기술부서 모두가 같이 사용할 수 있도록 한 장

의 종이에 양쪽 관련 요소를 모아서 표현하는 경우, 실제로는 양쪽 모두에게 쓸모 없는 산출물이 될 확

률이 매우 높다. 그러므로 산출물의 기초가 되는 데이터는 하나로 가지고 있고, 산출물은 이를 바탕으

로 하여 각 사용자 (또는 역할) 별로 자신에게 필요한 표준 산출물을 제공해 줄 수 있는 해법을 제공하

는 것이 최상의 방법이다.

비즈니스 사용자와 해당 모델간에 존재하는 불필요한 프로세스를 제거할 것. 모델을 보고 싶을 때 마다

업무 협조가 필요하게 된다면 모델과 그 안의 정보들을 사용할 의지를 꺾게 된다. 비즈니스 사용자들

또한 자신과 관련된 모델이 필요할 때, 바로 접근할 수 있고 익숙한 형식으로 활용할 수 있어야 한다.

비즈니스 사용자에게는 그들이 필요한 것을 줄 것. 비즈니스 사용자들은 모델에 편리하게 접근할 수 있

게 되면, 이를 잘 활용하는 경향이 있다. 예를 들어 만약 모델이 IT 부서만을 위한 것이라는 인식에 사

로잡히게 되면, 개발 과정에 자기 부서의 인원을 기꺼이 제공하고 싶은 관리자는 거의 없게 된다. 하지

만 관리자가 볼 때 자신의 팀원이 모델을 비즈니스 프로세스의 일환으로 적절히 활용하고 있다면, 프

로젝트에 기꺼이 참여시켜 줄 확률이 높아지게 된다.

비즈니스 사용자들을 토론하고 의견을 말하게 할 것. 비즈니스 사용자들은 이메일을 통해서가 아니라

직접 질문을 던지고 답을 주면서 모델과 메타데이터를 함께 살펴볼 수 있어야 한다. 모델링 오브젝트

와 소셜 관계를 맺음으로써 사용자들은 데이터 요구사항을 파악하는 프로세스의 한 부분이 될 수 있다.

이상과 같이 비즈니스 팀과의 협업을 장려하기 위한 첫번째 단계는 협업에 방해되는 장애물을 제거하는 것이다.

이제 그 다음 협업을 강화하는 단계로 비즈니스 사용자들이 모델을 사용하도록 장려하는 방안을 살펴보자.




비즈니스 업무 사용자를 끌어들인다

어떻게 하면 우리가 만들어 내는 모델에 비즈니스 적인 가치를 많이 담을 수 있을까?

IT 전문가라면 비즈니스 사용자들에게 높은 품질의 정보를 제때 제공하는 것이 중요하다는 점을 잘 알고 있다.

하지만 우리는 비즈니스 사용자들이 더 적극적으로 우리와 함께할 수 있도록 하기 위해 싸워야 할 때도 가끔

있다. 이제 이러한 단점을 유발하는 근본적인 몇 가지 배경부터 살펴보자.

모델링 산출물은 폭넓고 다양한 사용자들을 지원할 수 있어야 한다

많은 아키텍트들이 오직 한가지 버전의 모델만을 만들어 낸다. 개발자와 DBA 를 모델의 주된

사용자로 인식하기 때문에 모델은 개발을 위해 최적화된 형태로 작성된다. 하지만, 모델은 각

비즈니스 사용자들로부터 서로 다른 자신만의 고유한 니즈(Needs)가 올바로 반영되었는지 검토

또는 검증하기 위한 용도로도 사용될 수 있어야 한다.

비즈니스 사용자들이 모델을 검토하는 목표는 각자가 서로 다르기 때문에 우리는 이러한 고유한 각각의 관점에

맞추어 주는 해법 자체를 제시할 필요가 있다. 데이터베이스 관리자들은 성능과 보안 등의 관점에서 모델을

검토하고자 할 것이고, 비즈니스 사용자들은 비즈니스 규칙의 일관성과 완전성이 보장되는지를 검토하기 위해

모델을 살필 것이다. 따라서, 데이터베이스 관리자에게 보여질 것은 데이터타입, PK, 파티션 등의 기술 상세

정보가 강조되어야 하고, 비즈니스 사용자들을 위한 것은 비즈니스적인 의미와 비즈니스 규칙이 명확히 제공될

수 있어야 할 것이다. 또한 비즈니스 관점으로 작성된 산출물은 IT 전문가를 위해 다시 구현되고 표현되는

과정에서 해당 사용자에게 익숙한 방법론 또는 표기법으로 표현이 될 것이다. 예를 들어 데이터 모델의 관계

차수는 “1”이나 “M”과 같은 문장 대신 정보 공학적인 표기법으로 표현됨으로써 IT 전문가들이 보다 쉽게

검증하고 활용할 수 있게 되는 것이다.

많은 사람들이 “모델은 IT 에 속하는 것”이라고 생각한다. 하지만, 실제로 많은 모델들이 기술적으로 독립적이다.

그러므로 모델은 해당 비즈니스 조직에 속해야 한다. 비즈니스 사용자들 스스로가 이해하지 못하는 모델을

가져서는 안 된다. 어떻게 하면 모델을 잘 다듬어서 비즈니스 사용자들이 지속적으로 참여할 수 있도록 만들

것인지를 고려해야 한다. 이렇게 작성된 유형의 모델은 논리 모델이라고 하는 대신 “비즈니스 모델”이라고

부르기를 권장한다. 더 나아가서, 물리 데이터 모델은 “데이터베이스를 위한 비즈니스 모델”이라고 부를 것과

물리 프로세스 모델을 “애플리케이션을 위한 비즈니스 모델”이라고 부르는 것도 좋은 방법이다. 이를 통해서

모델이란 오직 비즈니스 프로세스와 정보를 지원하기 위해 필요한 것임을 보다 분명하게 상기시킬 수 있을

것이다.

비즈니스 사용자들은 데이터와 프로세스 모델을 스스로 볼 수 있기를 원한다

모델을 비즈니스에서 바로 사용할 수 있도록 하는 셀프-서비스 도구를 제공하는 해법을

IT 부서에서 찾아내지 못한다면, 결과적으로 우리의 모델 작업에 해당 사용자들이 직접 참여하는

것을 막는 장벽을 만들게 된다. 이렇게 되면 “모델은 비즈니스 업무 수행과는 무관한 것”이라는

메시지를 전달하는 것과 마찬가지가 된다. 비즈니스 부서에서 프로젝트에 인력을 제공하고

모델을 개발하며 검증하는 데 참여할 수 있으려면 자신들의 모델에 쉽게 접근하여 사용할 수 있어야 한다. IT

부서에서는 모델에 대한 보다 쉬운 접근과 빈번한 활용을 장려할 수 있는 다양한 방안을 제시할 필요가 있다.

우리 경험상 비즈니스 사용자들이 모델에 셀프-서비스로 접근할 수 있게 되면 개발 프로세스에 참여하고 있다는

느낌을 보다 확실하게 가지게 된다.



1.

마스터

데이터

도메인


DA

가

알아야

할 5

가지

온디멘드, 셀프-서비스 방식으로 모델에 접근하게 하는 하나의 쉬운 방법은 ER/Studio® 엔터프라이즈 웹포탈을

활용하는 것이다. 이 포탈은 웹 기반 애플리케이션으로써 모델링 데이터를 브라우징하고, 검색하며 리포트를

작성할 수 있도록 해준다. 웹포탈의 기본 첫 화면은 아래의 그림 1 과 같다.

그림 1 - ER/Studio 팀 서버 홈페이지

ER/Studio 팀 서버는 ER/Studio 리포지토리 또는 DArtisan 에서 모델 정보를 가져온다. 이를 통해 비즈니스

사용자들은 모든 모델 안에 있는 거의 모든 형태의 오브젝트와 속성을 볼 수 있다. 또한 사용자들 각자가

선호하는 형식과 내용으로 모델 정보를 조회하고 출력하여 활용할 수 있다.

비즈니스 사용자들은 ER/Studio 팀 서버를 통해 용어사전, 데이터 모델, 데이터 소스, 데이터 라이니지(타겟 및

소스 맵핑) 메타데이터 등에 액세스 할 수 있다.

모델 오브젝트에 액세스

비즈니스 사용자들은 모델 다이어그램 이미지와 모델 내용 모두 활용할 수 있다. 그림 2 - 모델 탐색기 에서

보이는 바와 같이 사용자는 각자의 권한에 따라 허용된 프로젝트와 모델에 접근할 수 있다. 각 서브 모델 수준

내에서는 테이블, 컬럼, 도메인 등 모든 오브젝트에 대한 정의, 이름, 데이터타입, 제약조건, 보안 속성 등에

접근할 수 있다.




그림 2 - 모델 탐색기

또한 사용자는 직접 모델링 다이어그램 이미지를 조회하고 출력할 수 있다 (그림 3 – 데이터 모델 이미지 참고).

비즈니스 사용자들 스스로가 프린트할 수 있기 때문에 데이터 아키텍트에게 별도로 출력물을 요청할 필요가

없고, 양쪽 모두 상당한 시간을 절약할 수 있다.

그림 3 - 데이터 모델 이미지

비즈니스 사용자들은 데이터 모델링 툴을 배울 필요없이 데이터 모델을 바로 찾아 상호작용 할 수 있다. 뿐만

아니라 IT 전문가들의 도움 없이도 더욱 상세한 내용들을 원하는대로 찾아볼 수 있다.

그림 4 - 엔티티 정의와 속성에서 확인할 수 있듯 비즈니스 사용자들과 IT 사용자들 모두 데이터 모델에서 특정

엔티티와 메타데이터들을 직접 확인해 볼 수 있다.



1.

마스터

데이터

도메인


DA

가

알아야

할 5

가지

그림 4 - 엔티티 정의와 속성

사용자는 Follow(위 이미지의 우측 상단 파란색 버튼)를 이용해 오브젝트나 용어를 팔로우 할 수 있어 업데이트

사항이나 개선된 사항들을 모니터링 할 수 있다. 이 기능은 데이터 관리자나 거버넌스 관게자들에게 특히

유용하다.

비즈니스 사용자들은 그림 수준 이상의 정보를 필요로 한다

비록 그림이 모델링에서 매우 중요한 요소일지라도, 그 안에 의미와 속성값을 가지고 있지

않으면 모델이라고 할 수 없다. 사실상, 그림 하나만 달랑 가지고 있는 경우가 아예 그림을

가지고 있지 않는 것 보다 오히려 더 많은 오해와 실수를 유발하게 된다. 다이어그램 상의 각

오브젝트들은 깊고, 복잡하고, 상세한 개념을 함축한 상징물이지, 그저 보기 좋게 만들기 위해

상자모양과 선들을 단순하게 모아놓은 것이 아니다.

비즈니스 사용자들에게 아키텍트가 다이어그램 만을 제공하게 되면, 해당 모델이 정확성에 대해 비즈니스

사용자 들로부터 올바르게 검증받게 될 확률이 매우 낮아진다. 그 이유는 비즈니스 사용자들이 자신들의 수고에

비해 자신들의 업무 자체에는 별반 도움 되지 않는다고 생각되기 때문이다. 하지만, 아키텍트가 모델을 통해

모든 주요 내용과 유형을 담아서 제공하게 되면, 비즈니스 사용자들은 이러한 정보를 자신들을 위해 활용할

것이다. 이러한 윈-윈 상황이 있어야 협업이 보다 원활해지고 강력해질 수 있다.

실상, 모델에 대한 정보가 보다 많이 공유되고 사용될 수록, 보다 많은 관리와 인력이 참여하게 되고 그 결과

시간이 지날 수록 더 많은 정보가 모이게 된다.

비즈니스 용어 사전과 용어들

논리, 물리 모델 작업뿐만 아니라, 데이터 아키텍트들은 데이터베이스와 데이터모델과는 별도의 용어와 정의를

제공함으로써 비즈니스 가치를 더할 수 있다. 비즈니스 용어사전을 통해 비즈니스 사용자들은 프로젝트나 특정

패키지 애플리케이션에 대한 걱정 없이 개념을 정의할 수 있다. 그림 5 - 비즈니스 용어사전 및 용어는 샘플

고객 서비스(Customer Service) 용어 사전 화면이며, 그림 6 - 샘틀 용어는 비즈니스 용어에 대한 다양한 정의가

가능함을 보여준다.




그림 5 - 비즈니스 용어 사전과 용어

그림 6 - 샘플 용어

사용자 계약

비즈니스 용어나 모델들에 대한 사용자 의견과 문의사항들을 확인하는 전통적인 방식은 직접 미팅을 갖거나

항상 수신인이 랜덤인 듯한 혼란스러운 이메일을 주고받는 것이었다. ER/Studio 팀 서버를 통해 비즈니스

사용자들은 모델링 오브젝트들을 바로 활용할 수 있다. 그림 7 - 비즈니스 용어 의견 교환에서 볼 수 있듯이

비즈니스 사용자들은 ER/Studio 팀 서버 기능을 통해 질문하거나 답변을 받는 등 피드백을 확인할 수 있다.

이러한 의견 교환은 이메일 손실 문제가 없으며, 토론 대상이 단 한 사람으로 제한되지도 않는다. 모델러들과

다른 비즈니스 사용자들은 필요한 만큼 의견을 낼 수 있고 피드백도 받을 수 있다.



1.

마스터

데이터

도메인


DA

가

알아야

할 5

가지

그림 7 - 비즈니스 용어 의견 교환

비즈니스 사용자들이 모델을 활용할 때에는 지금까지 자신들이 사용하는 형식에 맞게, 그리고

자신들이 관심 있는 내용들만 보고 싶어한다.

만약 모델과 그 안에 내포된 정보가 오직 기술 전문가들을 위해서만 만들어진다면, 비즈니스

전문가들은 모델의 부가적인 모델링 기술 정보들을 파악하느라, 정작 중요한 검토를 빠뜨릴

수도 있다. 예를 들어, 한번의 거래(transaction)를 검토할 때, 각 거래를 다른 별도의 거래와

구분해주는 요소가 무엇인지에 대한 일상적인 이해가 올바른지를 검증받아야 한다고 가정해보자. 이 과정에서

비즈니스 사용자들이 SQL 서버의 SEQUENCE 데이터 타입을 통해 구분하게 된다는 것을 알려고 하는 경우는

거의 없을 것이다.

ER/Studio 팀 서버의 강점 중 하나는 기술 전문가와 비즈니스 전문가 모두가 각자에 맞게 그리고 쉽게 모델과 그

요소들을 사용할 수 있다는 점이다.

ER/Studio 팀 서버 비즈니스 리포트

ER/Studio 팀 서버를 통해서 사용자들과 관리자들은 필요할 때 바로 수행되는 표준 리포트를 만들어낼 수 있다.

따라서 모델링 오브젝트와 속성, 타입 등에 대해 잘 모르는 비즈니스 사용자들도 빠르게 해당 리포트를 생성해

낼 수 있다. 그림 8 - ER/Studio 팀 서버 리포트는 공유 비즈니스 리포트와 여기에 포함된 속성 별 비즈니스 정의,

엔티티 정의, 비즈니스 규칙을 볼 수 있다.

그림 8 - ER/Studio 팀 서버 리포트




MS 엑셀 또는 Comma Delimited 파일로 내보내기

일단 사용자들이 이러한 공유 표준 리포트나 각자의 리포트를 생성하고 나면, 그 결과를 MS 엑셀이나 Comma

delimited 파일로 저장할 수 있다. 이에 따라 사용자들에게 이미 익숙한 오피스 도구를 가지고 모델을 다룰 수

있다. 그림 9 – 리포트를 MS 엑셀로 익스포트하기 에서 처럼 속성(attribute) 리포트를 엑셀로 저장할 수 있다.

그림 9 - 리포트를 MS 엑셀로 익스포트하기

이를 통해 모델의 내용과 이미지를 다른 문서나 다른 표현 형식에서 활용할 수 있다. 이러한 사용자 참여가

일상화 된다면, 이들은 향후의 모델링 작업 시 기꺼이 협업을 할 것이다.

비즈니스는 결코 애플리케이션이 중심이 된 영역 안에서 수행되는 것이 아니다

IT 예산은 주로 애플리케이션 구축 프로젝트를 위해 배정이 되는 것이지 비즈니스 사용자들을

위해 배정되지 않는다. IT 팀은 각 프로젝트의 요구사항을 충족하기 위해 배정이 되고, 이들은

해당 프로젝트의 목표 수행 능력에 의해 평가 받는다. 프로젝트 팀은 이와 같이 프로젝트의

성패에 따라 평가 받기 때문에 자신만을 생각하여 도구와, 방법(론), 산출물을 선택한다. 이

과정에서 비즈니스 부서에서 프로젝트 팀의 작업 결과를 어떻게 접근하고 검증할 것인지에

대해서는 고려하지 않는 것이 보편적이다. IT 부서에서 업무 분석 결과를 정리하여 제공할 때에 비즈니스

사용자들에게 익숙하지 않은 형식과 내용을 쓰게 된다면, 비즈니스 사용자들이 이러한 결과물을 대하고 작업할

때 훨씬 더 힘들고 많은 시간을 보내게 될 것이다.

ER/Studio 엔터프라이즈 팀 서버는 리포지토리(Repository) 안에 들어있는 모델을 가져와서 제공하기 때문에

애플리케이션, 데이터베이스, 다이어그램 전반에 걸쳐서 그리고 어느 팀이 어떻게 만들었는지 관계없이

리포팅과 검색이 가능하다. 특히 개발 과정의 각 단위와 관계없이 전체적인 관점에서 검색하고 리포팅 할 수

있다는 점에 대해서 비즈니스 사용자들이 기뻐할 것이다. 고객 데이터가 어디에 있는지를 알기 위해 물리적인

데이터베이스나 테이블 이름을 알아야 할 필요가 없지 않은가!

ER/Studio 팀 서버 검색



1.

마스터

데이터

도메인


DA

가

알아야

할 5

가지

비즈니스 사용자들은 모델을 탐색하는 것 말고도, 리포지토리 안의 모델을 넘나들며 검색을 할 수 있다.

브라우저 오른쪽 상단에 있는 간단한 검색창을 사용할 수도 있고 거의 모든 유형의 오브젝트에 대해서 고급

검색을 수행할 수도 있을 것이다. 그림 10 - ER/Studio 팀 서버 검색 옵션에서 보여지듯이 결과를 정렬하거나

특정 유형의 오브젝트를 포함 또는 배제하는 옵션을 활용할 수 있다.

그림 10 - ER/Studio 팀 서버 검색 옵션

ER/Studio 팀 서버 애드-혹(Ad Hoc) 리포팅

앞에서 살펴본 것처럼 IT 부서에서 미리 만들어놓은 리포트를 사용할 수도 있지만, 비즈니스 사용자들이

원한다면, 자신들만의 리포트를 직접 거의 모든 오브젝트와 속성에 대해 만들 수 있다. 자신들의 리포트에

들어갈 정보를 원하는 대로 선택할 수 있고 보기 쉽게 그룹핑, 필터링 할 수 있다 (그림 11 - ER/Studio 팀 서버

리포팅 옵션 참조)

그림 11 - ER/Studio 팀 서버 리포팅 옵션

사용자들은 애드-혹(Ad hoc) 리포트를 재생성할 필요가 없다 - 언제든지 ER/Studio 팀 서버 홈페이지의 내

리포트(My Reports)를 통해 확인할 수 있다(그림 8 - ER/Studio 팀 서버 리포트 참조).




결론…

우리 IT 아키텍트들은 비즈니스 사용자들이 모델링 과정에 함께 참여할 수 있도록 환경을 조성하는 노력을

아끼지 말아야만 진짜 비즈니스 관점에서 가치를 가지는 설계를 할 수 있다. 우리는 우리의 모델링 노력에

비즈니스 사용자들이 참여하는 것을 방해하는 장애물들을 제거할 수 있는 해법을 찾아야 하며, 이들이 모델링

요소들에 대해 보다 자주 깊이 있게 활용할 수 있도록 장려해야 한다.

우리는 공통된 기반을 구축하고 동일한 언어로 이야기를 나누고, 안전한 환경을 제공하여서 정보의 품질과

생산성을 증진시키고 이를 통해 모두가 각자의 목표를 실현할 수 있도록 해야 한다. 결국 성공적인 사업 수행을

돕는 것이 곧 우리의 성공이다.

쉽고, 친숙하게 비즈니스 목적으로 사용할 수 있게 하는 것이 IT 와 비즈니스 간의 성공적인 협업을 이끌어내는

중요한 요소이다. 비즈니스 사용자들은 IT 의 모델링 과정에 더욱 적극적으로 협조할 것이며, 해당 책임 임원은

이러한 모델링 과정의 결과를 더욱 신뢰하게 될 것이다.

저자에 관하여

Karen López 는 InfoAdvisors, Inc 의 수석 프로젝트 매니저이자 아키텍트입니다. 저자는 20 년간 대형 멀티 프로젝트 수행

조직을 도와주는 일을 했습니다.

InfoAdvisors는 캐나다 토론토에 위치한 데이터 관리 컨설팅 기업입니다. InfoAdvisors는 데이터 관리 이론의 응용에 강합니다.

이 기업의 철학은 비용, 이익과 고객사가 접하게 되는 기술로부터 위험을 수치화하는 것에서 시작합니다.

InfoAdvisors는 현업, 데이터 관리자, PM, 개발자와 같은 모델러가 아닌 분들을 위한 데이터 관리 이슈의 도입에 집중하는

트레이닝을 포함한 데이터 모델링 트레이닝을 제안합니다.

InfoAdvisors는 비즈니스 가치에 정보관리 자원을 도입하는 것을 도와줍니다.

더 많은 정보는 www.infoadvisors.com 에서 확인하실 수 있습니다.

엠바카데로 테크놀로지는, 1993년에 설립한 데이터베이스 툴 제작사입니다. 2008년에 볼랜드의 개발툴 부문 「CodeGear」를

합병하였습니다. 현재는 애플리케이션 개발자와 데이터베이스 기술자가 다양한 환경에서 소프트웨어 애플리케이션을 설계, 구

축, 실행하기 위한 툴을 제공하는 최대 규모의 독립계 툴 제작사입니다. 미국 기업의 총수입 랭킹 「포춘 100」중 90개 기업과

전세계 300만 이상의 고객이, 엠바카데로의 RAD Studio®, Delphi®、C++Builder® 등 개발툴 제품과 ER/Studio®、

DBArtisan®, RapidSQL®, DB PowerStudio® 등 데이터 모델링 및 DB관리 제품을 채용해, 생산성의 향상과 혁신적인 소프트웨

어 개발을 실현하고 있습니다. 엠바카데로 테크놀로지스는, 샌프란시스코에 본사를 두고, 세계 각국에 지사를 전개하고 있습니

다. 보다 자세한 내용은, http://www.devgear.co.kr를 참고하시기 바랍니다.

http://www.infoadvisors.com/

http://www.devgear.co.kr/

데이터아키텍트가 비즈니스 업무 부서와 협업하기 위해 알아야 할...

Technology