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

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의 확장성과 유연성 및 사용의 편리함 때문에 경쟁할 수 없게 될 것이다.

중략...

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


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