비전 정의

메리 커틀랜드
Microsoft Corporation

2001년 1월 10일

지난 주 칼럼에서는 웹 서비스 지침 팀과 Microsoft의 사명인 웹 서비스 빌드, 배포 및 운영 샘플을 소개하여 동일한 작업을 수행할 때 고려해야 하는 문제의 종류를 설명했습니다. 또한 첫 번째 샘플 프로젝트인 즐겨찾기 서비스를 소개했습니다.

여러분의 의견과 피드백을 보내주신 모든 분들께 감사드립니다. 우리는 당신이 제기 한 문제를 추적하고 있습니다, 그래서 그들을 오고 계속!

누군가가 샘플을 릴리스하는 데 3 개월이 걸리는 이유와 아이디어를 발표하기 전에 시작하지 않은 이유를 물었습니다. 사실, 우리는 지난 두 달 동안 거의 풀 타임 즐겨 찾기에 작업하고있다. 기능의 많은, 잘, 작동... 그러나 모든 것이 자신의 컴퓨터에 설치하거나 인터넷을 통해 시도 할 수있는 샘플에 멋지고 깔끔한 패키지되기 전에 해야 할 일이 여전히 있습니다. 또한 샘플 원본과 함께 제공하려는 모든 문서를 작성, 기술 검토, 편집 및 처리하는 데 시간이 걸립니다. 그래서 우리는 3개월의 프로젝트 주기를 목표로 하고 있습니다. 우리는 우리가 2 월에 언젠가 즐겨 찾기의 첫 번째 릴리스를 얻을 수있을 것입니다 우리의 손가락을 교차 유지. (이 내용을 작성할 때 팀은 릴리스 날짜를 더 잘 예측하기 위해 일정 연습을 진행합니다.)

일부 주석에서는 .NET Framework 사용하여 이 샘플을 개발하고 있다고 가정합니다. 반드시 그런 것은 아닙니다. 우리는 우리가 작업에 가장 좋다고 생각하는 모든 기술을 사용할 것입니다. 그리고 가장 좋은 것은 항상 기술적으로 우수, 사용하기 쉬운, 또는 뉴스에서 대부분을 의미하지 않는다. 어떤 것을 선택하든 이유를 알려 드리겠습니다. 사용하려고 할 때 어떤 문제가 발생했는지 알려드리겠습니다.

이번 주에는 즐겨찾기 서비스를 빌드하는 동안 팀에서 발생한 문제를 살펴보겠습니다. 백로그는 꽤 있지만, 처음에는 프로젝트의 목표와 목표 파악부터 시작하겠습니다.

시작하기

Microsoft 솔루션 프레임워크 프로세스 모델에서 프로젝트의 첫 번째 단계는 구상 단계입니다. 구상 단계에서 프로젝트 팀과 고객은 프로젝트의 목표 및 제약 조건에 대한 개략적인 보기를 만듭니다. 이 단계의 기본 결과물은 비즈니스 문제 분석, 제품 목표 설명, 솔루션 개념의 개요, 제품 사용자 프로필, 디자인 목표 및 프로젝트 scope 정의를 포함하는 비전 문서입니다. 구상 단계는 비전/scope 승인된 이정표에서 절정을 이룬다.

우리 팀은 비정상적인 시작점부터 시작했습니다. 웹 서비스를 작성하고 싶다는 것을 알았지만 특정 문제 도메인을 염두에 두지 않았고, 사용해야 하는 기존 애플리케이션도 없었습니다. 따라서 가장 먼저 해야 할 일은 확장 가능하고 신뢰할 수 있는 등 빌드를 정당화할 수 있는 합리적으로 현실적인 비즈니스 시나리오를 마련하는 것이었습니다. 웹 서비스.

우리는 한 방에 많은 사람들을 잠그고 지침에 대한 좋은 topics 만들 잠재적 인 비즈니스 또는 산업, 서비스 및 기술 문제를 브레인 스토밍하는 것으로 시작했습니다. 그 과정에서 웹 서비스를 빌드할 수 있는 몇 가지 이유를 설명했습니다.

• 최종 사용자 또는 다른 비즈니스에서 사용하려는 시간에 민감하거나 매개 변수가 있는 데이터의 원본입니다. 데이터가 자주 변경되지 않고 클라이언트가 거의 항상 모든 데이터를 원하는 경우 웹 사이트에 XML 문서를 게시할 수도 있습니다. 그러나 클라이언트가 데이터에 대해 쿼리를 실행하려는 경우 웹 서비스가 많은 의미가 있습니다. 클라이언트에 데이터를 푸시하려는 경우 구독 및 알림 작업도 잠재적인 웹 서비스입니다.
• 다른 비즈니스에서 구현할 수 없거나 구현하지 않으려는 알고리즘을 구현합니다. 이 경우 각 알고리즘은 잠재적인 웹 서비스입니다. 클라이언트는 데이터를 전달하고 답변으로 응답합니다.
• 다른 여러 서비스를 집계하여 상위 수준 서비스를 제공합니다. 이 경우 클라이언트는 원하는 정보의 조합을 제공하여 기존 서비스 자체를 결합하는 작업을 저장하기 때문에 서비스를 사용합니다.
• 비즈니스 프로세스를 파트너와 통합하려고 합니다. 엔터프라이즈 경계를 넘어가는 비즈니스 프로세스의 각 단계는 잠재적인 웹 서비스 또는 웹 서비스 작업입니다.
• 애플리케이션 통합을 위해 프라이빗 네트워크 또는 긴밀하게 결합된 프로토콜을 사용하는 것이 실용적이지 않은 다른 유형 및/또는 지리적으로 분산된 엔터프라이즈 아키텍처가 있습니다. 통합하려는 각 애플리케이션의 API는 잠재적인 웹 서비스입니다.
• 다른 웹 애플리케이션 및 웹 서비스 개발자(예: ID 서비스 또는 청구 서비스)를 위한 인프라 서비스("배관")를 제공합니다. 모든 클라이언트 플랫폼에 대한 사용자 지정 API 라이브러리를 빌드하는 대신 API를 웹 서비스로 노출할 수 있습니다.

물론 이러한 이유 중 어떤 이유로든 서비스를 구현하고 운영하는 비용을 정당화하기 위해 서비스에 충분한 수의 잠재적 클라이언트가 있는지 여부를 고려해야 합니다.

또한 일반 개발자 대상을 교육하기 위한 샘플 서비스를 빌드할 때 몇 가지 다른 고려 사항이 있다는 것을 빠르게 깨달았습니다. 첫째, 비즈니스 시나리오에는 지정된 산업에 대한 광범위한 지식이 필요하지 않아야 합니다. 둘째, 사용자 고유의 컴퓨터에 샘플을 설치하고 실행할 수 있기를 바랍니다. 셋째, 많은 흥미로운 시나리오에는 하나 이상의 데이터 저장소 또는 피드가 필요합니다. 소유하지 않은 데이터 원본에 액세스하는 방법을 보여 주는 샘플 소스 코드를 제공하는 경우 많은 문제가 있습니다. 또한 데이터 원본은 소유하지 않습니다... 적어도 우리는 샘플을 포기할 자유가 없습니다.

이로 인해 온라인 뱅킹, 컨트롤 홈 디지털 비디오 레코더, 검사 플라이트 상태 또는 일일 만화 서버와 같은 시나리오에서 인프라 서비스 라인을 따라 더 많은 것을 할 수 있었습니다. MSDN이 제공할 수 있는 웹 서비스의 종류(샘플이 아닌 실제 서비스)에 대해 생각하기 시작했습니다. 사람들이 정말 좋아했다는 한 가지 아이디어는 MSDN에 액세스하는 데 사용한 머신에 관계없이 다시 찾고자 하는 MSDN 문서를 추적하는 방법이었습니다. 이로 인해 서버 쪽 즐겨찾기에 대한 아이디어가 떠올랐습니다.

비전, 레브 1

빌드하려는 서비스에 대한 대략적인 아이디어가 있으면 다음과 같은 비즈니스 시나리오를 구축했습니다.

• 웹 개발 사례를 위해 클라이언트 기반을 확장하고 정기적인 수익원을 생성하는 방법을 찾고 있습니다. 웹 사이트에서 사용하려는 고품질 웹 서비스를 제공하여 두 가지 목표를 모두 달성할 수 있다고 생각합니다. 웹 서비스는 새로운 개념이므로 잠재 고객은 비즈니스의 일부를 서비스에 베팅할 수 있다고 확신해야 합니다. 따라서 다음과 같은 티저 웹 서비스가 필요합니다.
  • 잠재 고객의 웹 사이트에 명백한 가치를 제공합니다.
  • 중요 업무용 서비스를 제공하지 않습니다.
  • 개발 및 운영 사례의 품질을 보여 줍니다.
  • 합리적인 비용으로 구현하고 배포할 수 있습니다.

프로젝트에 대한 비전의 첫 번째 컷은 다음과 같습니다.

• The server-side Favorites Service will enable Web surfers to store their favorite links in a safe, secure, central location, so their favorites are accessible anywhere, any time. We will offer the service free of charge to all users; however because we want to protect each user's privacy, users will need to be authenticated to access their favorites. By using the service through a client Web site, users agree that we may use their favorite lists after all personally identifying information is stripped from the data. 이 프로젝트의 2단계에서는 웹 사이트에 대한 추가 서비스에 대한 라이선스를 부여합니다. 예:
  • 해당 사이트의 페이지가 책갈피를 지정하는 통계입니다.
  • 모든 사용자 즐겨찾기의 선호도 분석을 기반으로 하는 권장 링크입니다.

기술적 관점에서 이 시나리오는 고객으로부터 들었던 많은 질문을 해결하는 것처럼 보였습니다. 비즈니스 논리는 구현하기가 너무 어렵거나 독자에게 설명하기가 너무 어려워 보이지 않았습니다. 그러나 모든 사람들이 볼 수 있도록 비전 성명서가 기록되면 몇 가지 큰 붉은 깃발이 올라갔습니다.

• 웹 사이트가 사용자 식별자를 따라 서비스에 전달할 수 있을 만큼 일반적인 체계인 전역 사용자 식별 체계가 필요합니다.
• 최종 사용자가 아닌 웹 사이트에서 요청이 오면 최종 사용자를 인증하려면 어떻게 해야 할까요? 위임이 필요하거나 최종 사용자가 실제로 사이트를 사용하는 경우에만 사용자를 대신하여 요청하기 위해 웹 사이트를 신뢰해야 하는 것 같습니다.
• 다른 웹 사이트에서 추가된 최종 사용자의 즐겨찾기를 검색할 수 있는 웹 사이트가 있어야 하나요? 그렇다면 웹 사이트에서 서비스를 사용하도록 허용하시겠습니까? 아니면 서비스에 대한 액세스를 사용이 허가된 사이트로 제한해야 하나요? 모든 사이트에서 최종 사용자의 입력 없이 즐겨찾기 서비스에 저장된 모든 데이터에 액세스할 수 있도록 하는 것은 엄청난 개인 정보 보호 문제처럼 들립니다.
• 마찬가지로 웹 서비스에서 사용자 즐겨찾기 정보를 유지하기 위한 업데이트 방법을 제공한 경우 어떻게 해야 합니까? 한 웹 사이트에서 다른 웹 사이트에서 추가된 최종 사용자의 즐겨찾기를 수정할 수 있어야 하나요?
• 여러 웹 사이트에서 수집한 데이터에 대한 선호도 분석과 같은 작업을 수행하고 있다는 사실을 알게 되면 최종 사용자가 소리를 지르고 비명을 지르지 않겠습니까? 그들은 이러한 사이트가 우리의 서비스를 사용하고 있다는 것을 어떻게 알 수 있을까요? 어떤 사이트에서 데이터에 액세스하기 전에 최종 사용자가 서비스에 등록하고 개인 정보 기본 설정을 요구하는 것과 같은 작업을 수행해야 할까요? 최종 사용자가 Microsoft에 등록하는 것을 어떻게 알 수 있나요?

아마도 몇 가지 추가 연구는 순서대로했다.

더 비전, Rev 2

사용자 개인 정보 보호에 대해 찾을 수 있는 모든 것을 검토한 후 Microsoft의 회사 개인 정보 그룹 구성원과 몇 시간 동안 서비스를 통해 활성화될 수 있는 시나리오와 개인 정보 보호에 미치는 영향에 대해 논의했습니다. 나는 노트의 페이지 후 페이지를했다, 그리고 여전히 몇 가지 열려있는 문제가 있었다. 그러나 한 사이트가 다른 사이트에서 추가된 데이터에 액세스하거나 수정할 수 있는 시나리오는 개인 정보 보호 관점에서 끔찍하게 들립니다. 즉, 허용해서는 안된다고 말하는 것이 아니라 이러한 시나리오를 다루기 위해 정확하면서도 이해할 수 있는 개인 정보 취급 방침을 작성하는 것이 더 어렵고 최종 사용자가 시나리오에 익숙하지 않을 수 있습니다.

또한 인증 문제에 대한 몇 가지 예비 연구를 했습니다. 중간에 앱이 있을 때 인터넷을 통해 사용자를 전역적으로 식별하고 인증하는 좋은 방법은 없습니다. Microsoft Passport는 사용자가 브라우저를 통해 웹 사이트와 상호 작용할 때 잘 작동합니다. 그러나 웹 사이트에서 사용자의 자격 증명을 다른 웹 사이트에 전달할 수 있는 안전한 방법은 없습니다. 다른 Passport 사용 사이트로 이동할 때 사용자가 사용자 이름과 암호를 다시 입력할 필요가 없는 Passport의 단일 로그인 기능은 어떻습니까? 클라이언트 쪽 리디렉션을 사용합니다. 또한 웹 서비스는 최종 사용자의 컴퓨터와 직접 대화하지 않습니다.

이 예비 연구에 따라, 우리는 단계적으로 즐겨 찾기를 구현하기로 결정했다. 이렇게 하면 개인 정보 보호 의미를 파악하는 데 더 많은 시간을 할애할 수 있으며, 작년 PDC에서 여러 번 언급된 ID 웹 서비스는 글로벌 ID 체계가 필요할 때까지 사용할 수 있습니다.

수정된 비전은 다음과 같습니다.

• 최종 사용자가 나중에 액세스할 수 있도록 웹 사이트에서 선택한 페이지를 책갈피로 표시할 수 있도록 CY2001 중에 즐겨찾기 웹 서비스를 구현하고 배포합니다. 이러한 즐겨찾기는 즐겨찾기 서비스에서 저장되므로 최종 사용자가 사용하는 모든 컴퓨터 또는 디바이스에서 액세스할 수 있습니다.
• 즐겨찾기 서비스는 잠재 고객에게 광고하는 데 사용되므로 품질 및 개인 정보 보호에 대한 회사의 노력을 보여주는 고가용성, 확장 가능하고 안전한 서비스여야 합니다.

순수주의자들은 이것이 비전 진술이 되기에는 너무 길라고 주장할 수 있습니다. 그러나 중요한 것은 모든 사람이 당신이 그것을 부르고 싶은 것이 무엇이든 그것을 이해한다는 것입니다.

다음과 같은 단계를 정의했습니다.

• 1단계에서는 백그라운드에서 고객의 즐겨찾기를 관리하는 데 사용할 수 있도록 웹 사이트 개발자에게 라이선스를 부여할 수 있는 즐겨찾기 웹 서비스를 구현하고 배포합니다. (사실상 각 라이선스 사용자에게는 사용자 즐겨찾기의 프라이빗 데이터 저장소가 있습니다.) 즐겨찾기 서비스를 웹 사이트에 통합하는 방법을 보여 주는 샘플도 제공합니다. 서비스 및 샘플은 2001년 3월 1일까지 라이선스에 사용할 수 있습니다. 우리의 목표는 2001년 3월 1일까지 매월 약 10,000명의 신규 최종 사용자를 나타내는 5~10개의 사이트에 서비스를 라이선스하는 것입니다. (우리는 현재 직원을 감안할 때 이것이 관리 가능한 성장 속도라고 믿습니다.)
• 2단계에서는 인터넷 Explorer 및 Netscape Navigator용 브라우저 확장을 구현하여 최종 사용자에게 현재 클라이언트 쪽 즐겨찾기를 관리하는 것과 같은 방식으로 모든 웹 사이트에 대한 즐겨찾기를 안전하고 안전하게 관리할 수 있는 방법을 제공합니다. 또한 최종 사용자가 즐겨찾기를 관리하고, 개인 정보 취급 방침을 읽고, 개인 정보 사용에 관한 사용자 프로필 옵션을 설정하고, 브라우저 확장을 다운로드하는 데 사용할 수 있는 웹 사이트를 구현하고 배포할 것입니다. 브라우저 확장 및 웹 사이트는 2001년 5월 1일까지 제공됩니다. 우리의 목표는 매월 1,000명의 새로운 최종 사용자에게 도달하는 것입니다.
• 3단계에서는 최종 사용자가 직접 저장한 즐겨찾기(브라우저 추가 기능 또는 즐겨찾기 웹 사이트를 통해)와 즐겨찾기 서비스의 라이선스를 통해 저장된 즐겨찾기를 모두 볼 수 있도록 즐겨찾기 웹 서비스를 확장합니다. 라이선스 사용자는 최종 사용자에게 컨설팅 즐겨찾기 서비스가 사용되고 있음을 알 수 있는 특수 로고를 표시할 수 있습니다(따라서 이러한 즐겨찾기는 브라우저 추가 기능 또는 즐겨찾기 웹 사이트를 통해 액세스할 수도 있음). 라이선스 사용자는 백그라운드에서 즐겨찾기 서비스를 계속 사용할 수도 있습니다. 이 경우 해당 사이트를 통해 저장된 즐겨찾기를 브라우저 추가 기능 또는 즐겨찾기 웹 사이트를 통해 사용할 수 없습니다. 3단계는 2001년 6월 1일까지 제공됩니다.
  3단계는 향후 웹 서비스를 위한 토대를 제공합니다. 예를 들어 사용자가 웹 페이지를 방문하는 경우 사이트에 페이지를 좋아하는 다른 사용자도 좋아하는 웹 페이지 목록이 표시될 수 있습니다. 웹 사이트는 웹 서비스에서 페이지 목록을 검색합니다. 이러한 유형의 프로파일링 서비스를 구현할지 아직 결정하지 않았습니다.

이를 통해 비전 문서의 나머지 부분을 구체화할 수 있습니다.

다음 단계는 일부 사용자 프로필을 정의하는 것이었습니다. 웹 서비스 프로젝트에 대한 비전을 정의할 때 모든 사용자가 누구인지 신중하게 생각하는 것이 중요합니다. 구상 단계에서 식별한 사용자 범주는 다음과 같습니다.

• 최종 사용자 - 웹 브라우저를 사용하여 웹 사이트를 방문하는 모든 사용자입니다.
• 사용권자 - 즐겨찾기 서비스를 사용하는 웹 사이트를 사용하는 모든 비즈니스입니다.
• 라이선스 개발자 - 라이선스 사용자의 웹 사이트를 빌드하는 개발자입니다.
• 사용권자 운영자 - 사용권자의 웹 사이트 운영자입니다.
• 운영자 - 즐겨찾기 서비스 운영을 담당하는 사용자입니다.

이 열과 함께 제공되는 Favorites Vision 문서에서 전체 사용자 프로필을 읽을 수 있습니다. 그것은 우리가 몇 가지 범주를 놓친 것으로 나타났습니다 : 라이센스의 관리자와 관리자. 이러한 내용은 보고 요구 사항에 대해 생각하기 시작했을 때 잘렸습니다. 테스터를 별도의 범주로 분할해야 합니다. 이 목록은 대부분의 웹 서비스 프로젝트에 적합한 시작점을 제공해야 합니다.

우리는 또한 비즈니스 목표와 디자인 목표에 대해 생각하는 데 약간의 시간을 보냈습니다. 기본 질문 중 하나는 웹 서비스를 빌드하는 이유입니다. 당신은 돈을 벌려고? 비즈니스 프로세스를 간소화하려고 합니까? 아니면 완전히 다른 뭔가? 어떤 결정이든 요구 사항에 영향을 미칠 수 있습니다. 예를 들어 즐겨찾기 서비스의 주요 목표는 다음과 같습니다.

• 고품질 제품에 대한 우리의 헌신을 보여 줍니다.
• 신뢰할 수 없는 서비스, 보안 문제 또는 개인 정보 보호 문제로 인해 잘못된 언론을 피합니다.

이러한 목표 조합은 특히 라이선스 및 기능 요구 사항(확장성, 가용성 등)에서 서비스에 상당한 요구 사항을 추가했습니다. 그러나 돈을 버는 것은이 프로젝트의 완전한 비 목표입니다. 그것이 목표라면 많은 라이선스 요구 사항이 약간 다르게 나왔을 것입니다.

디자인 관점에서 사용자 개인 정보 보호, 보안 및 기타 비기능적 요구 사항에 대한 전반적인 철학을 고려해야 합니다. 또한 전 세계 클라이언트가 웹 서비스를 사용할지 여부와 이것이 세계화 및 지역화에 대해 의미하는 바를 고려해야 합니다. 예를 들어 몇 가지 디자인 목표는 다음과 같습니다.

• 전 세계 솔루션을 제공합니다. 서비스 및 모든 지원 애플리케이션은 전역화되어야 합니다.
• 안정적이고 안전한 서비스를 제공합니다. 서비스는 고가용성이어야 하며, 데이터가 손실되지 않아야 하며, 권한 있는 사용자의 액세스만 허용해야 합니다.

나머지 비즈니스 목표 및 디자인 목표는 Favorites Vision 문서에서 찾을 수 있습니다.

결론

프로젝트 팀과 고객이 전체 목표, 목표 및 scope 선불에 동의한 경우 프로젝트를 완료할 때 항상 더 쉽게 알 수 있습니다. 기존 웹 사이트에 웹 서비스 프런트 엔드를 추가하는 것으로 생각되더라도 비전 문서를 작성하는 데 시간이 걸리는 것이 좋습니다. 프런트 엔드를 추가하는 이유는 무엇인가요? 누구에게 사용하시겠습니까? 운영 담당자가 기대하지 않는 사이트에 얼마나 많은 추가 부하가 있나요?

즐겨찾기에 대한 비전 문서를 작성하는 것은 우리에게 중요한 연습이었습니다. 그것이 없었다면, 우리는 우리의 기능 사양에 결국 요구 사항의 절반 이상을 놓쳤을 것입니다. 예를 들어 게임 후반부까지 개인 정보 보호 및 보안 문제를 인식하지 못했을 것입니다. 비전 문서는 우리에게도 다른 일을 합니다. 기능 요청을 평가하고 요구 사항의 우선 순위를 지정하기 위한 척도를 제공합니다. 이 문서는 향후 단계에서 수행하려는 작업을 상기시켜 줍니다. 샘플 디자인에서 이를 설명할 수 있으므로 작업을 완전히 다시 작성할 필요가 없습니다.

다음 주에는 여기에 언급된 개인 정보 보호 문제를 자세히 살펴보겠습니다. 회사 개인 정보 그룹에서 배운 내용을 알리고, 지연된 어려운 문제에 대해 이야기하고, 1단계에 남아 있는 개인 정보 보호 문제와 이러한 문제가 설계 및 구현에 미치는 영향에 대해 설명합니다.

그럼 보자!

Mary Kirtland 는 MSDN 웹 서비스 지침 팀의 설계자이며, 사양을 최신 상태로 유지하려고 하고, MSDN에 대한 문서에서 배운 모든 것을 적고, 리뷰 중에 성가신 질문을 하고, 점심 식사를 주문하는 등 코딩, 테스트 또는 작업을 제외한 모든 작업을 수행합니다.