ProfServProjects: Difference between revisions
Karsten.will (talk | contribs) (→Tools) |
Karsten.will (talk | contribs) |
||
Line 36: | Line 36: | ||
During this phase it is decided what exactly there is to do, by whom and when. The resulting Customer Implementation Concept formalizes this information, accompanied by (several) SOWs which detail Open-Xchange efforts. | During this phase it is decided what exactly there is to do, by whom and when. The resulting Customer Implementation Concept formalizes this information, accompanied by (several) SOWs which detail Open-Xchange efforts. | ||
* Detail Workshop(s) | * Detail Workshop(s) | ||
* Detailed architecture-description (which parts are delivered by operating system / customer / Open-Xchange) | |||
* Installation of test-system | |||
* Authentication | |||
** explain separation of contexts. 2 separate roles: oxadminmaster (creates contexts) and oxadmin (creates users, but only in his context) | |||
** explain resolving of usernames into contexts | |||
** Auth-Bundle: SSO, Auth-Plugin (DB, LDAP, IMAP, custom) | |||
** Passwordchange (DB, LDAP, IMAP, custom) | |||
* Integration into customer´s provisioning (choose API best suited. RMI preferred) | |||
* Loadbalancing (existing / Apache / buy new one?) | |||
** explain session-stickyness (1 session always resolved to the same host) | |||
* Storage for Infostore (NFS / GlusterFS, existing / buy new?) | |||
* Monitoring (munin, nagios -> script that polls Open-Xchanges JMX-interface) | |||
* Scaling (How to setup a cluster, high availability) | |||
* MySQL-Sizing (dedicated servers / on the ox-machine(s)? master-slave / master-master?) | |||
* Branding (own heme, icons, login-page, wizard, about-dialog etc.) | |||
* compatibility of the IMAP-backend (supported features vary between different MTAs) | |||
* User-Migration | |||
** import exiting users / contexts via CSV-Batch-Import | |||
* Data-Migration | |||
** from existing webmailers (Horde, @mail, squirrelmail) | |||
** contacts, appointments, mailsettings (aliases, primary email-addresses, mailfilters) via import-interfaces (HTTP-API, supported: iCal, vCard) | |||
* Upsell | |||
* SPAM | |||
* SMS/MMS | |||
==Tools== | ==Tools== |
Revision as of 10:24, 25 October 2011
This page aims to give a detailed overview of customer-projects accompanied by the Open-Xchange professional services team: The different phases and decisions as well as the documents necessary to accompany this process are listed here.
The following diagram gives a birds-eye view of the whole process:
Initialization
During this phase the product gets demoed and the doability of the project is checked. After this phase a detailed offer is made and the customer decides whether to start the project or not ("Go" / "No-Go").
- Technical Demo (webcast or on-site)
- presentation of the product including all features relevant to the customer
- determine customer´s goals (replace webmail? operating parallel to MS Exchange?)
- OX USPs: Fast even with many mails, drag-n-drop in the browser, syncing with many different clients, social, upsell
- demo-systems could be http://ox.io, https://ox6-dev.open-xchange.com, own VM -> 2 users and some data are needed
- recommend ox.io-account to the customer for own tests
- Architecure Overview
- Integration with customer systems instead of out-of-the-box (provisioning, mailsystem [none is included!], CPanel, PBA/POA, Plesk)
- There are many ways to OX and its data. Broad range of supported devices and browsers
- Java, no proprietary formats or protocols, Apache, MySQL
- scales horizontally as well as vertically. Cluster size is entirely choseable, multiple tenants on one system -> "server density"
- show examples for 10K users, 100K users, 1M users
- APIs (HTTP, SOAP, RMI, ex- and import)
- whitelabeling for GUI, Outlook, OutlookInstaller, MobileGUI (branding, theming, detailed configuration with ConfigCascade)
- Proof Of Concept (POC)
- needs server (real or VM) with SSH-access, a few accounts on the existing mailsystem
- inform customer as soon as it is ready, get feedback after 2 weeks, are there still open issues open in R&D, Sales or Marketing?
- Technology Transfer
- approximately 10 mails.
- evaluate customer-environment (what kind of mailsystem, loadbalancer, storage, number of mailboxes?)
- hardware-sizing (how many concurrent sessions)
- provisioning (existing or custom?)
Tools
- Meeting Minutes These minutes cover attendees to a meeting, topics discussed, decisions made and action items.
- Project Charter The Project Charter contains the goals and scope of the whole project. Stakeholders on both sides are defined here as well as detailed responsibilities and milestones to measure progress. Also further organization of the project is specified including details about documentation, reporting and communication.
- Formal Offer.
- Basic SOW The basic SOW describes in detail all Open-Xchange implementation-efforts already known and agreed upon at this point in time.
Concept
During this phase it is decided what exactly there is to do, by whom and when. The resulting Customer Implementation Concept formalizes this information, accompanied by (several) SOWs which detail Open-Xchange efforts.
- Detail Workshop(s)
- Detailed architecture-description (which parts are delivered by operating system / customer / Open-Xchange)
- Installation of test-system
- Authentication
- explain separation of contexts. 2 separate roles: oxadminmaster (creates contexts) and oxadmin (creates users, but only in his context)
- explain resolving of usernames into contexts
- Auth-Bundle: SSO, Auth-Plugin (DB, LDAP, IMAP, custom)
- Passwordchange (DB, LDAP, IMAP, custom)
- Integration into customer´s provisioning (choose API best suited. RMI preferred)
- Loadbalancing (existing / Apache / buy new one?)
- explain session-stickyness (1 session always resolved to the same host)
- Storage for Infostore (NFS / GlusterFS, existing / buy new?)
- Monitoring (munin, nagios -> script that polls Open-Xchanges JMX-interface)
- Scaling (How to setup a cluster, high availability)
- MySQL-Sizing (dedicated servers / on the ox-machine(s)? master-slave / master-master?)
- Branding (own heme, icons, login-page, wizard, about-dialog etc.)
- compatibility of the IMAP-backend (supported features vary between different MTAs)
- User-Migration
- import exiting users / contexts via CSV-Batch-Import
- Data-Migration
- from existing webmailers (Horde, @mail, squirrelmail)
- contacts, appointments, mailsettings (aliases, primary email-addresses, mailfilters) via import-interfaces (HTTP-API, supported: iCal, vCard)
- Upsell
- SPAM
- SMS/MMS
Tools
- Meeting Minutes These minutes cover attendees to a meeting, topics discussed, decisions made and action items.
- Workshop Agenda
- WBS (mindmap)
- Customer Implementation Concept
- several SOWs (preferrably one per topic)
Implementation
During this phase everything that was planned before will be realized.
- Weekly status calls
- Documentation of all installed systems & components
- Training workshops for admins / 1st level support
- Open-Xchange-internal time tracking
- Open-Xchange-internal change management
- Open-Xchange-internal approval (review of the complete system)
- Loadbalancing
- MySQL-Cluster
- automated tests
- jmeter tests
Tools
- Meeting Minutes These minutes cover attendees to a meeting, topics discussed, decisions made and action items.
- Requirements Checklist ... In this list all issues and todos, together with dates and the person responsible on either side, are tracked. It is expanded during meetings or calls as necessary. When the phase is over all items in the list should be checked, making the project ready for launch.
- Test protocols
Approval
- Handover to Open-Xchange support
- detailed technical documentation including test-accounts, credentials, people in charge etc.
- test OTRS process
- Lessons learned
- customer feedback
- personal
- Open-Xchange-internal project retrospective
Tools
- Meeting Minutes These minutes cover attendees to a meeting, topics discussed, decisions made and action items.
- Requirements Checklist ... This list produced during the previous phase contains agreed upon and done items. These should be checked again in this phase by the customer´s quality assurance team for the live system.
- Test protocols