태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

아래 그림은 데이터 아키텍트가 해야 할 일에 대한 프레임웍입니다. 프레임웍(Framework)이란 전체가 어떻게 구성됐는지를 보여주는 논리적인 틀입니다.



데이터 아키텍트가 해야 할 일은 크게 표준, 구조, 품질 영역으로 구분할 수 있습니다. 각 영역은 업무의 종류에 따라 원칙, 설계, 관리, 시스템으로 구분할 수 있습니다.

 

표준 영역은 데이터에 대한 표준화를 의미합니다. 표준 지침서가 있어야 하고, 표준 단어와 표준 용어와 같은 표준 컨텐츠가 있어야 합니다. 그리고 이런 컨텐츠를 관리하는 메타 시스템이 필요합니다.

 

구조 영역은 데이터 모델을 의미합니다. 마찬가지로 모델링 지침서가 있고, 데이터 주제 영역, 개념 모델, 논리 모델 등이 있습니다. 모델링은 표준 데이터를 이용해서 수행합니다. 모델은 저장소에 저장돼 메타 시스템과 연동되고요.

 

품질 영역은 표준과 구조, 데이터 값에 대한 품질 관리를 의미합니다. 품질을 높일 수 있는다양한 기준(지표)을 관리해서 잘못된 부분을 개선해서 표준, 구조, 값에 대한 품질을 높이기 위한 활동을 하게 됩니다. 이런 활동을 원활하게 하기 위해서는 DQ시스템을 사용하게 됩니다.

 

세로 축인 원칙과 설계, 관리, 시스템은 서로 유기적으로 엮여 있습니다. 원칙에 따라 설계를 해야 하고, 설계 결과를 시스템에 반영해야 합니다. 또한 설계된 결과물은 검토나 승인 과정이 필요하며, 지속적으로 관리돼야 합니다.

 

가로 축인 영역 또한 서로 엮여 있습니다. 데이터 표준에 맞게 데이터 구조를 설계하게 되고, 데이터 구조를 구현한 DB에 저장된 데이터 값과 표준 콘텐츠, 모델 구조 자체에 대한 품질을 높이기 위한 활동을 하게 됩니다.

 

위의 데이터 아키텍트 프레임웍은 DA가 수행해야 할 핵심 요소만을 포함시켰습니다. 데이터 아키텍트는 위에 표현된 일 외에도 많은 역할을 하게 됩니다. 이해 관계자 사이의 의견을 조율하고 DA 조직을 관리하는 일도 하게 됩니다. 데이터와 관련된 각종 이슈를 해결해야 하는 것은 당연한 업무입니다.

 

데이터와 관련된 모든 지식을 총괄하는 사람이 데이터 아키텍트며, 총괄해야 하는 지식을 간단하게 표현한 것이 위의 표입니다.



'데이터 Story > 데이터 상념(想念)' 카테고리의 다른 글

데이터에 대한 개인적인 비전  (0) 2018.06.23
데이터 아키텍트 프레임웍  (0) 2018.03.31
[worst practice 4]  (0) 2017.11.04
worst practice  (0) 2017.10.28
[worst practice 2]  (3) 2017.09.30
모델러의 상처  (0) 2017.09.25
블로그 이미지

블루퍼필

댓글을 달아 주세요


"위즈덤마인드"는 아래와 같은 업무를 수행하는 데이터 모델링 전문 업체입니다.

업계 최고의 품질을 제공해 드립니다.


문의: bluepupi@gmail.com, 010-6320-2229

무료 방문 컨설팅 가능(시간 조정 후 방문)


ㅁ 신규 모델링 구축

 

-기존 ERD의 부분 수정으로는 효과가 없을 시 전면 재구축을 목표로 신규 ERD 설계

-차세대나 고도화와 같이 화면이나 소스까지 변경 필요

-규모에 맞게 모델러가 다수 투입돼 분석/설계 기간에 설계

 

 

ㅁ 리모델링 구축

 

-기존 ERD의 부적절한 부분만을 찾아 재설계

-기존 ERD에 반영 못했던 업무가 반영될 수 있도록 재설계

-소수의 전문 모델러가 길게 수행

-유지보수하면서 반영 가능한 범위 내에서 시행

-유지보수 때보다는 소스 수정이나 데이터 이행이 더 많이 발생

-전면 재개발처럼 한꺼번에 변경하는 게 아니라 점진적으로 변경

-대대적으로 고도화할 수 없는 경우 적절

 

 

ㅁ 데이터 아키텍트(DA) 수행

 

-DA 조직을 이끄는 사람으로 데이터 전체적인 아키텍처를 설계

-표준화. 모델링, 품질, 이행. 튜닝, DBA 등의 데이터 관련 당사자가 많을 경우 반드시 필요한 사람

-작은 프로젝트에서는 표준화와 모델링을 수행하는 사람 중에 리더를 의미

 

 

ㅁ 데이터 모델링 컨설팅

 

-데이터 모델링을 검토하고 가이드하는 통합 모델러 역할

-업무 분석 설계자나 개발자가 모델 설계를 할 경우, 모델을 검증하여 검토 결과서를 작성하고 모델 변경 권유

-소수의 통합 모델러가 통합이나 정규화 위배. 주 시별자 등 핵심적인 부분만을 검토

-데이터 모델링 표준 수립하여 제시

 

 

DA(데이터 아키텍처) 컨설팅

 

-DA 조직 구축이나 DA 업무 범위에 대한 가이드

-단어, 용어 등의 표준 데이터나 ERD에 대한 진단

-ERD와 연관된 표준화나 데이터 값에 대한 진단

 

 

ERD 관리

 

-계정계/업무계 전체 ERD를 통합 관리

-신규 업무에 대해서 TOBE 모델 제시

-엔터티 무결성, 참조 무결성, 도메인 무결성 등 모델의 품질을 높이기 위해 ASIS 모델에 대한 개선 모델 제안

-최소한의 모델링 툴 라이선스로 ERD 관리 가능

 

 

ㅁ 데이터 표준 컨설팅

 

-데이터 모델링과 연관된 표준화 컨설팅 수행

-표준지침. 표준단어. 표준도메인, 표준용어 등 구축 및 가이드

 

 

ㅁ 데이터 품질 컨설팅

 

-표준단어표준도메인 등 표준 컨텐츠 품질 점검

-데이터 모델 구조 품질 점검

-데이터 값 품질 점검

 

 

ISP 컨설팅

 

-EA DA 영역에 대한 컨설팅

-주제 영역 구축, 영역별 개념 모델 설계

-데이터 관리체계 정책 수립

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

지난 글에서 모델링을 모델러가 하지 못하는 현실에 대해 썼습니다나름 전문 모델러로서 슬픈 현실이 아닐 수 없습니다. 하지만 달라질 거라 확신합니다.

 

이유는 여러 가지가 있는데요. 우선 10년 전과 비교해 지금의 환경이 낫다고 생각하기 때문입니다. 모델러를 찾는 데가 없진 않습니다. 숫자를 헤아리기 힘든 공공에서 필수인 EA 프로젝트에서도 모델러가 필요하고요. 좋아지고 있는 추세로 판단하면 앞으로도 좋아질 거 같습니다.

 

시스템의 기반 환경도 좋아졌다고 생각합니다. SI 산업이 불황이라고 하지만 시스템 없이는 기업이 존재할 수 없는 상황이라 낙관적이라고 생각합니다. 지나친 긍정일 수 있지만 지금이 시스템 선진국으로 넘어가는 과도기라는 생각이 듭니다.

 

게다가 DB도 소위 기초 체력이 튼튼해졌다고 생각하고요. 누구나 DB가 중요하다고 말하고 있습니다. 비록 엄한 비용 때문에 말과 행동이 다르긴 하지만, 어쨌든 과거에 비하면 DB에 대한 인식이 많이 바꿨습니다.

 

관계형 DB의 생명력도 의외로 끈질길 거라 생각합니다. 정규형 모델에 저장하지 않고는 데이터 품질을 보장할 방법이 없는 거 같습니다. 사실 획기적인 다른 DB가 나와도 설계는 해야 할 것입니다. 그리고 데이터 품질은 갈수록 중요해질 것입니다.

 

빅 데이터가 태풍처럼 거대한 바람을 일으켰지만, 그 저반에는 어쨌든 계정계 데이터가 자리하고 있습니다. 분석도 하지 못하고 크기만 한 영상 데이터나 음성 데이터를 앞세웠지만, 결국 수익을 창출하는 데이터는 양질의 텍스트 데이터가 될 것입니다. 빅 데이터의 환상에서 깨어나 기본으로 돌아갈 거라 생각합니다. 어쩌면 베리(Very) 빅 데이터가 나와 더 골치 아프게 만들 수도 있지만요.

 

모델링이 점점 활성화될 거라고 보는 진짜 이유는 따로 있습니다. DA의 등장입니다. 오늘 얘기 하고 싶은 건 DA(data architect)입니다.

 

현재 큰 시스템을 운영하는 곳은 DA가 있다고 생각합니다. 제가 거친 곳은 다 DA 역할을 하는 사람이 있었습니다. 차세대 개발을 한 곳이니 더 그럴 거라는 생각은 들지만, 왠만큼 큰 조직에는 DA가 있을 것입니다.

 

예전에는 DA가 모델러보다 없었습니다. 15년 전에는 못 들어봤고, 최소한 본 적은 없었으니까요. DA만 놓고 보면 세상이 바뀐 셈입니다.

 

DA의 역할은 다들 잘 아실 것입니다. 데이터와 관련된 일을 기획하거나 관리하는 사람입니다. 때론 데이터와 관련된 일을 다 직접 수행하기도 합니다. 그러고보니 예전에도 DA는 있었네요. 그 역할을 하는 DBA가 있으니까요. 그래도 지금은 꽤 체계적입니다. DA에 대한 역할은 기회가 되면 더 자세히 쓰겠습니다.

 

DA가 현재 가장 열심히 하는 분야는 표준화입니다. 표준화는 필수 과목이 됐습니다. 메이저 3사의 역할이 컸다고 생각합니다. 단순히 속성 표준화에 국한된 게 아니라 ERD 관리와도 연관되기 때문에 데이터 모델링 환경이 좋아진 것입니다. 모든 기업에 ERD가 관리된다면 모델러에게는 더 없이 좋은 환경이 될 것입니다.

 

DA 업무가 현재는 표준화에만 치중돼 있지만 표준화가 완료되면 DA가 모델링에도 관심을 가질 것입니다. 10년 전에는 활성화되지 않았던 표준화가 기본이 됐듯이 조만간 정규화도 기본이 될 것이라 생각합니다. DA의 궁극적인 역할은 데이터 품질을 높이는 것이기 때문에 모델에 관심을 가질 수밖에 없습니다. 아직은 엄두가 안 나지만요.

 

DA가 활성화된 원인에는 DAP 자격증도 큰 몫을 했습니다. 그렇게 보면, DB 분야에서 엔코아의 업적을 무시할 수 없습니다. 선구자 역할을 하신 분이 있어 여기까지 왔는데, DB인들이 더욱 투철한 직업관과 사명감을 가지고 분발했으면 좋겠습니다.

 

이 글을 읽으시는 분들은 최소한 DA에 관심이 있는 분일 거 같습니다. 저는 모델러의 전망도 밝다고 생각하지만, DA의 전망은 매우 밝다고 생각합니다. 많은 분들이 도전했으면 좋겠습니다. 쉽진 않겠지만 그리 어렵지도 않습니다. 노력이 문제죠. 결국은 또 노오력이네요.

 

대기업에서 개발 오래한 분들도 DA로의 전향에 대한 관심이 높습니다. 연령 제한도 없는 편이고 다른 인력으로 대체하기 쉽지 않죠. 조율을 해야 하기 때문에 여성에게도 좋은 직업이라 생각합니다. 실제로 현장에서 많이 활동하고 있죠. 준비 기간이 있다면 전업이 아주 어려운 것도 아닙니다.

 

모델링은 DA 업무 중에서 더 특화된 분야입니다. DA가 모델링을 모르면 안 되죠. DAP 시험도 그걸 허용치 않습니다. 하지만 DA가 직접 모델링은 못할 수도 있습니다. 분야가 넓기 때문에 특화된 일을 못하는 여건일 뿐입니다.

 

DA가 직접 모델링을 할 수 있으면 더 좋습니다. 표준화가 정착되면 다음 차례는 모델이라고 생각합니다. 실제로 모델을 관리하는 것이 DA의 주된 역할입니다. DA를 목표로 하시더라도 모델링을 직접 수행할 수 있을 정도의 스킬도 목표로 하시길 바랍니다.

 

모두 파이팅하세요.

 

'데이터 Story > 데이터 상념(想念)' 카테고리의 다른 글

모델러의 상처  (0) 2017.09.25
[worst practice 1] 잘못 설계된 모델  (1) 2017.09.24
DA 전망  (0) 2017.09.23
모델링을 수행하는 주체는?  (0) 2017.09.17
업무를 모르면 모델링을 할 수 있을까요?  (0) 2017.09.02
액셀과 사례 데이터  (1) 2017.08.26
블로그 이미지

블루퍼필

댓글을 달아 주세요

빅데이터는 지난 3~4년 동안 나의 머리 속을 어지럽게 만든 단어다.

도대체 무엇인가? 데이터를 최전방에서 다루는 DA가 어떤 역할을 할 것인가?

 

나름 DA로서 경험과 이론이 풍부하다고 자부하지만, 빅데이터에 대해서는 어떠한 방향도 비전도 떠오르지 않았다. 이는 지금도 마찬가지다. 방향이라도 안다면 한 번 파볼 수도 있는데, 그게 없으니 어떻게 할 수가 없다. 애써 외면할 뿐이었다.

 

이 책은 우연히 제목이 눈에 띄어 뽑아 읽은 책이다. 모두가 빅데이터를 찬양하는데 제목이 참신했다. 솔직히 뭔가 알고 있다는 느낌이 들었다. 자신이 없으면 이 같은 제목으로 책을 낼 수는 없을 것이었다.


빅데이터는 거품이다/김동환/페이퍼로드/2016”


 

201610월이면 최신 책이다. 1년 동안 썼다고 해도 최신 정보가 들어 있을 것이었다.

 

이젠 빅데이터 열풍이 멈출 때가 된 것인가? 기대를 가지고 읽기 시작했는데, 2시간 정도에 다 읽었다. 두껍지 않았고 저자의 주장이 명확하기 때문에 쉽게 읽을 수 있었다.

 

몇 가지 인상적인 부분에 대해서 언급하려 한다.

 

우선 학자의 종류를 말한다. 모르면서 아는 척하는 학자와 알면서 모르는 척하는 학자를 언급했다. 전자에 대한 얘기는 진부한 얘기라고 생각한다. 학자뿐만 아니라 많은 사람이 잘 모르면서 잘 아는 척을 한다. 모르면 모른다고 하는 사람이 드는 게 현실이다.

 

후자가 신선했다. 알면서 모른 척하는 학자란다. 제목만 읽고도 이해가 됐다. 내가 가끔 취하는 형태다. 겸손이라고 생각하기도 했지만 때로는 회피하려는 의도에서 그런 자세를 취한다.

 

학자가 이런 자세를 취한다면 어떻게 될까를 생각했다. 진실을 외면하는 것이란 생각이 들었다. 진실이 무엇인지 쉽게 알 수 없을 수도 있다. 따라서 부조리를 외면하는 학자에 대해 비판만 할 수 없을 것이다. 하지만 작은 이득 때문에 분명한 사실을 외면하는 학자라면 학자다운 학자라고 할 수 없을 것이다.

 

저자는 빅데이터에 관계된 학자가 알면서 모른 척하고 있다고 주장한다. 자신에게 이득이 되기 때문에 빅데이터가 거품이라는 사실을 언급하지 않는다는 것이다. 충분히 그럴 수 있다고 생각한다. IT 세계를 어느 정도 아는 나의 입장에서도 그렇게 볼 수 있다.

 

사실 빅데이터의 거품, 최소한 애매함에 대해서는 주변에서 수없이 들었지만 책이나 기사 등에서 유사한 주장을 하는 경우는 못 봤다. 많은 전문가들은 거품이라는 것을 알고 있는지, 최대한 오래 거품이 지속되기 원하는 것인지 궁금했다.

 

DA 입장에서 빅데이터가 다른 점은 데이터의 유형이다. 크기만 가지고 빅데이터를 언급한다면 DBMS 자체도 이미 거대한 데이터를 가지고 있기 때문에 적절치 않다. 빅데이터에는 DBMS에서 처리할 수 없는 비정형 데이터가 많다는 것이 가장 다른 점이다.

 

영상, 음성, 이미지를 포함한 비정형 데이터 중에도 SNS에서 생산된 텍스트가 빅데이터에서 거론되는 핵심 데이터다. 영상 데이터는 분석이 불가능하다고 언급하면서 결국 문자만 분석 가능한데, 이는 가십(gossip) 분석에 그칠 수 있다고 한다.

 

SNS 텍스트 데이터를 분석하는 것은 중요할 수 있다. 성과가 있는 분야가 있을 것 같기도 하다. 하지만 빅데이터가 단지 SNS에서 주고받은 문자를 분석하는 것이라면 저자의 주장대로 빅데이터는 거품이 맞다.

 

저자의 주장대로 방대한 SNS의 문자보다 게시판의 불만사항만 검토해도 충분하다. 건의사항만 제대로 처리해도 될 것이다. 빅데이터가 아니라 스몰데이터를 평소에 꾸준히 관리하는 게 더 중요하다고 주장한다. 작은 민원을 정성껏 처리하는 게 더 중요하다.

 

저자의 또 다른 주장인 개인정보 공개에 대한 부작용은 충분히 예상되는 부분이다. 빅데이터가 뭔지는 잘 모르겠지만 개인이 생산해 낸 데이터를 기반으로 뭔가를 하는 것이라고 봤을 때, 사생활 침해 때문에 데이터를 확보하지 못할 수 있다.

 

업계에서는 이미 주민번호나 전화번호, 주소 등의 개인 정보가 암호화 되고 있다. 이런 민감한 정보는 말할 것도 없지만, 내가 주고받은 SNS 문자가 공개될 수 있다는 점은 분명 문제다. 나라면 유용한 예측을 하는 데 사용하더라도 공개를 원치 않을 것이다.

 

이런 문제 때문에 결국 개인적이고 방대한 데이터보다는 현재와 같이 RDB에 있는 데이터만 제대로 분석해도 되지 않을까라고 생각한다.

 

저자가 또 언급한 것은 스몰데이터 분석이 더 정확하다는 것이고, 거대한 데이터를 확보하기 어렵다는 것이다. 서비스를 하는 SNS 해당 회사가 아니라면 그 데이터를 확보하는 것은 사실상 불가능한다.

 

상관관계와 인과관계에 대한 얘기도 뭔가 의미 있어 보이는데 정확히 이해하지 못했다. 빅데이터로는 상관관계는 찾을 수 있지만 인과관계는 찾을 수 없다고 한다. 사업에서 중요한 것은 원인과 결과의 인과관계라는 것이다.

 

데이터를 최전선에서 다루는 DA의 입장에서 데이터의 소중함은 너무나 잘 알고 있다. 하지만 빅데이터도 스몰데이터로 시작한다고 생각한다. 스몰데이터가 제대로 돼 있지 않으면 빅데이터는 무용할 것이다.

 

정형 데이터를 제껴놓고 비정형 데이터에 집중한다는 것은 어불성설같다. RDB는 지금처럼 존재해서 그에 맞는 고품질의 데이터는 지속해서 제대로 관리해야 할 것이다. 지나친 빅데이터의 관심보다 균형잡힌 관심이 필요해 보인다.

 

고품질의 데이터를 제대로 관리하는 게 더 중요하다고 생각해서 사실 빅데이터에 많은 관심을 두지는 않았다. 정치적으로 부풀려졌든, 이익 집단에 의해 부풀려졌든 빅데이터가 대세인 것은 확실하다. 규모가 이미 무시할 수 없는 수준이 된 거 같다.

 

어딘지 잘 모르겠지만 필요한 분야가 있는 것도 확실하다. 아무리 거품이 심해도 실익이 있을 수 있다. 거품일지 아닐지 좀 더 관심을 가져야겠다.



블로그 이미지

블루퍼필

댓글을 달아 주세요

데이터 아키텍트(DA)에 대한 번역글입니다.

당연히 미국의 DA 상황인데요.

한국의 DA 역할과 매우 유사하다고 생각되는데, 기술 능력은 너무 광범위하네요.

 

그래도 빅데이터 관련 기술이 눈에 띄입니다.

현재 한국에서는 DA에게 빅데이터 관련 지식을 요구하지 않을 거 같지만 앞으로는 그렇게 될 수도 있다는 생각이 듭니다.

데이터 아키텍트의 확장판(?)인 빅데이터 아키텍트가 생길 수도 있고요.

 

원문: http://www.mastersindatascience.org/careers/data-architect/

 

--

 

데이터 아키텍트는 데이터 관리 시스템을 위한 청사진을 만든다. 데이터 아키텍트는 회사의 잠재적인 데이터 소스(내부 외부) 평가한 통합하고 중앙 집중화하며, 보호 관리하는 계획을 설계한다. 이를 통해 직원들은 적시에 적절한 장소에서 중요한 정보에 접근할 있다.

 

데이터 아키텍트의 책임

 

데이터 아키텍트는 다음을 수행할 있다.

 

- IT 경영진과 협업하여 업계 요구사항을 해결하는 데이터 전략을 수립한다.

- 아키텍처를 구현하는 필요한 데이터 목록을 구축한다.

- 데이터를 획득하기 위한 새로운 기회를 연구한다.

- 현행 데이터 관리 기술을 식별하고 평가한다.

- 데이터가 조직에서 어떻게 흐르는지에 대한 가변적인 양단간 비전을 창조한다.

- 데이터베이스 구조에 대한 데이터 모델을 개발한다.

- 데이터베이스 아키텍처 응용 프로그램(: 대규모 관계형 데이터베이스) 설계하고 문서화하며 구성하고 배포한다.

- 기술적 기능(: 확장성, 보안, 성능, 데이터 복구, 안정성 ) 통합한다.

- 데이터 정확성 접근 가능성 보장을 위한 조치를 구현한다.

- 데이터 관리 시스템의 성능을 지속적으로 모니터링, 조정 보고한다.

- 기존의 웨어하우스 구조에 새로운 시스템을 혼합시킨다.

- 데이터베이스 개발 표준을 작성하고 시행한다.

- 모든 데이터 아키텍처 산출물 절차에 대한 공동 저장소를 관리한다.

 

여러분은 데이터 아키텍트가 힘든 직업이라는 말을 듣고 놀라지 않을 것이다. 일부 기업은 데이터 모델링 기술에서 은밀하게 행동하는 데이터 아키텍트가 필요하다. 다른 기업은 데이터 웨어하우징, ETL 도구, SQL 데이터베이스 또는 데이터 관리 전문가를 원하고 있다. 대부분의 데이터 아키텍트는 비즈니스 인텔리전스 분야에서 수년간 경력을 쌓은 고위급 직원이다.

 

데이터 아키텍트 급여

 

실리콘 밸리(Silicon Valley) 있는 샌프란시스코는 데이터 아키텍트를 위한 최상의 도시 하나다. PayScale 따르면 2015 평균 급여는 144,883달러(전국 평균보다 29% 높음)였다대형 대학 보건 기관이 많은 Boston 144,883달러(23% 이상), 뉴욕은 135,467달러(20% 이상) 평균 급여다.

 

데이터 아키텍트 자격

 

- 어떤 종류의 학위가 필요한가?

 

데이터 아키텍트가 되려면 컴퓨터 과학, 컴퓨터 공학 또는 관련 분야에서 학사 학위를 취득해야 한다. 교과 과정에는 데이터 관리, 프로그래밍, 빅데이터 개발, 시스템 분석 기술 아키텍처가 포함돼야 한다. 고위직의 경우 일반적으로 석사 학위를 선호한다.

 

구직 신청의 핵심 요소는 경험일 것이다. 최고 고용주는 응시자가 어플리케이션 아키텍처, 네트워크 관리 성과 관리를 다루는 최소한 5 년을 소비했으면 한다.

 

- 어떤 종류의 기술이 필요한가?

 

기술 능력

 

l  프로그램 서버 소프트웨어(: Oracle)

l  데이터베이스 관리 시스템 소프트웨어(: Microsoft SQL Server)

l  사용자 인터페이스 및 쿼리 소프트웨어(: IBM DB2)

l  기업 애플리케이션 통합 소프트웨어(: XML)

l  개발 환경 소프트웨어

l  백업/보관 소프트웨어

l  어자일 방법론 및 ERP 구현

l  예측 모델링, NLP 및 텍스트 분석

l  데이터 모델링 도구(: ERWin, Enterprise Architect Visio)

l  데이터 마이닝

l  UML

l  ETL 도구

l  파이썬, C/C++, 자바,

l  UNIX, Linux, Solaris MS Windows

l  Hadoop NoSQL databases

l  기계 학습

l  데이터 시각화

 

언제나 그렇듯이 목록은 기술의 변화에 따라 달라질 있다.

 

비즈니스 기술

 

l  분석적 문제 해결중요한 데이터에 대한 명확한 시각으로 고차원 데이터 문제에 접근하며, 시간과 인적 자원을 최대한 활용하기 위한 올바른 접근 방식을 사용한다.

l  효과적인 의사 소통관리자, 데이터 분석가 및 관련 직원의 의견을 주의 깊게 듣고 최고의 데이터 설계를 내놓고, 비 기술적인 동료에게 복잡한 개념을 설명한다.

l  전문가 관리데이터 모델러, 데이터 엔지니어, 데이터베이스 관리자 및 후배 아키텍드 팀을 효과적으로 지휘하고 조언한다.

l  업계 지식선택한 업계의 기능 및 데이터 수집, 분석 및 활용 방식을 이해하며, 빅 데이터 개발에도 유연하게 대처한다.

 

- 자격증은 어떤가?

 

2015 현재 데이터 아키텍트에게 명시적으로 요구되는 전문가 자격증은 없다. 그러나 데이터 관리 분야의 이해 관계자(: Oracle, Microsoft, IBM ) 기술 관련 자격증은 많다. 확신이 서지 않으면 멘토와 상담하고 최신 직업 설명을 검토한 다음 어떤 약어가 시간과 돈의 가치가 있는지 결정하기 위해 2015년에 대한 Tom IT Pro Best Database 자격증과 유사한 기사를 확인하라.

 

데이터 아키텍트와 유사한 작업

 

데이터 아키텍트가 되기 위해 다양한 경로를 택할 있다. 사람들은 종종 데이터베이스 관리자(DBA) 또는 초급 프로그래머로 일하면서 시작한다. DBA 데이터 관리와 관련된 일상적인 작업(: 설치, 업그레이드, 백업 복구 ) 집중함으로써 데이터 저장 사용 방법을 이해한다.

 

아마도 아키텍트와 가장 가까운 직업은 데이터 엔지니어다. Aditya Singh 적절하게 언급한 것처럼 많은 아키텍트와 엔지니어는 동일한 기술 집합을 가지고 있지만 업무 프로파일은 다르다.

 

     아키텍트는 업무 요건 분석, 논리 모델 개발 프로시저 개발과 같은 뷰에 관심을 갖는 경향이 있다.

  엔지니어는 처음부터 데이터 관리 시스템을 설계, 구현 관리하는 건설 단계에 많이 참여할 있다.

 

데이터 아키텍트는 데이터를 분석하지 않는다. 대신 다른 사람들이 데이터를 사용할 있도록 한다. 분석가 분야에 관심이 있다면 데이터 분석가나 데이터 과학자가 되는 것을 고려할 있다.

 

데이터 아키텍트 직업 전망

 

데이터 관리와 관련된 다른 모든 직업과 마찬가지로 직업에 대한 수요가 향후 10 내에 증가할 것으로 기대할 있다. 데이터 아키텍트는 단지 1990년대부터 존재했지만, 기업들은 계속해서 그들을 찾고 있다. 이유는 빅데이터 때문이다.

과거에는 백엔드 데이터 관리 시스템을 구축하는 것이 상대적으로 간단했다. 아키텍트는 웨어하우스를 구축하고 SQL 데이터베이스에 정보를 구조화하여 통합하고 개별 부서가 데이터를 사용할 있도록 만들면 작업이 완료됐다.

 

하지만 시절은 끝났다. 정보가 시장에 흘러넘치면서 아키텍트들은 비즈니스 결정을 내리는 도움이 있는 모든 종류의 비정형 데이터(: 오디오, 비디오, 텍스트) 대한 접근을 요구하고 있다. 이로 인해 아키텍트는 새로운 기술(: Hadoop) 기존 관계형 데이터베이스와 혼합하여 비용 효율적이고 안전한 유연한 인프라를 만드는 까다로운 작업을 수행해야 한다.

 

Dip Kharod 지적한 것처럼, 빅데이터 아키텍트는 이제 스스로에게 질문해야 한다.

 

"보안 환경에서 이전에 묻지 않았던 질문에 답할 있도록 고도의 분석을 통해 엄청난 양의 데이터를 처리하면서 시기 적절한 결정을 만들도록 비즈니스의 수중에 있는 충분한 정보를 제공하는 플랫폼을 어떻게 구축하는가?


[원문]


The Life of a Data Architect

 

Data architects create blueprints for data management systems. After assessing a company’s potential data sources (internal and external), architects design a plan to integrate, centralize, protect and maintain them. This allows employees to access critical information in the right place, at the right time.

 

Data Architect Responsibilities

 

A data architect may be required to:

 

-Collaborate with IT teams and management to devise a data strategy that addresses industry requirements

-Build an inventory of data needed to implement the architecture

-Research new opportunities for data acquisition

-Identify and evaluate current data management technologies

-Create a fluid, end-to-end vision for how data will flow through an organization

-Develop data models for database structures

-Design, document, construct and deploy database architectures and applications (e.g. large relational databases)

-Integrate technical functionality (e.g. scalability, security, performance, data recovery, reliability, etc.)

-Implement measures to ensure data accuracy and accessibility

-Constantly monitor, refine and report on the performance of data management systems

-Meld new systems with existing warehouse structures

-Produce and enforce database development standards

-Maintain a corporate repository of all data architecture artifacts and procedures

 

You won’t be surprised to hear that this is a difficult job. Some companies need data architects who are ninjas in data modeling techniques; others want experts in data warehousing, ETL tools, SQL databases or data administration. Most data architects are senior-level employees with plenty of years in business intelligence under their belts.

 

Data Architect Salaries

 

Home to Silicon Valley, San Francisco tops the list of best-paying cities for data architects. Acccording to PayScale, the median pay in 2015 was $144,883 (29% above the national average). The runners up? Boston – a hotbed of large universities and healthcare entities – with a median pay of $144,883 (23% above) and New York, with a median pay of $135,467 (20% above).

 

Data Architect Qualifications

 

-What Kind of Degree Will I Need?

 

To become a data architect, you should start with a bachelor’s degree in computer science, computer engineering or a related field. Coursework should include coverage of data management, programming, big data developments, systems analysis and technology architectures. For senior positions, a master’s degree is usually preferred.

 

The key aspect of your employment application will be experience. Top employers expect job candidates to have spent at least five years dealing with application architecture, network management and performance management, if not more.

 

-What Kind of Skills Will I Need?

 

Technical Skills

 

l  Application server software (e.g. Oracle)

l  Database management system software (e.g. Microsoft SQL Server)

l  User interface and query software (e.g. IBM DB2)

l  Enterprise application integration software (e.g. XML)

l  Development environment software

l  Backup/archival software

l  Agile methodologies and ERP implementation

l  Predictive modeling, NLP and text analysis

l  Data modeling tools (e.g. ERWin, Enterprise Architect and Visio)

l  Data mining

l  UML

l  ETL tools

l  Python, C/C++ Java, Perl

l  UNIX, Linux, Solaris and MS Windows

l  Hadoop and NoSQL databases

l  Machine learning

l  Data visualization

 

As always, this list is subject to changes in technology.

 

Business Skills

 

l  Analytical Problem-Solving: Approaching high-level data challenges with a clear eye on what is important; employing the right approach/methods to make the maximum use of time and human resources.

l  Effective Communication: Carefully listening to management, data analysts and relevant staff to come up with the best data design; explaining complex concepts to non-technical colleagues.

l  Expert Management: Effectively directing and advising a team of data modelers, data engineers, database administrators and junior architects.

l  Industry Knowledge: Understanding the way your chosen industry functions and how data are collected, analyzed and utilized; maintaining flexibility in the face of big data developments.

 

-What About Certifications?

 

As of 2015, there was no expert certification explicitly dedicated to data architects. There are, however, plenty of skill-specific credentials from vendors with a stake in data management (e.g. Oracle, Microsoft, IBM, etc.). When in doubt, consult your mentors, examine recent job descriptions and check out similar articles to Tom’s IT Pro Best Database Certifications for 2015 to decide which acronyms are worth your time and money.

 

Jobs Similar to Data Architect

 

You can take a variety of paths to become a data architect. Folks often get their start working as Database Administrators (DBAs) or entry-level programmers. By concentrating on the day-to-day tasks involved with data management (e.g. installation, upgrades, back-up and recovery, etc.), DBAs gain an understanding of how data are stored and used.

 

Perhaps the closest job to an architect is a Data Engineer. As Aditya Singh aptly puts it, many architects and engineers have the same skill sets, but different work profiles:

 

·       Architects tend to be concerned with the 10,000 foot view – analyzing business needs, developing logical models and developing procedures.

·       Engineers may be more involved in the construction phase – designing, implementing and maintaining data management systems from the ground up.

 

Data architects do not analyze data. Instead, they make it available to others. If you’re interested in playing in the analyst sandbox, you could consider becoming a:

 

·       Data Analyst

·       Data Scientist

 

Data Architect Job Outlook

 

Like every other job related to data management, you can expect demand for this title to grow in the next 10 years. Although data architects have only been around since the 1990s, companies are continuing to seek them out. The reason? Big data.

 

In the past, building back-end data management systems was relatively straightforward. Architects might set up a warehouse, structure and consolidate information into an SQL database and make data available to individual departments. Job done.

 

Those days are gone. As information floods the market, analysts are demanding access to all kinds of unstructured data (e.g. audio, video, text) that could help in making business decisions. This leaves architects with the tricky task of mixing new technologies (e.g. Hadoop) with existing relational databases to create flexible infrastructures that are cost-effective and secure.

 

As Dip Kharod notes, big data architects must now ask themselves:

 

How do I build a platform that provides just enough information in the hands of the business to make timely decisions while processing a massive amount of data that allows advanced analytics to answer never-before-asked questions in a secure environment?)

 


 

블로그 이미지

블루퍼필

댓글을 달아 주세요

현재 EA 관련 프로젝트를 하고 있습니다. 관련 논문도 쓰고, 컨설팅도 여러 번 수행했지만 EA는 여전히 쉽지 않네요. 정해진 게 없어서 그럴 것입니다.

 

오늘은 EA가 무엇인지 중심 잡는 데 도움이 될만한 얘기들을 두서없이 쓰겠습니다.

 

EA는 우선 ISP와 다소 헷갈립니다.

하나는 업무(Business) 위주고 하나는 기술(Technology) 위주인데요.

 

고객측의 참여 주체가 다르다는 게 핵심일 거 같습니다.

ISP는 고객의 업무 현업이 주도적인 역할을 합니다.

반면에 EA는 고객의 IT 현업이 주도적인 역할을 하고요.

물론 핵심 주체가 분명하지 않을 때도 많습니다. 경험상 이럴수록 프로젝트가 힘들어집니다.

 

EA라는 용어를 사용하기 전의 공식 용어가 ITA(Information Technology Architecture)였는데요(ITAEA로 바뀜). 이 용어가 더 와닿습니다. Enterprise 아키텍처는 왠지 모호합니다.

 

EA 타스크는 크게 현행 아키텍처 분석과 향후 아키텍처 구축으로 나눌 수 있습니다.

개인적으로 현행 아키텍처 분석만을 수행하는 것도 좋다고 생각합니다. 이것만 제대로 있어도 위력을 발휘하기 때문인데요. 특히 DA가 그렇습니다.

 

현행 아키텍처 분석 단계에서는 상세한 수준의 현행 실체를 분석해야 합니다. 예를 들어 DA는 테이블을 분석하는 것이죠.

차세대 프로젝트에서 모델링을 하는 것과 크게 다르지 않습니다. 다만 상세화 수준이 다를뿐입니다.

어프리케이션/메뉴, ERD/테이블, 장비/소프트웨어 등 실체를 들여다보고 그대로 그리는 것이 중요합니다.

 

그리고 향후 아키텍처 구축 단계에서는 제안/개선 등 TOBE에 대한 내용이 들어갑니다.

이 제안이나 진단은 근거가 있어야 합니다.

선진사례나 원칙 등의 기준이 있고 그것과 비교해서 어떻게 해야한다는 내용이 있어야 합니다.

근거없이 결론이 나오면 안 되고, 논리의 비약이 있어도 안 됩니다.

여기에 전문가다운 통찰력(Insight)이 근거에 더해져야 합니다.

 

EA에서는 상세한 실체를 들여다보면서도 큰 틀을 유지해야 합니다.

큰 틀을 프레임웍(Framework)이라고 부르는데 DA 프레임웍는 [그림1] 같습니다.

 

요소

Standards

Structures

Interfaces

Manage-

ments

Contextual

Planner

(경영자)

데이터표준화 지침서

주제영역 정의서

업무흐름지침서

DA관리지침서

Conceptual

Owner

(책임자)

모델링지침서

DB표준화지침서

데이터참조모델

  (DRM)

개념모델

데이터흐름지침서

서비스&주제영역관계정의서

DA조직R&R

Logical

Designer

(설계자)

단어정의서

용어정의서

논리모델

업무&엔터티관계정의서

데이터공유정의서

DA프로세스

Physical

Builder

(구축자)

도메인정의서

코드정의서

물리모델

DB스키마정의서

테이블&어플리케이션 관계정의서

데이터품질

System

Enterprise Data Architecture Management System

[그림1] EDADF 프레임웍1)

 

데이터 아키텍처를 수행하려면 위와 같이 표준(Standards)과 구조(Structures), 인터페이스(Interfaces), 관리(Management)라는 큰 틀 내에서 검토해야 합니다. 상세 항목은 변할 수 있지만 어떻게 수행하는지, 어떤 산출물이 나오는지를 알면 혼란은 없을 것입니다. 큰 그림과 결과 그림을 알면 EA를 수행하기 수월합니다.

 

컨설팅 프로젝트는 다양한 참여자들의 다양한 의견 때문에 힘이 드는데 정답이 없는 것도 힘든 요소 중 하나입니다.

모델링도 정답이 없다는 점 때문에 힘들 때가 있지만 EA는 모델링보다 더 추상적이니까요.

수행하기 힘들더라도 중심을 잡고 있는 것과 그렇지 않은 것은 차이가 많이 납니다.

 

개인적으로 EA 프로젝트의 핵심은 주제영역이라고 생각합니다.

EA 프로젝트는 시스템을 구축하기 전 단계라고 볼 수 있습니다.

현행을 분석해서 방향을 정하는 것으로만 끝내기엔 부족하고 차세대 시스템 구축에 사용해야 합니다.

 

차세대 프로젝트에서 초반에 혼란을 겪는 것이 주제영역입니다. EA에서 주제영역만 명확하게 정의하면 이어지는 차세대에서 유용하게 사용할 수 있습니다.

 

그리고 주제영역을 도출하기 위해서는 개념 모델이 필요합니다. 주제영역에는 데이터 통합이 주요 관점이고 이는 개념 모델에서 보일 수 있습니다.

 

EA 프로젝트와 구축 프로젝트는 연속성이 있어야 합니다. 구축 프로젝트에서 이어서 사용할 수 있는 EA 산출물을 만드는 게 바람직합니다.

 

 

1) 김기창, “전사적 데이터 아키텍처 프레임웍에 대한 개념모델 개발”, 2007




블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 정유성 2012.10.15 17:28  댓글주소  수정/삭제  댓글쓰기

    오랜만에 들렀습니다. 새로운 프로젝트를 하고 계시나 봅니다. 작년에 EA관련 공부를 잠깐 하던 때가 생각나네요. 좋은 가을 되시고, 행복한 프로젝트 기간 되세요 ^^

    • 블루퍼필 2012.10.15 23:39 신고  댓글주소  수정/삭제

      감사합니다.

      그런데 행복한 프로젝트가 있을까요... ㅎㅎ
      좀 재밌는 프로젝트는 있지만요..

      많이 읽고 많이 생각하는 행복한 가을 되세요.

  • 허민석 2014.01.28 08:19  댓글주소  수정/삭제  댓글쓰기

    구구절절 옳은 말씀이시네요.

    일전 프로젝트시
    AS-IS EA 현행화 과정이 쉽지 않았으나,
    TO-BE 모델링, 시스템 설계시 무척 도움되었고, 또한 누락없이 잘 마무리 지었습니다.

    하여,

    말씀처럼 주제영역에 대한 중요성과
    AS-IS 현행화는 무척이나 주요한 과정이라 동의에 동의 합니다..^^

i am

일상 Story/일상 2011. 2. 13. 22:47
i am 40대에 블로그를 시작한 사람. 어쩔 수 없이...
i want 합리적 원칙주의
i wish 가난한 사람들을 위한 은행
i like 생각, 생각, 생각, 생각. 신한카드(?)


15년 동안 DA(Data Architecture) 컨설팅과 데이터 모델링을 수행했으며, 진정한 데이터 프로페셔널(Data Professional)이 되려고 노력하고 있다.
2016년 현재 재충전을 위해 뉴질랜드에서 책을 쓰고 있다.

저서: ‘프리미엄 가이드2 - 관계형 데이터 모델링 노트’
        ‘이론과 실무를 겸비한 전략서 - 관계형 데이터 모델링 프리미엄 가이드’
        ‘데이터베이스 활용을 위한 SQL Server 2000’
논문: ‘전사적 데이터 아키텍처 프레임웍에 대한 개념모델 개발’





'일상 Story > 일상' 카테고리의 다른 글

프로젝트를 마치며  (6) 2011.03.26
안나푸르나... 마차푸차레...  (2) 2011.02.28
한 번은 읽을 만한 데이터 모델링 책... ㅎㅎ  (9) 2011.02.17
진정한 프로가 되는 1만 시간의 법칙  (0) 2011.02.16
뭐든 시작해야 한다  (0) 2011.02.16
i am  (0) 2011.02.13
블로그 이미지

블루퍼필

댓글을 달아 주세요