Music by a stream with clouds

Consumers have an ample choice of online music services right now. The market is fragmented; each provides a slightly different set of offerings and outlays. Napster is the most established. A decade ago, it was innovative, subversive and popular. It then went dark for a couple years (while presumably it went through legal dialogue) and emerged as a competitive and commercial music rental/purchase service. It had cool features such as an embedded monthly music “magazine”, Windows XP Media Centre integration and a virtual monopoly for around five years in offering unlimited music rental for around $10/month. It should have been a second coming but an apparent inability to read the market caused it to slide from public consciousness; the magazine stopped after a few months, marketing was outmoded, DRM implementation was unwieldy, Media Centre integration disappeared for both Vista and Windows 7, barely anything was free and mobile, web-client and social networking integration were too little too late.

This opened up the market as smaller players gained footholds. Some concentrated on “radio” e.g. Pandora and Slacker. Several went for the rental market e.g. Spotify and Rhapsody. Others stayed with the download model e.g. iTunes and Amazon MP3. Across all of these (and others) there are varying combinations of payment/access methods/DRM/integration etc.

It is clear that streaming and downloading will both remain as different media access methods. Apple hardware owners will always use iTunes (and latterly Lala [US only at moment]) and the remainder of the download music service market looks to be being mopped up well by Amazon MP3.

The first service that can make a sustainable business out of free (and DRM-free) global audio streaming access in a browser (not just US like Pandora and Slacker or Europe like Spotify [plus Spotify does not currently provide web access]) with service continuity and payment options that include - Media Centre integration, mobile and offline support will have a relatively clear-run for the next five years or so. Aside from essential playlist functionality, adverts (or the lack of them), HD/loss-less quality, social networking features, upload capabilities and music discovery/search features are not mainstream deciding factors. Online music is mostly commoditized in terms of need. Consumers want a service that works, is accessible anywhere and is (at an entry level) free. Of available services, Spotify appears to have the best service continuity - being the fastest to start tracks (faster even than Windows Media Player) and never dropping out.

Of those available - the closest to this ideal is Grooveshark. Although to ensure its future, it still needs to improve service continuity, produce a Media Centre client and ideally - deliver the mobile experience without requiring an app (and a bit faster). Also, it is worth noting that the perceived legality of Grooveshark is topical; dissuading some from investing time in it. It simply seems too good to be true that right now; anyone - anywhere, on any PC or console (including PS3) browser can play pretty much anything (without audio adverts) - all day, without even creating an account. Further, if you do elect to create an account (requiring the barest minimum of details), the site will help you send links to people to share tracks or embed a play button in your blog (all without them creating an account). You can even post any streaming track to Facebook. Why isn't everyone using it? It’s great now. It will be fantastic if they can make their business model work long-term.

Given Google’s general cloud/consumer centric approach and the fact that they have recently released a video streaming solution, it appears incongruous that they do not possess an audio streaming solution. Yes - they came in late last year with search augmentation where samples are streamed and then directed to purchases from partners but Google does not own these organisations which means they will not be well integrated with the rest of the range (tags, social, semantic web etc.). They also suffer from comparison with the ideal above.

People can go to a friend’s house/cyber-cafe, use their computer to watch a film through YouTube (US only at moment) then access all of their pictures and documents through Picasa and Google Docs respectively; but they cannot play their music (using a Google product) while they are doing it? Shouldn’t Google buy Grooveshark and mix it up with everyone else? 

Seraphis to Spreadsheets

Offshore development is a trade-off of cost and skills against communication. It will always be this way until, of course, demand exceeds supply and the only reason organisations consider offshore is for premium skills. Communication will likely always be an issue; as it is when broaching any two cultures, time-zones and work ethics. It is however unhelpful to blanket term – communication.

The issue with offshore communication is communicating project goals (and also progress against them as this is the only real way to confirm understanding). Operational (day-to-day/immediate communication) is generally OK (and much of the reason why non-French speakers can order food in Paris and be understood). Even complex operational communication can be understood offshore. The problem is in appreciating (and buying into) the end-game or goal and that means keeping it simple.

Ancient Greeks understood this when they simply bolted on Greek Gods to Egyptian religion (creating The Cult of Seraphis) as a goal-bridge to help them manage Egypt.

The simplest method of maintaining project tasks is to place them into a single spreadsheet (easy comparison between developers) and to establish a daily process for recording developer feedback e.g. proportion of tasks they have worked on the previous day/changes to effort estimates based on greater exposure. We will certainly want a way of “parking” tasks for a while (if one of their pre-requisites is not ready). Next, we will want a system generated “estimate” for when the task will be completed (based upon daily progress). This will be necessarily different to both the original estimate and the ongoing developer estimate. Finally, we want web-enablement. That is it; the minimum required to capture/communicate developer progress against common goals/estimate when code will be complete.

The process of being code-complete further refines the goal (coding is usually not the bulk of a project). Developers can intersect actual communication (bugs, “please make it do this...” etc.) with code to obtain an accurate representation of what is really required. Further communications – testing, QA/UAT, environment support etc. is easier.

A reusable example of the spreadsheet we have just described is here. Cell comments aid interpretation. Just apportion 1.0 of a day over the tasks for each developer and do it every day. Simple spreadsheets like this have genuinely helped manage complex offshore development projects. Project servers, operational BI, timesheet integration etc. add complexity and detract from the “what/who/when” simplicity required for communicating goals.     

MOSS Internet Site - Security

Building a corporate Internet site using MOSS has real security implications. Access from the Internet (for the users) and from within the organisation (Intranet) must be considered in terms of both authentication and authorisation. Although a sound solution, MOSS is not well documented here and an implementation typically needs to be designed. Following is a suggested solution template for organisations to use when attempting this. It should resonate with the majority of MSFT-shop organisations moving to a MOSS Internet site solution.

The solution supports two basic user categories:

1) Internal users. Employees accessing via the Intranet. Typically content authors - in charge of maintaining solution content. It is recognized that a requirement for employees to maintain content via the Internet (from home?) may well exist. In this situation, they should connect to their Intranet using whatever connectivity solution is already in-situ (VPN?). Although it is certainly possible to allow employees to manage content directly over the Internet, this creates additional complexity, cost and security risk for perhaps the sole benefit of; being able to manage content from an “unofficial” desktop (without the connectivity software) e.g. in a cybercafé.
2) External users. Public users accessing via the Internet. Able to access content only. May be further categorized as either - Anonymous user (Read only/Able to access all public content) or Registered user (Read only/Able to access special content in addition to public content).

The solution supports two-way authentication; one to support internal users (NTLM) and the other to support external users via Forms Based Authentication (FBA). Internal users are authenticated using the SSO (Single Sign-On) feature provided by the LDAP directory services. An internal SSO process synchronises the Intranet AD with a De-Militarized Zone (DMZ) LDAP. In practice, this will mean that an internal user can log onto the Intranet and be pass-through authenticated to the DMZ i.e. they will not have to log in twice.

Synchronisation between the Intranet AD and DMZ LDAP is one-way. This means that the creation of new internal users will have to take place on the AD and not directly in production. Assuming your organisation does not need to use profile import for LDAP users (and also does not provide custom profile properties for its internal users), it will only need to cater for authentication of LDAP users. This is perhaps a minor risk, since it will only be possible to test this once deployed in Production.

Similar to traditional NTLM authentication mechanisms, the FBA application requires a centralized store for external user credentials (in this case - SQL database). Internal user credentials are stored in AD (on the Intranet) and in LDAP (within the DMZ). An internal SSO process synchronizes them. No authentication is required for anonymous external users as you would expect.

User information stored in the SQL database is created only by a single registration process. A registration page defines the user information and the related validation. Using FBA, users will remain authenticated until the user closes their browser or until authentication timeout occurs.
 
Moving onto authorisation; authorization policies are required for granting content access rights for differing user categories. As stated above two different “extended” web applications are defined for managing both internal and external users. Authorization policies are applied to those distinct “extended” applications addressing the user categories’ tasks.

In the “extended” web application defined for the NTLM authentication (used by internal users) two different user groups are defined in the site settings permission section - Site Administrator (users with full control access rights) and Content Authors (users with design control access rights). No Anonymous access is supported in this “extended” web applications instance. In the “extended” web application defined for the FBA authentication (used by external users) all users are defined as users with read access rights. Anonymous access is supported for a subset of content as appropriate.

A final note on domains. The AD within the DMZ is for service accounts only e.g. SQL or MOSS services. It is not possible to trust the DMZ AD and the organisation AD proper. The DMZ is also unconnected to any other organisational system. MOSS based content deployment into the DMZ is unsupported. These measures should address internal security concerns. There are plenty of other security hoops to jump through when creating a MOSS Internet site but the above should get you started.