지난 금요일 KT DigiEco 후원의 SW 공학 스터디 포럼인 "미래의 소프트웨어공학 기술 연구회" 에서 4월 정기세미나가 열렸습니다.
주제는 "IT 시장의 태풍 SaaS"이었습니다.

제가 평소 SaaS(Software as a Service)에 많은 관심을 가지고 있었는데 미래의 소프트웨어공학 기술 연구회에서 저를 초대하여 주셔서 "소프트웨어와 서비스(Software and Service)"란 주제로 발표를 하였습니다.

발표 내용을 함께 나누고자 이렇게 글을 올립니다.

참고로 미래의 소프트웨어공학 기술 연구회가 역사는 오래되지 않았지만, 여러모로 의미있는 주제를 가지고 많은 세미나를 기획하고 있습니다. 처음 초대받아 간 자리지만, 내공이 탄탄한 좋은 분들을 많이 만나뵐 수 있어서 참 좋았습니다. 여러모로 뜻깊은 모임이기에 미래의 소프트웨어공학 기술 연구회에 회원으로 활동하기로 하였습니다. 따라서 잠깐의 홍보를 드립니다. :-)

그리고 혹시 저의 생각을 나눌 수 있는 자리가 있다면, 언제든지 연락하여 주시기 바랍니다. 부족하지만, 제가 가진 생각들을 함께 나누겠습니다. 저의 이메일 주소는 본 블로그 하단에 이미지로 있습니다. 감사합니다. :-)

제 발표 내용을 보시면서 여러모로 부족한 부분이 있을 수 있지만, "SaaS라는 애매모호한 IT 패러다임을 사용자 관점에서 어떻게 받아들어야 하는가?"에 대한 저의 생각이 담겨져 있는 발표자료입니다.

제가 말로 다 표현하지 못한 내용들을 아래에 정리하였습니다. 따라서 보시면서 천천히 요약자료를 보시면 한결 쉽게 이해되실 것 같습니다.
발표 내용은 다음과 같습니다. 약 30분정도의 발표 내용입니다. 그리 무겁지 않은 내용이기 때문에 쉽게 이해되실거라고 생각합니다.



본 발표 내용을 요약한 내용은 다음과 같습니다.

SaaS(Software as a Service)는 사용자와 공급자에게 모두 가치있는 소프트웨어 패러다임입니다.

SaaS에서 가장 중요하게 부각되었던 점은 공급자적인 가치였습니다. 특히 하나의 소프트웨어(Software based Service)를 여러 사용자(Tenant)에게 쓸 수 있는 패러다임이라고 인식되고 있습니다.

하지만, SaaS에서 가장 중요한 요소는 사용자(Tenant and User) 입니다.

따라서 현 상황에 맞는 가장 중요한 사용자적인 가치가 무었인가에 대하여 확인할 필요가 있다고 생각합니다. 이에따라 IT에서 사용자적인 가치를 가장 높였다고 말하는 Web 2.0에 대하여 생각해 보았습니다.

일반적으로 Web 2.0을 참여와 공유를 지원하는 새로운 인터넷 환경으로 인식하는 경우가 많습니다. 그렇다면 Web 2.0 이전의 세대를 Web 1.0이라고 보았을 때 Web 1.0에서는 참여와 공유가 없었을까요?

제 생각에는 Web 1.0시대에서도 참여와 공유는 계속 있어왔습니다. 그 방식이 다를 뿐이지 언제나 인터넷 환경은 참여와 공유로 이루어져 있었습니다.

따라서 Web 2.0에서 말하는 참여와 공유는 그다지 Web 2.0을 설명하는 중요한 차이점이 아닌것 같습니다. Web 2.0의 여러가지 구성 요소를 살펴보면서 저는 Web 2.0과 Web 1.0의 차이를 신뢰의 차이라고 생각하였습니다.

특히 사용자가 다른 사용자를 신뢰하는 영역이 넓어졌으며, 이러한 신뢰를 바탕으로 많은 변화가 일어나고 있다고 생각합니다. 대표적으로 Wikipedia와 Blog입니다. 알지 못하는 우리가 우리를 신뢰하지 못한다면 Wikipedia는 존재할 수 없습니다.

Wikipedia라는 사이트의 시스템이 중요한것 보다 우리가 우리를 신뢰하는 신뢰성이 증대되었기 때문에 Wikipedia가 가치있어 졌다는 것입니다. 마찬가지로 Blog도 Blog의 저자를 Blog의 독자가 신뢰하였기 때문에 Blog란 생각보다 아주 단순한 시스템이 현재 새로운 가치를 만들어 내고 있는 것입니다.

따라서 저는 현재 가장 사용자에게 가치있는 부분은 신뢰라고 생각하며, 사용자가 소프트웨어를 신뢰할 수 있는 기반이 마련되었다고 생각합니다.

즉 이러한 사용자간의 신뢰성이 확장되면서 새로운 소프트웨어 시스템들이 사용자에게 널리 사용되기 시작한 것입니다.
이러한 새로운 소프트웨어 시스템의 예가 Blog입니다. Blog는 1994년 미국의 펜실베니아 스와스모어 단과대학생 저스틴 홀이 처음 시작하였다고 말합니다. 이미 15년 전에 Blog란 소프트웨어 시스템은 존재하였습니다.

하지만 지금에 와서 Blog가 각광받고 있는 이유는 무었입니까?
제 생각에는 이전에는 Blog의 저자가 만들어내는 정보를 신뢰하지 못하였기 때문입니다. Blog의 정보를 신뢰하지 못하였기 때문에 Blog의 정보를 사람들이 참고하지 않았습니다.

지금은 많은 사용자들의 Blog의 저자의 글들을 신뢰합니다. 어찌보면 누가 쓴 글인지도 정확히 모르는 이러한 정보들을 신뢰하기 시작한다는 것입니다.

이러한 예는 무수히 많습니다.
이 모두 근간에는 신뢰라는 것이 있기 때문에 발전한 것들입니다.

따라서 저는 Web 2.0의 가장 중요한 가치를 신뢰라고 생각합니다.

이러한 흐름을 볼 때 사용자들이 다른 사용자들을, 즉 우리가 우리를 신뢰할 수 있는 가장 큰 원동력이 무었일까 고민해 보았습니다.
그 가장 큰 동기는 바로 Prosumer의 탄생입니다.

이미 1980년에 앨빈 토플러에 의하여 예측된 Prosumer는 일정 수준의 전문성을 갖춘 생산자이면서 소비자입니다. 일반적인 공급자들보다 더 좋은 생산을 해 낼 수 있는 전문적인 사람들이 탄생한 것입니다.

물론 Prosumer들은 항상 존재하였지만, 최근 Prosumer들은 대폭 늘어나고 있습니다. 특정 부분에 전문가적인 지식을 바탕으로 새로운 지식을 창조하고, 이를 나누고, 다른 정보들을 소비하는 Prosumer들을 우리는 많이 볼 수 있습니다.

대표적으로 Blog의 저자들인데요, 저 역시 Prosumer라고 볼 수 있습니다.
이러한 Prosumer들은 정보의 질을 한층 신뢰할 수 있도록 만들었습니다. 따라서 우리는 대학 교수들이나 전문 의사만이 가질 수 있었던 지식의 신뢰성을 나누어 가지게 되었습니다. 이러한 신뢰성은 계속 증대되어 우리가 우리를 신뢰할 수 있는 단계에 와 있습니다.

많은 공급자들인 이렇게 강화되는 Prosumer들의 의견을 적극 수용하기 위하여 흔히 이야기하는 얼리어답터에게 제품 출시전에 미리 제품을 공급하여 반응을 살피기도 합니다. 얼리어답터역시 Prosumer이고, 이들의 조언은 전문가적인 수준이기 때문에 가능한 것입니다.

이러한 변화는 소프트웨어 분야에도 많은 변화를 일으키고 있습니다.
예전에는 무지막지한 블루 스크린을 무작정 사용자에게 던지던 소프트웨어들이 사용자에게 어느 순간부터 신뢰를 주기 시작합니다.

점점 블루스크린을 보는 기회가 줄어들고 있으며, Google의 Gmail과 같이 Beta 버전이지만, 사용자에게 많은 효용과 신뢰를 주는 소프트웨어들이 생겨나기 시작하고 있습니다.

이러한 이면을 보면 소프트웨어를 사용자들이 점점 신뢰하기 시작하고 있다는 것을 알 수 있습니다. 사용자의 개인 정보들을 가장 많이 담고 있는 E-Mail을 아무런 꺼리낌없이 Gmail이란 E-Mail 시스템에 맡기고 있습니다.

Google이 만약 신뢰할 수 없는 곳이라면 사람들인 Gmail의 기능이 아무리 뛰어나더라도 사용하지 않을 것입니다. 왜냐하면 나의 가장 소중한 개인정보들은 신뢰할 수 없는 곳에 노출하기를 원하지 않을 것이기 때문입니다.

따라서 Google의 Gmail이 여러분들에게 주는 가장 큰 가치는 바로 소프트웨어에 대한 신뢰인 것입니다.

여러분들은 어느 순간부터 블루스크린과 에러만 뱃어내던 소프트웨어를 신뢰하기 시작하고 있습니다. 무수한 버그 투성이로 얼룩져있던 소프트웨어를 신뢰하고, Web Application이건 Stand-Alone Application이건 신뢰하기 시작하고 있습니다.

특히 Web Application에 대한 신뢰가 증대되고 있습니다. 패키지 소프트웨어의 경우 기존에 컴퓨터에 설치하여야만 그 기능이 업그레이드 되었지만, 지금은 어느 순간 동일한 기능을 제공하면서도 새로운 신뢰할 수 있는 기능을 제공하고 있기 때문입니다.

그래서 요사이에 Web Application에 대한 신뢰가 더 커지고 있는 것입니다.
이를 SaaS 관점에서 바라본다면, 사용자에게 더욱 유용한 소프트웨어를 제공하는 기술 중에 Web Application을 구축하여 제공하는 것이 더욱 좋은 방법이다라는 관점이 생길 수 있습니다. 왜냐하면 여러가지 Web Application의 장점을 사용자들이 신뢰하고 있기 때문입니다.

따라서 많은 SaaS의 정의를 보면 Web 기반으로 소프트웨어를 제공하는 기술이라고 바라봅니다.

하지만 꼭 소프트웨어가 웹 기반으로 제공되어야만 사용자에게 신뢰를 줄 수 있는 것은 아닙니다.
패키지 소프트웨어도 신뢰를 줄 수 있으며, 콘솔 게임 소프트웨어도 사용자에게 신뢰를 줄 수 있습니다. 가족 모두 모여서 즐거운 게임을 즐길 수 있다라는 새로운 가치와 신뢰를 만들어준 Nintendo Wii가 그러한 예입니다.


이러한 변화를 한번 종합하여 생각해볼 필요가 있습니다.
사용자들은 사용자간에 서로 신뢰하기 시작하였으며, 소프트웨어 역시 신뢰하기 시작하고 있습니다. 특히 소프트웨어는 이러한 신뢰를 높여줄 수 있는 기능을 제공하고 있으며, 더욱 신뢰를 높일 수 있는 기능이 필요로 합니다. 이러한 변화는 Prosumer에 의하여 더욱 가속화되고 있으며, Prosumer들은 이러한 변화에 더욱 유연하게 적응하고 있으며, 이러한 변화를 이끌고 있습니다.

이러한 변화의 시대에 맞는 소프트웨어가 필요하다는 공통의 인식이 있으며, 이렇게 사용자에게 신뢰할 수 있는 소프트웨어를 제공할 수 있다는 소프트웨어 패러다임이 생겨났습니다. 이러한 패러다임을 총칭하여 SaaS라고 불리운다고 생각합니다.

따라서 우리는 SaaS를 너무 공급자적인 관점에서 바라보지 말고 사용자적인 가치를 찾을 필요가 있습니다.
SaaS의 기존의 공급자적인 관점을 넘어서 사용자적인 정의를 저는 다음과 같이 내렸습니다.

사용자 관점에서 SaaS란 소프트웨어를 바탕으로 사용자에게 신뢰할 수 있는 서비스를 제공하는 활동이라고 생각합니다.
즉 사용자에 있어 SaaS의 기술이나 각 요소들이 중요한것이라기 보다 이제 소프트웨어를 신뢰할 수 있으며, 마치 서비스처럼 신뢰할 수 있다는 것이 중요한 변화입니다.

사용자에게 가치있는 신뢰를 제공하려면 이를 종합적으로 제공할 수 있는 플랫폼이 필요합니다.
그 플랫폼을 Service Platform이라고 생각하며, Service Platform은 다음과 같은 구성요소를 가질 수 있습니다.
Service Platform

Service Platform



여러가지 공급자적인 가치와 함께 살펴본다면 더욱 이해가 높아질 수 있지만, 이러한 변화의 중심에는 사용자들의 신뢰가 높아지고 있으며, 신뢰의 가운데 소프트웨어가 함께 한다는 것이 중요한 의미라고 생각합니다.

마지막으로 헨리포드가 가장 혁신적인 방식으로 싸게 수 많은 자동차를 만들어 냈지만, 정작 사용자에게 외면을 받은 것은 공급자가 너무 사용자에게 원하는 것을 제공하지 못하였기 때문입니다. 즉 사용자가 받고 싶은 서비스들을 이해하지 못하고, 공급자, 헨리포드 자신이 원하는 자동차를 소비자에게 강요하였기 때문에 결국 크라이슬러에게 밀리고 말았던 것입니다.

사용자는 좋은 서비스를 받고 싶어하며, 그리고 제공하는 많은 것들을 신뢰하려고 하는데, 이러한 사용자들의 요청을 묵살한다면 아무리 좋은 기술과 새로운 방식으로 소프트웨어를 만든다고 하더라도 헨리포트의 T 자동차처럼 결국 사용자의 외면을 받을 것이라고 생각합니다.

이상입니다.

휴~ 정리가 쉽지 않았습니다. :-) 물론 이전에 원고를 써 놓긴 하였는데요~ 약간 수정하였습니다.
여러분들에게 조금이나마 새로운 시각을 제공하는 발표자료였기를 기대합니다.

혹시 궁금한 점이나 부족한 점이 있다면 댓글 부탁드립니다.
감사합니다. ;-)

저작자 표시
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글  4개가 달렸습니다.
  1. 좋은 강의 고맙습니다.
    서비스는 벤더에 종속되지 말고 사용자관점으로 되어야 함과 신뢰가 밑바탕 되어야 하고 이런 신뢰가 어느정도 바탕이되어 많은 서비스가 되어야 한다.는 관점이 좋고 공감합니다.^^


    읽고 들으면서 조금 의문이 되는 부분이 있었습니다.
    일단 서비스를 제공하는데 신뢰가 가장 중요한 부분이라는 점입니다.
    하지만 지금 신뢰성 있는 서비스여서 사람들이 사용하는 것 보다는
    선택맹에 빠져 안전 불감증에 사용하고 있지 않나 생각해 봅니다.

    얼마전 카메라 렌즈를 중고시장에 팔고있는데... 동생이 깜짝놀랠 정보를 알려줬습니다.
    렌즈 구매하려는 사람의 ID를 가지고(일반적으로 다른곳에서도 같은 아이디를 사용하기에) 구글등 검색엔진에서 검색해서 그사람의 이름과 전화번호... 심지어 그 사람의 와이프가 의료사고를 당해서 의료소송을 걸고있다는 사실까지 알아내더군요...ㅡㅡ;;;
    기능을 보고 아무생각없이 서비스에 가입하고 ActiveX 설치 동의를 하는것이 일반적 사용자가 아닌가 합니다. (물론 프로슈머는 다르겠죠.)
    신뢰할 수 있는 서비스인지의 여부는 현재 SaaS가 아직 많이 활성화 되지 않고 제공되는 정보가 지엽적이여서 문제시 되고 있지 않을 뿐이라는 생각이 듭니다.
    하지만 어느순간 프로슈머들의 활동으로 인해 신뢰성 낮은 서비스는 공격을 받겠고 자연히 신뢰가 그 서비스의 성패를 좌우하게 되겠네요. (결국 장책임님과 의견을 같이하네요.^^)

    이런 신뢰성은 결국 말씀하신대로 Service Platform으로 보장받을 수 있을 것 같은데 이 플렛폼은 얼핏보기에 벤더가 제공하는 프레임워크와 비슷한 역할을 한다는 생각을 해봅니다.
    사용자가 원하는 서비스를 제공하는데 벤더의 프레임워크가 제약이 된다거나 너무 크다는 면에서 밴더 독립적인 플랫폼이 되어야 한다고 말씀하시는것으로 이해했는데 그렇다면 이 플랫폼의 주체는 어디가 될지 궁금합니다. (각 프로젝트?,각 회사?,-벤더- ,아님 표준스펙?, 방법론??)
    벤더보다 작은단위가 되었을 때 신뢰성을 어떻게 보장받을 수 있는지 (아무리 프로슈머라도 비기능 요소를 보기는 힘들지 않나 생각합니다.)
    그럼 서비스 위에 서비스가 2중 3중으로 올라가게 될 서비스는 큰 거품위에 있게되고 어느순간 다같이 무너지게 될 수도 있지 않나 생각해 봅니다.
    ex) 기본되는 서비스의 보안문제 or 서비스 중단문제
    (각 회사나, 팀에 속한 플랫폼이 신뢰하지 못한다는 것이 아니라 누구도 확신 할수 없다는것이죠..)




    ps 동영상이 외국에 있어서 그런지 자주 끊기네요.^^
  2. 와!

    꼭 들어봐야겠군요!!!
    일요일에나 들을 수 있을 듯 합니다 =ㅂ=
    당분간은 계속 바쁠 듯 해서... 쩝
    듣고 나서 다시 댓글 드릴께요 ^^
    • 네~ 보시면서 궁금하신 점이 있으시면 댓글 부탁드립니다.
      공급자적인 SaaS의 가치도 나중에 한번 같이 고민해보면 좋겠습니다.
  3. 안녕하세요 선진님
    :) 이 동영상을 저한테 좀 주셔와요.

    저희 EvaCast (http://www.EvaCast.net)에 올리려구요.
    여기 올리면 더 많은 분들이 보실수 있고, 그러니 공유 부탁드립니다.

    물론 선진님 profile과 사진도 필요해요 :)
    제발 please~~~ T_T
    http://www.devpia.com/net2/EvaCast/Lecture/?cu=view&r=148
    그럼 부탁 드리죠 :)
secret

SaaS 기반의 어플리케이션이 많은 각광을 받을 것 같습니다.

이에 따라 SaaS기반의 어플리케이션이 제공하는 서비스를 평가하는 기준이 필요한 시점입니다.

여러 가지 좋은 평가 기준들이 존재하지만 Google의 평가기준이 여러모로 좋은 관점을 제공하고 있는 것 같습니다.

아직 국내에서는 Google Apps를 많이 사용하지 않고 있지만, 알게 모르게 많은 분들이 큰 관심을 보이고 계십니다.

  

특히 소규모 기업이나 조직(비영리 조직인 동아리나 클럽 등)에서 Gmail을 자신들의 도메인과 연동시켜 사용하고 있습니다.

이에 관한 자세한 내용은 다음에 한번 다루겠습니다.

 

이처럼 SaaS 기반의 서비스들을 사용하려고 할 때 여러 가지 고민해야 할 점들이 있습니다.

이러한 점들을 모아 Google에서 "SaaS를 통한 비즈니스 및 IT 생산성 향상"이란 문서를 만들었습니다.

쉽게 질문 형식으로 정리되어 있어서 SaaS 기반의 서비스를 도입하시려고 할 때 참고하시면 좋을 듯합니다.

 

참조 1 http://www.google.com/a/help/intl/ko/security/platform.html

간단한 소개는 다음과 같습니다. 참 SaaS 기반의 어플리케이션을 구축하실 때 고려하셔야 할 점들이 매우 많습니다.

 

IT 조직에서 통신 보안 및 규정 준수 주문형 솔루션 제공업체를 평가하기 위해 고려해야 하는 5가지 주요 요소는 다음과 같습니다.

 

효율성
높은 효율성은 통신 보안 및 규정 준수 솔루션의 선정에서 가장 우선적으로 고려되어야 하는 요소입니다. IT 조직에서는 변경이 필요할 경우 이를 수행할 수 있을 뿐 아니라 변경 중에도 지속적으로 효율적인 통신 보안 및 규정 준수를 제공할 수 있는 솔루션인지 평가해야 합니다. 주문형 솔루션 제공업체에 다음과 같은 질문을 해보시기 바랍니다.

 

  1. 이메일이나 웹 등 모든 통신 채널을 통해 보안 및 규정 준수를 제공하는 플랫폼 기반 방식으로 솔루션이 구현되었습니까?
  2. 서비스 중단 없이 신속하고 간편하게 새로운 서비스나 응용 프로그램을 솔루션에 추가할 수 있습니까?
  3. 필요할 경우 간편하게 솔루션을 변경해 최신 규정 및 법적 기준을 적용할수 있습니까?
  4. 새로운 보안 위험 요소를 신속하게 파악하고 이에 따른 보호 방안을 솔루션에 채용하여 고객의 위험에 대한 노출을 최소화할 수 있습니까?
  5. 고품질의 SaaS를 안정적으로 제공할 수 있는 축적된 경험이 있습니까?

 

유연성
주문형 통신 보안 및 규정 준수 솔루션을 선정할 때에는 확장성을 지원하는지 알아보는 것이 중요합니다. 조직에서는 자신들의 구체적인 요구사항을 해결하며 기술 직원이 수익 창출에 도움이 되는 보다 가치 있는 작업을 수행하는 데 더 많은 시간을 쓸 수 있도록 편리하게 관리할 수 있는 솔루션을 찾아야 합니다. 솔루션 제공업체에 다음과 같은 질문을 해보시기 바랍니다.

  1. 이메일과 웹 상에서 유사 정책 및 이의 처리 결과는 어떻게 관리됩니까?
  2. 동일한 정책 설정을 중복해서 사용할 수 있습니까? 아니면 각 정책에 대해 별도의 프로필을 작성해야 합니까?
  3. 새로운 보안 위험 또는 규정에 따라 긴급하게 정책을 변경해야 할 때 얼마나 신속하게 변경내용을 적용할 수 있습니까? 수분이 걸립니까, 아니면 수시간이 걸립니까?
  4. 정상적인 프로세스에서 조직 내 서로 다른 부서별로 독립적인 정책 또는 규정 요구사항을 만들 수 있습니까?
  5. 메시지 추적 및 조사를 위해 얼마나 세밀한 수단을 제공합니까?

 

배포 및 사용의 용의성
통신 보안 및 규정 준수 솔루션에서 가장 중요한 기능 중 하나는 배포 및 사용의 용의성입니다. 이 두 가지 측면에서 솔루션이 어렵고 복잡할수록 보안 수준은 낮아지고 조직 내 지속적인 규정 요구사항을 준수하기가 어려워집니다. 이러한 측면에서 솔루션이 갖춰야 할 주요 요소는 다음과 같습니다.

  1. 솔루션 실행에 걸리는 시간은 얼마입니까?
  2. 솔루션을 설정하거나 정기적으로 구성을 변경할 때 어느 정도의 작업이 필요합니까?
  3. 솔루션이 전자 통신을 처리하는 데 걸리는 부하는 어느 정도입니까? 처리지연 및 보안 위험을 초래할 수 있는 디스크 저장 과정이 필요합니까? 아니면 고급 수준의 메시지 처리 프로세스를 제공합니까?
  4. 직원들이 셀프 서비스 포털을 통해 필터 적용과 같은 일반적인 업무를 직접수행할 수 있습니까? 아니면 관리자가 있어야만 수행할 수 없습니까?
  5. 솔루션을 사용하는 데 필요한 데이터 용량은 얼마나 됩니까?
  6. 솔루션 실행 및 관리에 하드웨어 및 인력자원이 별도로 필요합니까?

 

총소유비용(TCO)
통신 보안 및 규정 준수 솔루션의 초기 투자 비용은 빙산의 일각인 경우가 많습니다. 조직에서는 초기 투자 비용 및 추가 관리 비용이 낮은 주문형 솔루션을 선정할 수 있도록 정밀한 조사를 실시해야 합니다. 솔루션 제공업체에 다음과 같은 질문을 해보시기 바랍니다.

  1. 솔루션을 배포하는 데 소요되는 기간은 얼마입니까?
  2. 솔루션을 배포하는 데 필요한 리소스는 무엇이 있습니까?
  3. 업체에서 솔루션 구현을 관리합니까? 아니면 기업에서 전문가를 고용해야합니까?
  4. 솔루션을 구현하는 데 추가 하드웨어, 소프트웨어 또는 기타 리소스에 대한 추가 자본 투자가 필요합니까?
  5. 솔루션 초기 투자 비용은 얼마입니까? 향후 관리 비용이 추가로 필요합니까?

이 외의 자세한 내용은 "SaaS를 통한 비즈니스 및 IT 생산성 향상" 에서 확인하세요~

 

신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글이 없습니다.
secret
개발자의 관점에서 SaaS란 무었인가에 대한 많은 생각들을 하였습니다.

사실 SaaS에 대한 많은 정의와 내용들이 존재하지만 개발자에게는 쉽게 다가오지 않는 것이 사실입니다.
어떤 면에서는 SaaS처럼 혜성처럼 나타나는 많은 IT의 패러다임 자체가 개발자에게는 부담일 수 있습니다. SaaS라는 이야기가 구체화되어 갈수록 SaaS에 대한 정확한 정의가 개발자의 관점에서 부족한 것이 사실입니다.

나름대로 오랜기간 SaaS에 대하여 고민하여온 저에게도 SaaS는 애매모호한 부분이 많습니다. 똑같은 예가 Web 2.0인데요 대강의 개념은 알지만 개발자 관점에서 정확하고 구체적인 내역을 한마디로 정의하기에는 너무도 어려운 용어입니다.

저는 이러한 문제 자체가 IT 패러다임 자체에 문제가 있다고 생각합니다.

IT 패러다임의 문제

1946년 진공관을 사용한 최초의 컴퓨터인 애니악(ENIAC)을 컴퓨터의 기원으로 본다면, 우리가 종사하는 전산은 50여년의 역사를 가진 학문이라고 볼 수 있습니다.

하지만 경제학의 기원이라고 볼 수 있는 경우 애덤 스미스(Adam Smith)의 국부론(An Inquiry into the Nature and Causes of the Wealth of Nations)은 1776년에 나왔으며, 이에 따라 경제학은 200년 넘는 역사를 가진 학문이라고 볼 수 있습니다.

애덤 스미스가 국부론에서 “보이지 않는 손(invisible hand)”이란 아주 애매모호한 용어를 사용했을 당시만 하더라도 아마도 많은 사람들이 “보이지 않는 손”이란 새로운 경제 용어에 대하여 명확하게 이해할 수 없었을 것입니다. 지금에 와서는 고등학교 교과서에서도 나오는 이 유명한 “보이지 않는 손”은 경제 주체간의 모든 이해가 자연적으로 조화를 이루어 수요와 공급을 유지시켜 시장가격을 결정한다는 의미로 이해되고 있습니다.

이는 궁극적으로 애덤 스미스의 “보이지 않는 손”이란 새로운 패러다임이 오랜 역사를 거쳐 일반적인 상식으로 발전한 것입니다.

하지만 전산의 경우 역사가 짧고 변화의 속도가 매우 빠르므로 새로운 패러다임이 출현한 뒤 철저하게 검증되거나 발전할 시간자체가 부족합니다.
따라서 현재 새롭게 출현하고 있는 IT 패러다임과 이를 한마디로 요약할 수 있는 각 용어에 대한 명확한 정의와 구체적인 내용이 빈약한 것이 사실입니다. 따라서 각 IT 패러다임을 개발자나 기타 IT 종사자들이 한 번에 이해한다는 것은 무척이나 어려운 일입니다.

사실 2004년 Web 2.0이란 용어를 오라일리미디어사(O’reilly Media, Inc.,)의 대표인 팀 오라일리(Tim O’reilly)가 말했을 때에도 그 개념을 정확하게 이해하기 힘들었습니다. 현재는 2년 여간의 시간을 통하여 많은 사람들에게 Web 2.0이란 용어가 참여와 공유를 중시하는 웹이란 의미로 받아들여지고 있으며, 구체적인 실체로서는 블로그(Blog)나 위키(Wiki)가 있고 AJAX(Asynchronous JavaScript and XML)나 매쉬업(Mashup)을 통하여 서비스를 공유시키고 사용자의 참여를 유도할 수 있는 개발방안이 일반화되고 있습니다.

즉 팀 오라일리가 Web 2.0이란 새로운 용어를 만들었을 당시만 해도 구체적이지 않았던 Web 2.0 패러다임이 시간이 지날수록 구체화되고 일반화되면서 점점 상식으로 받아들여가고 있다는 것입니다. 결국 IT 패러다임도 다른 분야의 패러다임과 마찬가지로 구체화되고 일반화되어야 하는 시간이 필요합니다.

하지만 IT 패러다임의 문제는 IT의 변화속도가 워낙 빠르기 때문에 구체화되거나 일반화되는 시간동안 새로운 패러다임이 출현한다는 문제입니다. 이로 인하여 많은 IT 개발자들이 패러다임을 인식할 수 있는 시간이 부족하게 되고 이를 구체적인 기술로 인식하기전에 벌써 새로운 기술이나 트렌드를 맞이하게 되는 악순환이 벌어지고 있습니다.

또한 IT를 주도하고 있는 마이크로소프트나 IBM 등의 대형 벤더에서 각 IT 패러다임을 자신에게 유리하게 해석하고 이를 구체화할 수 있는 방안을 홍보하여 IT 종사자들에게 혼란을 야기하고 있습니다. 대표적인 예가 SOA(Service Oriented Architecture)인데 각 대형 벤더가 서로 자신에게 유리한 부분을 부각하여 SOA를 재해석하고 이를 개발자에게 전달함으로써 개발자들이 정확하게 SOA의 가치와 의미를 파악하기 힘들게 되었습니다.


IT 패러다임을 이해하는 안목

Web 2.0이나 SOA 및 SaaS(Software as a Service)와 같은 새로운 패러다임에는 근본적으로 사용자들의 요구가 반영되어 있습니다. 블로그의 경우 팀 오라일리가 Web 2.0이란 용어를 말한 2004년보다 훨씬 앞선 1994년 미국의 펜실베니아 스와스모어 단과대학생 저스틴 홀이 처음 만들었습니다. 물론 블로그의 기원은 보는 시각에 따라 약간씩 다를 수 있지만 궁극적으로 웹상에서 참여와 공유를 위한 흐름은 훨씬 이전부터 있었던 일이며, 이를 단지 Web 2.0이란 용어로 정리가 되었을 뿐입니다.



개발자의 눈으로 바라보는 SaaS

이러한 관점에서 SaaS를 바라본다면 어떤일이 일어날까요? 과연 SaaS라는 개념은 혜성처럼 나타난 새로운 패러다임일까요?

 2001년 9월 21일 전자신문에서는 “포스트SW-SW 사지 말고 웹서비스 이용하세요”라는 기사를 통하여 현재 화두인 SaaS와 같은 내용을 포스트 소프트웨어 모델로 제시하고 있습니다.

“웹서비스(web services)가 소프트웨어(SW) 산업의 지형을 바꾸는 포스트 모델로 떠오르고 있다. 웹서비스는 단말기 종류에 구애받지 않고 언제 어디서나 웹에 접속해 최적화, 개인화된 서비스를 구현한다는 개념으로 기존 SW산업 질서를 재편하는 혁신적인 내용을 담고 있다.

웹서비스가 일반화되면 각 단말기별로 필요한 SW를 구매, 설치할 필요 없이 언제 어디서나 어떤 장비에서도 일관된 내용의 웹서비스를 받을 수 있게 된다. 따라서 ‘판매-구매’라는 단선적인 사이클을 가진 상품으로서의 SW는 사라지고 ‘상시 제공-수시 이용’의 순환체인을 갖는 서비스로서의 SW모델만이 남게 돼 기존 SW산업 시스템에 일대 변화가 일어나는 것이다.”

놀랍게도 현재의 SaaS와 같은 내용이 단지 포스트 소프트웨어 모델이란 이름으로 2001년도에 기사로 나왔었습니다. 이를 주관적으로 판단해본다면 현재의 SaaS에 관한 논의는 이전부터 존재한 것이며 현재 부각되고 있는 이유는 SaaS와 같은 소프트웨어 유통방식이 일반 사용자에게도 충분히 받아들여질 수 있는 상황이 되었다고 필자는 생각합니다. 전자신문의 기사에서는 소프트웨어가 웹 서비스로 제공될 때의 변화에 대하여서도 예리하게 지적하고 있습니다.

“웹서비스 모델은 기업의 인프라스트럭처를 표준기술에 기반한 플랫폼으로 바꾸는 작업에서부터 SW구매 및 판매방식에 대한 새로운 정책을 수립하는 문제에 이르기까지 광범위한 변화를 요구하고 있다.

이에 따라 기존 시장의 질서나 업체간판도가 웹서비스에서 재편될 가능성을 내포하고 있다. 우선 SW유통 모델이 바뀌는 만큼 SW를 판매하고 설치하는 기존 오프라인 공급업체들의 입지가 줄어든다. 따라서 마케팅이나 프로모션 방식에도 큰 변화가 일어날 것이다. 또 웹서비스가 일반화되면 그 동안 이기종 시스템간 연동을 위해 사용된 게이트웨이, 커넥터 등 많은 중개(brokerage) 기술이 다른 형태로 모습을 바꾸게 될 것이다.

뿐만아니라 어떤 개발언어, 어떤 툴을 쓰느냐의 문제는 점점 중요하지 않게 되는 반면 플랫폼이나 아키텍처, 프레임워크 기술의 중요성은 더욱 부각될 것이다. 또 열린 웹상에서의 서비스이므로 보안문제가 더욱 중요한 사안으로 등장할 전망이다.

이와 함께 SW컴포넌트가 가속화할 것이다. 서비스 모델은 수시로 업그레이드되고 최적화돼야하기 때문에 컴포넌트가 아니면 시장 즉시성(time-to-market)을 구현하기 힘들기 때문이다. 이에 따라 SW업계의 재편이 점쳐진다. 웹서비스를 효과적으로 지원하는 솔루션 벤더는 영향력을 유지하겠지만 그렇지 않은 업체는 힘들어진다.”

SaaS란 해성과 같은 패러다임도 알고 보니 예전부터 존재하는 개념이며, SaaS가 확산될 때의 변화에 대하여서도 정확하게 예측하였습니다.


IT 패러다임을 바라보는 안목

사용자 삽입 이미지

SaaS 처럼 새로운 IT 패러다임을 이해할때 필자는 "주관을 통한 가치파악"을 꼭 해보시길 권해드립니다. 남들이 좋다고해서 벤더가 이끈다고해서 개발자인 저희들이 맹목적으로 따라갈 필요는 없다고 봅니다.

개발자인 우리들은 IT 패러다임을 재해석하고 IT 패러다임에 필요한 IT 기술을 필요에 따라 습득한다면 SaaS와 같은 새로운 IT 패러다임이 나타난다고 하더라도 충분히 이해할 수 있을 것이라고 생각합니다.

여기서 가장 중요한 것이 주관입니다. 자신의 주관을 바탕으로 가치를 파악한다면 수없이 많은 새로운 패러다임중에 옥석을 골라 정말 필요한 것들만 취하실 수 있을 것입니다.

이것이 개발자의 눈으로 바라본 SaaS입니다.



SaaS에 대하여 많은 기술적인 부분들이 존재하지만 제가 개발자인 관계로 개발자의 입장에서 SaaS와 같은 새로운 패러다임을 어떻게 볼것이며 어떻게 대처하여야 할 것인가에 대한 고민을 하던 중 이와 같이 정리하였습니다.

본 자료는 마이크로소프트웨어(http://www.imaso.co.kr) 에 2008년 4월에 특집기사로 기고한 내용을 바탕으로 정리한 것입니다.

특히 많은 개발자분들에게 SaaS와 새로운 패러다임을 어떻게 바라볼 것인가에 초점을 맞추어 쓴 글입니다. 부족하지만 많은 개발자분들에게 조금이나마 도움이 되길 기원합니다. 아울러 마소에 기고한 글을 첨부합니다.


감사합니다.






신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글  4개가 달렸습니다.
  1. 좋은글 잘 보고 갑니다 :)
  2. 매우좋아요.. 2008.08.08 08:19 신고
    매우 잘 정리된 글
    잘 보고 갑니다.... 이올린에 추천 한방 날립니다.. ~~ ㅎㅎ
secret
최근 Peter Laird씨가 작성한 클라우드 컴퓨팅/SaaS/PaaS 시장의 이해(Understanding the Cloud Computing/SaaS/PaaS markets: a Map of the Players in the Industry) 라는 글을 읽었습니다.

최근 크게 이슈가 되고 있는 클라우드 컴퓨팅 및 SaaS와 PaaS 시장에 대한 이해를 할 수 있는 매우 좋은 자료였습니다. 이에따라 공유 차원에서 간략한 정리를 올립니다.

클라우드 컴퓨팅(Cloud Computing)

클라우디 컴퓨팅은 데이터 센터의 가상화를 지원합니다. 개인적으로 서버 장비를 가지지 않고 큰 규모의 서버 장비를 모아놓은 후 이를 원하는 만큼 사용하는 개념입니다. 클라우드 컴퓨팅 솔루션은 일반적으로 사용하는 어플리케이션을 실제 서버 장비에 배포할 필요가 없도록 지원합니다.일부에서는 이러한 것을 “hardware as a service”라고도 부릅니다.


Software as a Service(SaaS)

일반적으로 SaaS 모델을 통하여 어플리케이션을 제공하는 것을 의미합니다. SaaS 모델의 공통적인 특성은 다음과 같습니다.
  • 인터넷을 통하여 제공됩니다.
  • 제3자에 의하여 원격에서 제공됩니다. (remote)
  • 사용한 만큼 비용을 지불하는 모델을 가지고 있습니다. (usage-based)

Platform as a Service(PaaS)

벤더들이 플랫폼을 서비스처럼 제공할때 빌드, 테스트, 커스텀 어플리케이션의 배포를 지원하는 통합된 플랫폼을 PaaS라고 합니다. PaaS는 당신에거 SaaS 모델(remote, usage-based)을 제공합니다. Dion Hinchliffe 가 최근 발행한 comprehensive whitepaper에 이러한 내용이 포함되어 있습니다.


Core Cloud Services

3가지 시장에 대한 정의 후에도 기본적인 빌딩 블록(fundamental building blocks)와 같이 기초가 되는 솔루션들이 남아 있습니다. 이러한 솔루션들은 cross cutting concerns을 지원합니다.

The Visual Map

사용자 삽입 이미지




솔루션 그룹들의 정의

Left Side

Cloud Providers - vendors who provide server hardware in commodity form, as a virtualized cloud

Cloud Deployment - solutions surrounding the deployment of applications to a virtualized cloud

Virtual Appliances - packaging and virtualization format solutions for provisioning applications into a cloud

Topology Management - solutions focused on the coordination of many virtual appliances (app, DB, network) in the cloud to form a full deployment

Billing, Contract Management - solutions that provide metering, billing, pricing, and contract management to help charge for use of a system

Security - solutions focused on solving security requirements in these markets

Data - services that deliver/retain data for applications

Hosters 2.0 - Hosting Service Providers with SaaS focus. Perhaps a controversial grouping and impossible to define, these hosters tend to appear over and over in these markets

Nerd Stuff - geeky topics fall into this category. MapReduce is mechanism for solving large computing tasks, like Google Search indexing

Right Side

On Demand Apps - the heart of the SaaS market, only a few depicted here but we could add "...and a cast of thousands". These are the end application products offered for consumption in a SaaS model

Integration as a Service - service solutions that help in integrating multiple systems, possibly multiple SaaS systems

Content as a Service - hosted content repositories

BPM and Workflow - service based offerings for managing workflow and process

Platform as a Service - incarnations of the PaaS concept



솔루션 리스트의 참고자료


Cloud Computing,
   SaaS, and PaaS
       Industries
             2008




신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글이 없습니다.
secret
2004년도에 Cordys란 회사에서 새로운 어플리케이션 슈트(APS)를 출시하였을때 Gartner에서 쓴 분석자료입니다.

제가 현재 서비스 플랫폼이란 SaaS와 SOA 및 Web 2.0을 지원하는 플랫폼을 구축하고 있기에 Gartner 의 분석자료를 보았습니다.

현재 Cordys는 BPM을 중심으로 슈트를 발전시켜나가는 것 같습니다.

SaaS를 가능하게 하는 플랫폼에 관심있으신 분들을 참고세요.


cordys_application_platform__124070.pdf

Cordys' Application Platform Suite Makes Intriguing Entrance







신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글이 없습니다.
secret
오늘 게임 아카데미 뉴스레터에서 GPU 프로그래밍의 발전방(http://cyber.gameacademy.or.kr/letter/200807/sub_02.html)에 관한 글을 읽었다. 아직 안읽어 보신분들은 읽어보기를 권한다.

NVIDIA의 CUDA에 대항하는 Intel의 Larrabee에 대한 간결한 설명이 인상적이었다. 일부 내용을 설명하면 다음과 같다.

사용자 삽입 이미지

쉽게 Intel의 CPU은 초간지 건담 RX-78이다. 초간지이기때문에 예상대로 무지 비싸다. GPU의 경우 초저렴 짐(RGM-79)이다. 무지싸다.

간결한 설명이다. Intel의 경우 라리비를 발표하면서 NDIVIA의 GPU를 이용항 CUDA에 병렬처리분야에 딴지를 걸겠다는 의미이다.

사용자 삽입 이미지

이것이 CPU대 GPU의 차이이다. GPU의 경우 CPU보다 상당히 처렴한 Cache 메모리를 이용하여 ALU를 많이 사용함으로써 병렬처리능력을 확보하였다.


사용자 삽입 이미지

요것이 검담의 대결이다. 초간지 검담 RX-78 32대와 초저렴 간담 RGM-79 128대와 만약 싸운다면 누가이길까?

난 초저렴 건담인 RGM-79에 한표 던진다. 왜냐하면 초간지 건담과 싸워서 몇대 완전피 파괴되어도 저렴하므로 더 생산해서 싸우게 하면된다.

특히 수적으로는 4대 1의 싸움인데 아무리 잘 싸우는 초간지 검담이라고 하더라도 인해절술로 밀어붙인다면 승산이 있다.

즉 Intel의 라라비보다는 NVIDIA의 CUDA가 더욱 승산이 크다는 것이다.

CUDA의 경우 다음과 같은 아키텍처를 가지고 있다.

사용자 삽입 이미지


CUDA의 아키텍처는 그렇다고 하여도 CUDA를 이용하여 GPU활용한 병렬처리가 얼마나 높은 성능을 낼 수 있는지 잘 모르시는 분들도 계실것이다.

지금 GPU 기반 퍼스널 슈퍼컴퓨팅 시대 '초읽기'(http://www.zdnet.co.kr/news/digital/0,39030978,39171258,00.htm) 란 기사를 읽어보기를 권한다.

GPU를 활용하여 슈퍼컴퓨터를 만들어 활용하는 예가 나온다.

슈퍼 컴퓨터 말로만 듣던 슈퍼컴퓨터를 NVIDIA의 CUDA를 통하여 쉽고 값싸게 구현할 수 있다면 어떤 일이 벌어질까?

웹 상에서 어려웠던 각종 멀티미디어 처리가 쉽게 이루어 질 것이다. 웹의 한계로 여겨졌던 그래픽 처리를 웹 브라우져 안에서 아주 손쉽게 할 수 있을 것이다. 마치 웹 상에서 구동되는 포토샵이라고 할까?

단지 멀티미디어 처리분야만 발전할까?

SaaS 기반의 어플리케이션의 경우에도 많은 영향을 받을 것 같다. 특히 SaaS는 Single-Instance를 기본으로하기떄문에 GPU를 통하여 높은 컴퓨팅 능력을 부여하여 준다면 단일한 머신안에서 최대의 Tenant들을 처리할 수 있을 것이다.

또한 클라우드 컴퓨팅에 많은 영향을 미칠 것 같다.

요사이 클라우드 컴퓨팅이 중요한 화두인데 상대적으로 저렴해진 하드웨어들을 이용하여 원하는 만큼의 컴퓨팅 능력(연산 능력)과 저장공간을 즉시 사용할 수 있도록 제공하는 컴퓨팅 환경에 대한 개념이다.

많은 웹 기반의 어플리케이션들이 Amazon의 Amazon EC2에서 호스팅되고 있다. 저렴한 비용에 원하는 만큼의 즉시 사용할 수 있는 클라우드 컴퓨팅 환경을 제공한다. 이때문에 많은 벤처 및 중소 IT 업체에서 Amazon EC2를 활용하여 Web 기반의 Application들을 제작하고 있다.

만약 아마존에서 NVIDIA의 CUDA를 이용한 컴퓨팅환경을 제공해준다면 어떤 일이 벌어질까?

아마도 더욱 저렴하게 수준높은 컴퓨팅 능력을 구매하여 웹 상에서 구현되기 어려웠던 어플리케이션들이 빠르게 처리될 것이다.

여러분의 컴퓨터에서 동작하는 Microsoft Excel보다 웹상에서 동작하는 Google Docs의 Spreadsheet가 더 빠르게 동작할 수 도 있는 것이다. 물론 네트웍환경때문에 쉽지 않겠지만 컴퓨팅 능력 만큼은 데스크탑 컴퓨터보다 훨씬 빠를 것이다.

이것이 GPU기반의 병렬처리프로세싱의 미래가 아닐까 예상해본다.
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글 하나 달렸습니다.
  1. 쿠다크라우드 2009.11.03 01:08 신고
    흥미롭게 읽었습니다. 최근에 들어서야 CUDA나 클라우드 컴퓨팅에 대해 듣게 되어서 서핑하다가 여기까지 오게 되었네요.
    확실히 쿠다와 구름이 만나면 무시무시할 거 같네요.
secret
Gartner에서 나온 Introducing SaaS-Enabled Application Platforms: Features, Roles and Futures 란 글을 읽었습니다.

SaaS를 지향하는 어플리케이션을 개발하길 원하는 분들에게 좋은 글인것 같아서 공유차원에서 올립니다.
특히 SaaS기반의 어플리케이션을 지원하는 플랫폼을 구축하길 원하는 분들에게 강력 추천 드립니다.

아래은  Introducing SaaS-Enabled Application Platforms: Features, Roles and Futures 에 대한 정리입니다. 혹 정리가 부족한 부분이 있으면 언제든지 저에게 알려주시기 바랍니다.


SaaS를 가능하게 하는 어플리케이션 플랫폼에 대한 소개: 기능, 역활 그리고 미래

14 August 2007

Yefim V. Natis

Gartner RAS Core Research Note G00150447

SaaS(Software-as-a-service) 스타일과 같은 비즈니스 어플리케이션의 수와 영역이 확장되고 있으며, 새로운 SaaS가 가능할 수 있는 어플리케이션 플랫폼은 산업의 확산과 벤더들간에 플랫폼의 핵심을 장악하기위한 리더쉽을 잡기위한 전쟁터에서 새로운 순환을 시작하고 있다.

개요

현재 SaaS와 같은 소프트웨어에 특화된 벤더들은 상대적으로 작으며 플랫폼과 어플리케이션을 이끌고 있는 벤더들은 아직 SaaS에 대하여 고객에게 제안할 수 있는 준비를 완벽하게 끝내지 못하였다. 그리고 대다수의 주요 사용자들을 위한 SaaS 스타일의 어플리케이션 솔루션들은 작은 시장에 집중하고 있으며 아직 실험중이다.

그럼에도 불구하고 우리는 지금 엔터프라이즈 IT 부문들은 비즈니스 경험을 바탕으로 SaaS의 확산을 증진하기 위한 계획을 세우기 시작하였다.


핵심사항
  • SaaS는 엔터프라이즈 IT의 일정영역에서 잘 수립된 현상이다. SaaS는 소프트웨어 기반의 비즈니스 솔루션의 중요한 선택사항으로 성장해갈 것이며 몇몇 주요 엔터프라이즈 IT 부문에 3년정도 안에 많은 영향을 미칠 것이다.
  • SaaS 모델은 다중의 비즈니스와 기술형태인데 중요 기업들은 SaaS 모델을 명확하게 할 것이다.
  • 엔터프라이즈 소프트웨어 벤더들은 아직 SaaS 어플리케이션 스타일을 지원하는 베스트 프랙틱스를 수립하지 못하고 있으며, 또한 산업 표준들을 적용하지 못하고 있다.
  • 표준 기반의 어플리케이션 서버들과 같은 전통적인 기술 플랫폼은 충분하게 단순한 SaaS 활용을 지원하지만 진보되거나 현재의 영역폭이 넓은(broad-based) SaaS의 제공은 다가올 미래에서는 특별하거나 확장된 SaaS가 가능한 어플리케이션 플랫폼에 의존할 것이다.
  • 다음 3년안에 대부분의 주요 고객들은 혼합된 SaaS IT 환경과 SaaS를 사용하지 않는 IT 환경에 대한 베스트 프랙틱스와 같이 잘 알려진 SaaS를 지원하는 소프트웨어 모델과 SaaS를 지원하지 않은 소프트웨어 모델간의 트레이드 오프(trade-offs)에 대한 이해의 필요성에 대하여 직면하게 될 것이다.

권고
  • 여러분들의 현재 활용하고 있는 비즈니스 어플리케이션, 소프트웨어 인프라스트럭처와 개발 툴의 공급자의 SaaS와 연관된 비즈니스와 기술 계획을 이해하여야 한다. 이와 같이 새로운 소프트웨어 제품과 벤더들의 평가시에 SaaS에 연관된 질문들이 포함되어야 한다. SaaS 스타일의 비즈니스 소프트웨어 솔루션을 위한 정보를 주거나 신뢰할만한 비즈니스 위치와 계획을 가지고 있는 벤더들을 선호하여야 한다.
  • 차츰 SaaS 스타일의 소프트웨어 솔루션들을 엔터프라이즈 소프트웨어의 옵션으로 지원할 수 있도록 추가할 계획을 세워야 한다. 그러나 계획만 세우지 말아라. 대부분의 경우 다음 5년안에 SaaS 기반의 어플리케이션 소프트웨어로 완전히 이주할 것이다. 따라서 SaaS를 지원하는 비즈니스 소프트웨어 솔루션들과 지원하지 않은 솔루션들이 공전하는 환경을 준비하여야 한다.
  • 미래의 프로젝트들을 위하여 SaaS와 SaaS가 아닌 소프트웨어 솔루션들의 선택할 수 있는 선호도를 위한 가이드라인을 만들어야 한다.
  • 기업 내부에 몇몇 비즈니스 소프트웨어를 위한 "내적인 SaaS" 모드 설립을 위한 기회에 대하여 설명하여야 한다.

목차

분석

1.0
   
Definition
2.0
   
Roles and Responsibilities in SaaS Environments

2.1
   
One Vendor Plays All Providing Roles (Application Provider, Platform Supplier and Host)
2.2
   
Platform as a Service (PaaS)
2.3
   
Internal SaaS
2.4
   
Personal SaaS
3.0
   
Functional Characteristics of a SaaS-Enabled Application Platform
4.0
   
Leading Vendors

4.1
   
Salesforce.com Apex Platform
4.2
   
Cordys Application Platform
4.3
   
Oracle Fusion Middleware
4.4
   
SAP (Future)
4.5
   
Microsoft (Future)
5.0
   
Future of SaaS-Enabled Application Platforms
6.0
   
Bottom Line


표 목차
<테이블 1> Functional Characteristics of a SaaS-Enabled Application Platform

그림 목차
<그림 1> Roles and Responsibilities in a SaaS Application Environment




분석

SaaS는 IT 업계에서 성장하고 있는 현장이다. 현재 중요 기업들이 활용할 수 있도록 진출을 준비중이다. 패키지 어플리케이션을 이끌고 있는 벤더들은 오랜기간동안 그들의 소프트웨어 솔루션들을 고객에게 SaaS 방식으로 전달할 수 있도록 헌신하여 왔다.
플랫폼 기술 벤더들은 그들의 어플리케이션 플랫폼들(개발 프레임웍들과 툴 및 미들웨어)의 기술 내용을 SaaS 스타일의 어플리케이션 이용을 위한 요구사항들을 지원하기위한 관점에서 재평가하였다.
현재, SaaS를 이끌고 있는 특별한 벤데들은 상대적으로 작으며  플랫폼과 어플리케이션을 이끌고 있는 벤더들은 SaaS에 대한 제안을 할 수 있는 준비가 아직 안되어 있다. 그리고 대다수의 중요한 사용자들을 위한 SaaS 스타일의 어플리케이션 솔루션들은 작은 시장에 집중되어 있고 다른 부분들은 실험중이다.
그럼에도 불구하고 우리는 지금이 엔터프라이즈 IT 부분들이 그들의 비지니스 경험안에서 확산되고 성장하는 SaaS를 위한 계획을 세우기 시작하여야 한다고 믿는다.

비즈니스 어플리케이션들의 SaaS 모델화는 새롭운 것이 아니다. 사실상 Gartnet("Dataquest Insight: SaaS Demand Set to Outpace Enterprise Application Software Market Growth" 참조)에 따르면  SaaS 어플리케이션 솔류션들은 2006년 40억달러의 시장수입을 거두었다.
Salesforce.com이나 NetSuite, Ceridian이나 많은 다른 회사들은 그들의 완벽한 SaaS 스타일의 어플리케이션 제공으로 폭넓은 성공을 거두었다.
대부분의 현재 배포되고 있는 SaaS 어플리케이션들은 그 회사만의 기술들로 구축되었는데 그 이유는 일반적은 목적의 어플리케이션 서버들이나 플랫폼들은 SaaS의 요구사항을 충족시킬 수 없었기 때문이다.
최근에 WebEX(현재는 Sisco), Cordys, Salesforce.com, Oracle, Micorsoft와 같은 벤더들은 SaaS를 위하여 재사용할 수 있는 플랫폼 기술들을 제공하기 시작하였다.
오늘날 가장 주목할만한 것은 Apex Code를 포함하여 최근에 잘 알려진 Apex 플랫폼("Salesforce.com Challenges Conventional Thinking With Web Application Platform" 참조)이다.

이러한 일을 하는 대부분의 벤터들의 목적은 새로운 ISVs의 생태계를 위한 기반을 마련하는 것이다. Independent Software Vendors (ISVs)는 작은 어플리케이션 벤더들로 제3자의 플랫폼위에서 SaaS 스타일의 소프트웨어를 개발하여 드라마틱하게 들어가는 비용을 절감한다.
플랫폼 벤더들은 거대한 생태계를 따르는 추종기업들과 함께 시장을 이끌어가며 공유한다.
벤더들은 다른 비즈니스 모델을 추적하고 ISV가 판매하는 제품을 위한 플랫폼을 제공하고, ISV들이 신청한 서비스들은 호스트하거나 벤더의 어플리케이션이나 파트너의 어플리케이션을 위한 기술들이 가능하도록 한다.
플랫폼 벤더들과 어플리케어션 벤더들 사이에 SaaS를 가능하도록하는 경기는 시작되었으며, 사용자들은 반드시 그들이 제시하난 옵션들에 대한 상관관계를 이해하여야 한다. 언제 전용 플랫폼들이 일반적인 목적을 가지는 플랫폼들에 비하여 이득을 제공할 수 있는지? 그들을 통하여 어플리케이션을 운영하였을때 무었이 플랫폼의 기능인지? 플랫폼의 기능들 중 무었이 활용을 위한 패턴들인지? 어떻게 ISV들이 플랫폼을 선택하는지와 어떻게 선택한 ISV 어플리케이션들이 사용자들 등록하는지?
이러한 질문들의 답은 SaaS가 가능한 어플리케이션 플랫폼의 본질과 다른 능력을 이해하면 할 수 있다.

플랫폼 미들웨어는 메인프레임 시절(CICS, IMS)에서부터 비즈니스 어플리케이션을 위한 기술들이 가능하도록 하였다. 어플리케이션 플랫폼들은 어플리케이션의 스타일 변화를 지원하고 각 시기에 맞는 우세한 어플리케이션 스타일(분산 컴퓨팅 [Tuxedo, DCE], 분산 객체 [CORBA, DCOM], 분산 컴포넌트 [Java EE, .NET])을 지원한다.

새로운 어플리케이션 패턴이 나타난것과 같이 새로운 기술들도 함께 나타났다.

대부분의 새로운 기술들은 이벤트드리븐 어플리케이션 플랫폼(Java Service Logic Execution Environment [JSLEE])과 SaaS를 가능하도록 하는 플랫폼(SaaS-enabled application platforms; SEAPs)를 포함한다.

사용자들은 변화하는 시기에 잘 구성된 이전세대의 플랫폼 기술을 사용하거나 경쟁력을 얻을 수 있을것 같은 진보적인 특별한 기술로 도약합니다. 이러한 시도가 SaaS 스타일의 소프트웨어 솔루션들에 적용됩니다.

새로운 방법을 통하여 SaaS 스타일의 어플리케이션들은 최저화된 SEAPs를 통하여 더욱 탄력적이고 더욱 생산적이며 더욱 빠르다는 것을 증명할 것입니다. 하지만 현재 지배적은 분산 컴포넌트 플랫폼(기업 내부에서 디자인되어 사용되고 있는)은 잘 구성되어 있으며 엔터프라이즈 관련 기술 구매자들에게 매력적인 요소들을 가진 높은 표준을 가지고 있으며, 잘 이해된다.

본 조사의 목적은 SaaS 스타일의 어플리케이션을 위한 새로운 플랫폼의 기술적 차이점을 확인하는데 있다.


1.0 정의

다음과 같은 특성("Evaluating Software-as-a-Service Providers: Questions to Ask Potential SaaS Providers" 참조)을 가지고 있을때 소프트웨어를 SaaS 또는 소프트웨어 온 디멘드(software on-demand)라고 칭한다.
  • 상대적으로 사용자의 밖에서 배포되고 관리되는 소프트웨어
  • 사용자이 조직이 관리하지않고 다른 사람이 소유하는 소프트웨어
  • 소프트웨어를 사용한만큼 지불한다.
  • 소프트웨어를 독립된 다양한 사용자 조직에 의하여 공유된다.(하나의 소프트웨어 인스턴스를 많은 입주자(Tenant)들이 사용한다.)
여기서 주목하여야 할 것은 SaaS는 application as a service와 정확히 같지 않다는 것이다.

"어플리케이션(Application)"은 사용자를 위하여 처음과 끝을 위한 완벽함을 포함하여야 하고 거기에는 반듯이 사용자 인터페이스(UI), 비즈니스 로직, 데이터 엑서스 모듈 그리고 종종 조직의 안과 밖에 있는 다른 어플리케이션의 외부 리소스에 대한 접근등을 할 수 잇어야 한다.
대다수의 새로운 어플리케이션은 이러한 점들을 혼합하여 구성되어 있다. 많은 어플리케이션은 기업 내부의 리소스와 SaaS 스타일의 리소스를 조합하고 있다.

구성에 대한 논의는 SaaS와 SaaS가 아닌 리소스에 대한 내용을 포함하는데 본 조사의 범위가 아니다. 하지만 소프트웨어 요소들은 다양한 본질들을 구성하여 조합되는 어플리케이션은 반드시 아주 뛰어난 단일한 특성을 가지게 된다.

또한 다양한 사용자(Tenant)에 의하여 공유되는 소프트웨어는 다양한 형태를 가져야 한다. ("How to Evaluate SaaS Architecture Model Choices" 참조)


2.0 SaaS 환경의 역활과 책임

다음은 <그림 1>의 SaaS 시나리오에 있는 5가지 중요한 역활을 하는 참여자에 대한 설명이다.
  • SaaS 플랫폼 공급자: 개발하고 플랫폼 기술의 지적인 특성(intellectual property)을 소유하고 어플리케이션에 대한 문제를 근본적으로 해결한다.
  • SaaS 어플리케이션 제공자: 개발하고 어플리케이션 소프트웨어의 지적인 특성을 소유한다.
  • SaaS 호스트: 많은 어플리케이션 제공자들과 어플리케이션들을 위하여 호스트하고 어플리케이션 소프트웨어를 관리하고 많은 사용자 조직(Tenant)의 플랫롬 기술을 관리하며
  • 사용자 조직(Tenant): 어플리케이션 공급자와 계약하고 어플리케이션 소프트웨어의 독립된 가상 인스턴스를 제공한다.
  • 사용자: 일반적으로 사용자 조직의 직원이거나 고객으로 어플리케이션 소프트웨어를 실제로 사용하는 독립체이다.

<그림 1> SaaS 어플리케이션 환경안에서 역활과 책임
사용자 삽입 이미지


이러한 역활들은 몇몇 시나리오에서 명확하게 나타나지 않았을 것이다.



2.1 모든 역활(어플리케이션 제공자, 플랫폼 제공자 그리고 호스트)을 하는 벤더

대부분의 경우 SaaS 어플리케이션들은 하나의 특정한 플랫폼위에서 개발되며, SaaS 플랫폼 공급자와 호스트와 어플리케잇녀 제공자는 모두 하나의 단체이다. 이러한 경우 일반적으로 플랫폼은 표준적이지 않으며 제품화되어 있지 않다. 우리는 2012년이 지나면 특정 플랫폼은 사라져가며 제품화되어 있고 표준화되어 있는 플랫폼으로 트랜드가 변화할 것이라고 믿는다.

이것은 현재 존재하는 표준 플랫폼(JavaEE와 같은)을 확장하여 가능할 수 도 있고 규격화 되어 가면서 만들어져 갈 수도 있고 최소 코드로 작성되는 Apex 코드와 같이 SaaS에 특화된 새로운 프로그래밍 모델을 통하여 가능할 수 있다.

플랫폼 벤더들은 SaaS 시장에 진입하는 것이 목적이며 SaaS 어플리케이션 제공자는 플랫폼 벤더들의 주변 파트너로서 생태계를 만들어가는 것이 목적이다. 둘다 프로그래밍이 가능한 SEAPs의 경쟁자로 성장해가며 이끌어 갈 것이다.

예: Salesforce.com's SFA


2.2 Platform as a Service (PaaS)

플랫폼을 제공하고 호스트하는 단체가 하고 어플리케이션 제공자가 다른 같은 경우의 SaaS 제공을 PaaS라고 한다. PaaS는 어플리케이션 개발과 배포를 위한 플랫폼으로서 ISV들이 그들의 어플리케이션들을 플랫폼위에 구축할 수 있는 서비스를 제공하며 어플리케이션 제공자는 사용자 조직(Tenant)를 위하여 순차적으로 활동할 것이다.

예: ForeSoft's dbFLEX


2.3 내부 SaaS(Internel SaaS)

어플리케이션 제공자가 아마도 사용자 조직의 부서이며, 제3자가 고객에게 서비스를 제공하듯이 다른 부서에 서비스를 제공한다.
기술적인 관점에서는 이러한 내부 SaaS는 SaaS를 부정하는 정의인데 그 이유는 조직이나 사용자의 밖에서 어플리케이션이 호스트되어야 하기 때문이다.
우리는 "내부 SaaS"가 채택되어 성장할 것으로 보는데 전통적인 SaaS와 완전히 라는 변동성이 비지니스 본질상 존재하기 때문이다. 더욱이 기술적으로는 내부 SaaS는 SaaS 모델에 속한다.


2.4 개인 SaaS(Personal SaaS)

일부 시나리오에서는 개운 사용자가 사용자 조직없이 직접 공급자와 계약을 맺는다. 이 경우를 개인 SaaS라고 부른다. 사용자는 로컬에서 솔루션을 배포할 수 있으며 외부 사이트에서 사용할 솔루션을 선택한다.

SaaS 제공자에 의하여 엔터프라이즈 어플리케이션들이 호스트될때 엔터프라이즈 형태의 SaaS인것처럼 SaaS 제공자에의하여 개인 어플리케이션들이 호스트될때 개인적인 형태의 SaaS이다.

개인 SaaS는 본 조사의 범위에서 벗어나므로 더이상 언급하지 않겠다.

예: Google's Docs & Spreadsheets


예외가 있음에도 불구하고 SaaS의 기능을 이해하는데 5단계의 역활(Role) 모델을 적용하는 것이 항상 유용하다. 전통적인 on-premise 모델에서는 사용자의 조직과 드물게 적용된 1대다로 호스팅된 곳에서 대부분의 SaaS 역활을 수행한다. (비록 지역이나 부서에 의하여 데이터가 분할된다고 하더라도 같다.)

SaaS 모델에서 5가지 단계의 다중 관계는 SaaS 기술과 비즈니스 요구사항에 중대한 영향을 미친다.



3.0 SaaS가 가능한 어플리케이션 플랫폼의 기능적인 특성들(Functional Characteristics of a SaaS-Enabled Application Platform)

SaaS의 요구사항들을 정의하면서 제공자들은 반드시 적합한 플랫폼 기술들을 사용하여야 한다. JavaEE로 구현되었거나 .NET 어플리케이션 플랫폼으로 구현된 일반적인 목적의 어플리케이션들은 단순하거나 격리된 Tenancy 모델의 배포를 사용하여 SaaS 시나리오의 요구사항을 만족시킬 수 있다. ("How to Evaluate SaaS Architecture Model Choices" 참조)

여기서 각 사용자 조직들은 각 조직의 시스템 인스턴스나 물리적으로 격리되어 각 조직에 의하여 호스팅되는 각 인스턴스를 가지고 있다. 그러나 새로운 사용자 조직을 추가하는 것은 비용적이나 추가의 복잡성이나 지원이나 스케일을 높이는 것은 매우 어렵다.

대부분의 사용자 조직은 전략적으로 소프트웨어를 SaaS 모델화하고 있는데 비록 아직까지 SaaS를 가능하게하고 다중 사용자(multitenancy)를 지원하는 어플리케이션 플랫폼들의 표준이 없다고 하더라도 자사의 플랫폼 디자인을 신뢰하고 있다. 일부 사용자 조직들은 더욱이 1대다 모델 SaaS 모델에서 신뢰의 결함을 노출된 후 완벽한 격리화를 보장하기 위하여 격리된 Tenacy를 선택하고 있다.

SEAP의 기능은 멀티태넌시(multitenancy)로 정의된다. 플랫폼에서 멀티태넌시는 개별 사용자가 (사용자 조직들, Tenant들)이 자신의 결정에 의하여 설정되어 표현되는 기능이다. 따라서 사실상 컴퓨터의 리소스들을 분할하여야 하며 플랫폼과 어플리케이션 코드들을 동시에 접속하는 다중 Tenant를 단일 인스턴스(single instance)에서 지우너하여야 한다.

멀티태넌시는 많은수의 사용자나 Tenant를 위하여 컴퓨팅 리소스들의 사용을 높은 수준에서 최적화할 수 있어야 한다. 그러나 Tenant의 사용시 신뢰할 수 있고 안전하게 격리하여 로직의 독립을 제공하는 것은 무척 어려운 도전과제이다.

SaaS 스타일의 행위들은 일반적인 어플리케이션 플랫폼(격리된 Tenancy에 의한 SaaS, 또는 가상화 또는 다이나믹 그리드를 이용한 확장성 제공)들을 사용하여 제공할 수 있다. 그래서 멀티태넌시가 SaaS의 요구사항이 아니지만 SaaS가 가능하도록 하는 어플리케이션 플랫폼을 위한 요구사항이다.

<테이블 1>에서 언급된 SaaS 플랫폼의 상세한 기능들이 나열되어 있다. <테이블 1>을 활용하여 당신에게 맞는 우선순위와 상황에 맞게 SaaS 플랫폼의 평가할 할 수 있다. 이것은 SEAP을 사용하기 위한 최소한의 요구사항은 아니지만 요구되는 능력의 나열이다. 대부분의 벤더들은 몇개의 요소들은 제공하고 있지만 모두다 제공하지 못하고 있으며, 대부분의 사용자들은 몇몇 요구사항을 가지고 있지만 모두다는 아니다.

<테이블 1> SaaS가 가능한 어플리케이션 플랫폼의 기능적 특성
특성
상세내용
Multitenancy
 
  • Tenant 지향(Tenant-aware)의 어플리케이션 서버(프로세스 컨테이너) 리소스 공유, 우선순위, 최적화 그리고 격리화
프로세스들은 다중 사용자(Tenant)화의 실행을 통한 이익을 위하여 공유된 메모리와 프로세스 공간안에서 실행되어야 하지만 보여지는 메모리, 프로세스상태, 메타데이타 설정, 성능의 변동 그리고 Tenant간 잘못된 에러의 발생 처리등은 Tenant별로 격리되어 보호받아야 한다.
Tenant는 service-level agreement (SLA)와 게약 그리고 다른 외부변수들에 위하여 우선순위를 보호받아야 한다.
  • Tenant 지향의 데이타 공간의 공유와 격리
어플리케이션 플랫폼은 데이타 저장소에 의하여 분리된 기술 레이어를 가지고 있다. 데이타 레이어의 기능은 멀티내넌트를 보장하도록 설계되어야 한다. (Tenant간에 보여지는 데이타의 격리)
각 Tenant별로 데이타 저장 인스턴스가 분리되어 데이터 저장소에 접근되거나 일반적인 데이타 저장소를 모든 Tenant별로 나누어야 한다.
데이터 레벨의 멀티태넌시(Multitenancy)는 자동적으로 데이타 저장소에 의하여 구현되거나 플랫폼에 의하여 자동적으로 구현되거나 어플리케이션에 의하여 설계되어 구분되어야 한다.
잘 디자인된 멀티태넌트 어플리케이션 플랫폼은 모든 옵션을 지원하며 최소한 하나의 요구사항은 지원한다.
  • Tenant 지향의 백엔드 데이타 관리
데이타베이스는 더 이상 한명의 사용자를 위하여 존재하지 않기 때문에 어느 시점으로 데이타를 복구하여야 할지 정할 수 없다.
데이타 백업 및 복구, 장애 복구, 롤백, 롤포워드, 진단, 임포트/익스포트 그리고 다른 데이타베이스 관리자(DBA) 지향의 백엔드 데이타베이스 프로세스는 반드시 엄격하게 Tenant 지향적이어야 한다.
  • 일정한 간격을 둔 Tenant 지향의 호스팅
Tenant의 어플리케이션 데이타 또는 비즈니스 로직은 반드시 다른 Tenant로 부터 보호받아야 한다는 의미이며 호스트로부터도 마찬가지이다. 호스트 제공자는 어플리케이션의 전체 동작을 지원하여야 한다. 하지만 주제넘는 지원은 안된다.
단지 Tenant에게 호스트 DBA나 다른 호스트의 Tenant의 비즈니스 데이타에 접근할 수 있는 직원에 대한 인증을 담당하여야 한다.
단지 어플리케이션 제공자는 어플리케이션의 코드와 비즈니스 로직에 대하여 접근할 수 있다.
  • Tenant 지향의 보안, 모니터링, 리포팅, 관리
Tenant와 연관된 사용자는 Tenant 밖에 있는 리소스들에 대하여 보여지는 것을 막아야하며 각 Tenant별 격리된 모니터링과 독립된 관리 인자와 정책을 제공받아야 한다.
  • Tenant 커스터마이징
Adjustments to application user interface, service interfaces, process flows, policies, data objects, rule frameworks and SLAs that apply to an individual tenant, without preventing that tenant's virtual rendition of the application to run in a shared real resource environment.
어플리케이션의 사용자 인터페이스(UI), 서비스 인터페이스, 프로세스 흐름, 정책, 데이타 객체, 룰 프레임웍 그리고 SLA의 조정은 공유되는 실제 리소스 환경안에서 실행되는 어플리케이션의 Tenant별로적용되어야 한다.
  • Tenant안의 사용자에 대한 부가적인 개인화
개별 Tenant에포함된 사용자에게 개인화 기능의 지원되어야 한다.
  • Tenant지향의 개발 툴과 메타데이타 지원
개발 툴, 메타데이타 사용과 런타임 엔진은  특정한 SaaS 동작을 설계하는 어플리케이션 개발자에게 복잡도와 비용을 감소시켜준다. 특히 작은 ISV에게 좋다.
  • Tenant on- and off-ramping (that is, "provisioning")
Optimized process to create a new tenant (or remove a tenant) at low cost, time to completion and complexity.
  • User on- and off-ramping (that is, "provisioning")
Optimized process to register (or remove) a new user within a tenant at low cost, time to completion and complexity.
  • Application on- and off-ramping and version control (that is, "rolling updates")
Optimized process to deploy (or remove) a new application at low cost, time to completion and complexity; also includes the ability to substitute versions or run multiple versions of the application simultaneously for different tenants.
  • Subtenancy
Ability to create "tenants within tenants" so a customer of an application provider (a tenant) can turn around and contract with its own customers and provide a level of multitenant isolation for these customers (subtenants) under the umbrella of the customizations of the "supertenant."
Fine-grained usage tracking and metrics
SaaS application tenants pay to application providers in some proportion of usage (in part because the traditional per-CPU pricing is impossible because all tenants share the common pool of CPUs, and in part because it fits best with the logic of the SaaS model). The SEAP must, thus, have the ability to register fine-grained usage metrics per users and per tenant and control the visibility of this information to both the relevant tenants only and to the SaaS application provider and the host as a whole.
XTP-style high scalability
A successful SaaS host might have to support thousands of tenants with hundreds of thousands of customers each. Ability to support the dynamics and demands of a mature multitenant environment will require high and, in some cases, extraordinary levels of availability, scalability, performance, reliability and consistency in the underlying platform. Extreme transaction processing (XTP) capabilities will be essential for addressing this challenge over time (see "Extreme Transaction Processing: Technologies to Watch")
Integration with other on- and off-premise resources
The whole environment of an enterprise will not be SaaS — the ability of the SaaS-style application to participate in composite applications and to also access resources outside of its own scope is essential for the majority of user enterprises. The integration technology, essential for composition of multiapplication and multienterprise (business-to-business [B2B]) applications, may itself be SaaS (in this case, referred to as "IaaS" — integration as a service; see "Taxonomy and Definitions for the Multienterprise/B2B Infrastructure Market").
Support for dual use
Most ISVs developing an application using a SEAP would value the ability to offer the same application on-premise as well, depending on the user enterprise requirements.
Internationalization
A SaaS-style application will likely have user organizations operating in different geographies, so the application must be able to be localized per tenant and possibly per user. To support this form of personalization and customization, the platform overall must have support of internationalization (a coexistence of multiple na
Source: Gartner (August 2007)



4.0 선도하는 벤더들

대부분의 어플리케이션과 플랫폼의 벤더들은 SaaS 모델을 지원하기위한 준비중이거나 제공중이다.

중략...




4.1 Salesforce.com Apex Platform

Apex 플랫폼은 의견이 없는 가장 진보적인 SEAP이다.

중략...






4.2 Cordys Application Platform

Cordy는 서비스 지향 아키텍쳐(SOA) 스타일의 프로젝트를 지원하는 어플리케이션 플랫폼을 제공하며, XML 기반의 Java 어플리케이션 서버와 서비스 관리 환경(SOA Grid), 비지니스 프로세스 관리자, 룰 엔진 그리고 XForms 또는 AJAX 기반의 사용자 인터페이스 프레임웍을 포함하고 있다.

중략...





4.3 Oracle Fusion Middleware

Oracle Fusion 미들웨어는 Tenant 프로파일에 대한 개념을 포함하는데 메타데이타 객체의 프로파일링을 에스팩트(aspect)로 한다. 프로파링은 Java를 기반으로 자기기술이 가능하며 SQL과 다른 어플리케이션 프로그래밍 인터페이스(API) 그리고 Oracle 개발 툴을 재조합하였다. 그래서 Fusion 개발자는 멀티태넌트 스타일의 어플리케이션을 개발할수 있는 여건을 갖추었다.

중략...




4.4 SAP (Future)

SAP은 중간 사이즈의 엔터프라이즈를 위한 차기 어플리케이션의 슈트(now code-named A1S)는 SaaS를 제공할 수 있도록 계회되어있으며 NetWeaver(now referred to as v.7.1)의 차기 버전에 의하여 가능할 것이다.

중략...





4.5 Microsoft (Future)

Microsoft의 현재 CRM Live v.3은 격리된 Tenancy 접근을 SaaS 배포에 지원한다. 차기 버전(code-named Titan)은 현재 베타이며 수백여개의 ISV가 참여하고 있으며 SaaS의 멀티태넌트를 지원할 것이다.


중략...



5.0 Future of SaaS-Enabled Application Platforms

우리는 다음 24개월안에 SaaS를 위한 프로그래밍 가능한 플랫폼들의 수가 많이 증가할 것이라고 예상한다.

중략...

우리는 SaaS 스타일로 어플리케이션 배포 및 솔루션 제공자의 계약이 지속적으로 증가할 것으로 믿는다.

중략...


6.0 Bottom Line

단순한 SaaS 지원은 현존하는 표준 플랫폼을 이용하여 격리된 Tenancy 모델을 지원할 수 있지만 새로 등장하는 SEAP의 확장성과 유연성 및 사용의 편리함 때문에 경쟁할 수 없게 될 것이다.

중략...

어플리케이션을 받쳐주는 플랫폼은 어플리케이션들의 확장성과 유연성 및 비용에 영향을 미치는 중요한 예언자이다.


긴 글을 마지막까지 읽어주신 독자님께 감사드린다. 글을 쉽게 이해할 수 있도록 일부 의역을 하였다. 만약 잘못된 부분이 있다면 꼭 알려주시길 부탁드린다.
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글이 없습니다.
secret