Infrastructure for Enterprise 2.0 Applications – Part 1
by Michael Hay on Feb 16, 2009
At Hitachi do we have such a thing? I’m sure many customers would say I think not, but wait maybe just maybe we do. Hang with me a second and let’s first consider the point that Microsoft Sharepoint 2007 is really an Enterprise 2.0 platform in sheep’s clothing. If we look at the Wikipedia definition of what Enterprise 2.0 is we can find the following attributes (pulled directly from Wikipedia):
- Search: allow users to search for other users or content
- Links: group similar users or content together
- Authoring: include blogs and wikis
- Tags: allow users to tag content
- Extensions: recommendations of users or content based on profile
- Signals: allow people to subscribe to users or content with RSS feeds
Well, I can honestly say that many of these attributes already exist within MOSS or Sharepoint itself directly. Further if you look an announcement from Microsoft circa last summer you will find that they are extending the platform to other companies so that Sharepoint can be used as a platform in a way similar to building a FaceBook application. Of course the difference is that Microsoft really suggests that ASP.NET is used as the application platform, although with the usage of open middleware toolkits (.NET built or not) based on XML over HTTP communications it is possible to connect to other systems like modern storage devices. Like other Enterprise 2.0 platforms adoption of Sharepoint comes from smaller organizations or business units within an enterprise, and in many cases are either manged or deployed without direct involvement of the centralized IT organization. In a very real sense Enterprise 2.0 applications, like Sharepoint, are empowering to both the smaller organization and to the individual directly. Due to an investment strategy by Microsoft adoption of Sharepoint is way way up, and I would argue it is rapidly become the most prevalent file sharing application on the market.
However while there is empowerment at the level of the organization or individual, it doesn’t mean that there aren’t trade offs, consequences, or limitations. One rather large issue is that for every new project, group, or business unit in many cases there is a new Sharepoint site created. Further while it makes sense that users should share links to files that are warehoused within Sharepoint this is not typically what happens. Instead people use the least common denominator to share files like USB drives or email. In some cases this is done to circumvent security countermeasures, in other instances it is done to for inter-organization communications, and finally because these two approaches are just so easy. (I know that someone will point out exceptions to this observation, but again I’m looking at the general behaviors here.) The results of these activities include the unnecessary duplication of content between Sharepoint sites. However, Microsoft has yet to provide a way to detect this duplicated content let alone remove it. This problem is aggravated by the fact that Sharepoint sites have a very real scaling limit due to the embedded MS-SQL server. Further as sites fill up users tend to create more sites which becomes a vicious cycle making the problem more acute. Let me add one more wrinkle to the mix: eDiscovery and compliance. Even though these sites are owned by individuals, groups, organizations, teams, or business units companies and the centralized IT organizations are still responsible for gathering and protecting this content in accordance with the laws and federal procedures of the land. That implies some kind of a merger of a centralized IT infrastructure coupled to an Enterprise 2.0 front end. The question is how can this be done?
(Continued in Part 2)
