DATOR


정말 데이터는 프로세스에 종속적이지 않은 것인가? Data Modeling


이전에 근무할때 한 공공기관의 프로젝트에 들어갔을때의 이야기다.

당시에 나는 DBA역할로 들어갔기 때문에 모델링에 대해 관여를 하지 않았다.

AA를 보던분과 같이 밥을 먹고 있던 도중 이런 이야기가 나왔다.

"고객이 자꾸 화면에 대한 요구사항이 바뀌어서 데이터모델링 한것이 계속 변경되서 귀찮아 죽겠어요."

프로젝트에 참여한지 얼마 안된 상태이기 때문에 뭐라 조언을 할수는 없었지만 그 요구사항이 순수 화면에 표시되는 내용인지, 아니면 관리하고자 하는 데이터가 추가되거나 변경되는 것인지를 확인할 필요가 있었다.

그래서 밥을 먹고 올라가서 고객의 요구사항과 데이터모델, 화면 디자인을 같이 확인을 해보았다.

해당 프로젝트는 데이터 모델링을 하는 사람이 존재 하지 않았고 해당 AA가 데이터 모델링까지 진행을 하였기 때문에 데이터 모델링에 업무적인 프로세스가 녹아들어 있었다.

문제의 발단은, 전에 업무가 진행되고 있던것이 아니라 담당자가 스프레드시트(엑셀)로 관리를 하고 있었는데 일반시민들에게 반응이 좋아, 새롭게 시스템을 구축하여 사용자를 늘리자는 취지였고,

그래서 BA관점에서 업무를 정리하고, 전체적인 관점에서 프로세스를 정비할 필요가 있었다. (DBA는 조언을 해줄수 있지만, 관여할수 없는 슬픈 마음을 아시는 분이 있기를...)

다시 본론으로 돌아와서, 해당 담당자의 데이터모델은 한 화면에 내용을 하나의 엔터티로 구성을 해놓은 상태였다.

한 사람이 회원을 가입하고, 자신이 원하는 서비스에 접수를 하고, 그에 대해 심사를 받고, 1차 심사, 2차 심사, 3차 심사까지 있었고, 통과가 되면, 서비스에 등록이 되서... 뭐 이렇게 가는 방식인데

엔터티를 다 따로따로 만들어 구성을 해놓으니 업무프로세스를 변경하면 데이터모델을 비롯하여 어마어마 하게 변경이 되는 것이었다.

정말 내가 하고 싶은 말은 데이터 모델은 업무 프로세스를 최대한 배제하고 만들어야 한다고 생각한다.

업무 프로세스는  데이터로 말하면 '어떻게'에 해당이 되는 부분이고 데이터는 '무엇을'에 해당이 되는 부분이다.

예를 들어 주문엔터티를 만든다고 가정하자. 주문엔터티의 명칭을 '전화주문'으로 생성을 하고 그에 맞게 모델링을 진행 한다면 이것은 프로세스를 중심적으로 만들었다고 생각을 할수도 있다.

주문을 어떻게 했는가? '전화'로 한것이다. 인터넷이나 방문하여 주문하면 따로 엔터티를 구성하거나 '전화주문' 엔터티에 넣는다면 이것은 정말 천벌을 받을 짓을 하게 되는 것이다.

행위의 주체나 행위의 대상이 되는 단계에서는 저런 오류를 범할 일이 많지는 않겠지만, 그 아래단계에 오게되면 자신도 모르게 할수도 있다.

위와 같은 것은 '어떻게'라는 것을 하나의 속성이나 코드로 관리를 해준다면 새로운 주문방식이 들어오더라도 프로세스와는 관계가 적어진다. (물론 새로운 프로세스가 생기면 모델에 영향이 절대로 없다는 것은 아니다)

그렇다면 '무엇을'의 관점에서 본다면, '상품주문'일것이다. 줄여서 '주문'이라고 생성하는 곳도 많지만 '무엇을'을 신경쓰고 한다는 가정이다.

이 엔터티를 관리하는 기관이, 업무의 본질인 즉, 고객에게 상품을 판매하는 행위를 하는 것을 계속한다면 향후에 업무 프로세스가 변경되더라도 크게 변경될 영향은 적다는 것이다.

프로세스가 변경되더라도 안에서 고객접수일자, 고객성명, 제품명, 납품희망일자 등 고객 주문프로세스에서 얻어지는 데이터는 거의 변화가 없다는 것을 보면 알수 있다.

그리고 요즘같이 세상이 '스마트' 해지는 세상에 스마트폰, TV로 들어오는 주문 프로세스는 어떻게 감당할것이며, 그렇다면 우리는 평생 일만 하다 죽을것 아닌가?

모델링을 진행하면서 이세상을 보는 관점이 우리가 무엇을 관리할것이 무엇인지, 그리고 어느정도 상세하게 관리할것인지를 중심으로 생각해본다면 조금은 더 편하게 모델링을 진행할수 있으리라고 생각된다.

 

TAG

Leave Comments


profile우리는 하나님을 믿는다. 다른 모든 것들은 데이터로 검증해야 한다. 

Recent Trackback