There is a key difference when we look at social networks in our personal lives (Facebook , Twitter, etc.) and professional lives (LinkedIn) and social networks in an enterprise and that key difference is that enterprises are still primarily concerned with getting work done.
If we sat down and read every email in everyone’s inboxes, took notes in every meeting, lurked in every chat room, and then carefully kept everything up to date, we’d be able to answer questions like, What are all the steps left between now and the next project? Who’s responsible for each step? Which tasks are high priority, and which can wait until later? Where are all the files and conversations needed to do this particular activity?
Or, Why did we decide that thing six months ago that’s affecting what I’m trying to do right now? Heck, What should I be working on right now?
But no one is able to read/note/track/lurk on everything. Even if they could, it’s soul-sucking (at least, it was for me). And this work about work — and the resulting confusion around not knowing what’s expected of us — contributes to disengagement, resulting in billions in lost productivity. Every year.
It seems crazy that 99% of companies lack a single place to track all of this, a definitive source of “truth” about everything they’re working on. Crazier still given that $304 billion will be spent on enterprise software this year, much of it — like enterprise social networks — purporting to solve these problems. The problem with many of these approaches is that they’re just ports of earlier technologies designed for connecting people, not for coordinating work.
Yet there’s a way to work together with less effort, and it requires harnessing the work graph. Whereas a social graph maps people and their relationships, a work graph centers around the work.
I think the bolded is the key; what enterprise needs today isn't necessarily tools to connect people -- there are plenty of those already -- but better tools to coordinate work. What enterprises need is a way to streamline how work gets done and -- sure -- part of that is connecting the right people, but part of that is being able to then coordinate the effort without introducing too much process friction and overhead.
By and large, most of the teams I work with from Fortune 500 customers and clients as well as tier 1 consulting companies still rely on positively antiquated processes and software to manage coordination of work that are heavily wrought with impedance. Microsoft Project plans and Excel spreadsheets are some of the absolute worst tools that one could possibly choose for planning, managing, and coordinating modern software projects and yet they are still the bread and butter of many teams (maybe that's why "On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted").
I find that most of that is a result of the simple fact that project managers in your typical enterprise project are likely to be more senior folks who moved on up from their prior positions that are somewhat set in their ways and their tools. Software and how we interact with it has evolved dramatically over the last decade (think about it, Facebook didn't exist 10 years ago) and yet many project managers have not evolved their thinking and how to utilize more fit-for-purpose software for coordinating work; they have stuck to their guns and carry over legacy Excel spreadsheets and Microsoft Project plans that are simply too unwieldy for fast-paced, day-to-day collaborative execution of work.
Just as cloud infrastructure is beginning to shift how enterprises rethink IT infrastructure, will we see a similar shift in how teams coordinate work? If it comes, I think it will look far less "social".
Thinktastic TeamPoint is one crack at solving this problem of coordinating work by integrating chat with real-time notifications linked to project artifacts (tasks, documents, milestones) to create a real-time, contextual, workstream that allows teams to view progress, broadcast status and in-progress work, as well as provide greater visibility into the overall health of the project.
I've worked with SharePoint now for some 7 years starting from SharePoint 2007 beta 2 and I've worked with portals and CMS systems in some form or another since 2003.
Since 2006, most of my domain experience has been in life sciences, but I think that what I've observed applies to most other industries and verticals as well.
So the question is whether SharePoint has jumped the shark? Is it the second coming of Lotus Notes? Have businesses soured on it as an enterprise application platform? Is it a failed vision? Is it time for your organization to put it out to pasture?
One of my observations in the last two years or so is that increasingly, I have been called upon to defend the choice of building a solution of top of SharePoint (I've even heard audible snickers). You can see the eyes rolling from certain folks when we mention that our solution at InnovoCommerce is built on top of SharePoint. The skepticism and questions about scalability soon follow, but it's not unfounded: it's most often based on firsthand experience with the pains of owning and managing SharePoint. As the saying goes: fool me once, shame on you; fool my twice, shame on me.
Indeed, I think that the popularity and rise of SharePoint has been its own worst enemy in a sense. As adoption of SharePoint increased with 2007 and 2010 (in part, thanks to the incredible marketing of Microsoft that often oversold the ease and value), organizations rushed to roll it out and make it available to their users. In many cases, proper governance and information architecture were either an afterthought or poorly thought out from the onset, leading to deployments which were a nightmare to manage and maintain as rogue site collections and sub-sites cropped up like toadstools after an early summer shower.
Now, after one or two upgrade cycles, and maybe half a decade of ownership, organizations are starting to sour on shelling out for another (multi-) million dollar project to upgrade to 2013.
Organizations eventually -- more or less -- run into the same key problems:
Scalability and Performance.
One of the most troublesome byproducts of poor information architecture and planning is a considerable degradation of performance. SharePoint provides endless ways with which to shoot yourself in the foot with regards to building scalable, performant applications; it's a field of landmines that even experienced SharePoint architects have to navigate carefully on each project as understanding the scale and intended usage patterns of data is key to coming up with a plan to build a system that will scale. The indiscriminate use of and reliance on item level permissions is a good example of this. Failure to break up data into manageable scopes is another. In the case of custom code, bad or lazy coding practices can also have severe consequences in terms of performance.
Fortunately, most performance issues can be managed -- if use cases are well designed and well understood -- through some thoughtful design up front to build an information architecture that will align with how SharePoint is built to scale. On the custom code side, following guidelines and best practices along with code reviews can help prevent or alleviate many of the most common traps that developers fall into. For this, experienced, battle-tested SharePoint architects and developers are worth their weight in gold (wink, wink)!
Of course, this feeds well into the next point...
Getting a large SharePoint architecture and deployment right is expensive (getting it wrong, even more so!). From the cost of the hardware to the cost of the licenses of SharePoint (don't forget Windows Server, SQL Server, etc.) to the cost of the human resources required to plan the infrastructure, gather the requirements, design the architecture, manage the deployment, and offer on-going support.
It is a huge endeavor made all the more challenging when you factor in custom solutions that get built and installed on top of SharePoint and all that entails -- including risk. Of course, many companies I've worked with have tried hard to minimize these costs through governance policies that severely limit the amount of customizations available -- often requiring several rounds of evaluation, validation, and approvals to get custom solutions installed.
While this does tend to help keep costs down from an ongoing maintenance perspective, I contend that it also severely limits the ROI and utility of SharePoint by crippling it. Strip away the ability to build sophisticated business solutions on top of SharePoint, and you are left with a very expensive portal; it's like going to Chipotle and getting a rice bowl with only rice in it
In a way you could say that overzealous organizations addressed the cost of risk by squashing creativity and innovation in terms of mapping business processes into powerful solutions in SharePoint; IT simply didn't allow teams to come up with novel, creative, and innovative ways to extract ROI from SharePoint because of fear (I don't blame them!). Oddly, by limiting SharePoint to basic ECM functionality, I believe that IT organizations simultaneously decreased their own value in terms of delivering real solutions to the business users and creating a justification for the investment in SharePoint -- everyone loses if you just treat SharePoint like a giant file share or a merely a portal.
While I'm a huge advocate of SharePoint as an enterprise application platform (it's what I've been doing for years now) and not just a portal, working in the solution and product development side means that I also have an appreciation of the pain and costs associated with planned obsolescence. You see, every three years or so, Microsoft releases a new version of SharePoint that will eventually "force" you to upgrade. Perhaps it's a new feature of Office that can only be used with a certain version of SharePoint. Or it's a critical fix or feature that addresses a key issue of your current deployment. Or the product simply reaches end-of-life. Or, from a product development perspective, you are simply forced to upgrade your codebase to capture or keep your customer base that is moving onto a new version. It's expensive (I could imagine circumstances where migrations could cost as much or more than the original platform itself) and you are kind of forced to do it every few years.
It creates so much impedance and hand-wringing that some companies simply skip the migration and leave little zombie SharePoint deployments sitting around (our own document management portal at InnovoCommerce is still on SharePoint 2007, and we're a SharePoint shop with deep SharePoint experience).
From the product development side, it is a particularly challenging balancing act to decide how to allocate resources and time to upgrading your codebase while still developing capabilities and maintaining support for existing customers who may not move off of their current version of SharePoint for another two or three years (because of the aforementioned issue of cost and time). When the fundamental architecture of the platform changes so drastically -- as it has with the shift from 2010 to 2013 -- this makes it all the more challenging (and expensive).
Analytics (Or Lack Thereof).
While SharePoint does offer many great features for building dashboards and KPIs, integration with SQL Server Reporting Services, and other reporting capabilities, I find it severely lacking from an analytics perspective. A good example is that, for a platform that bills document management as one of the key features, you would think it would be simple to see a document access report that shows all documents, the number of times they were accessed, who accessed them, what actions each user took, etc. You'd like to see it with some basic charts and visualizations that give you a good overview of the data (in an increasingly data driven and yet data saturated world).
Nope. Instead, to get this type of basic document metrics, you have to build quite a complex solution (especially so given the barely sufficient audit log query APIs).
Another challenge from an analytics perspective is basically complexity. For any significant deployment, it is a huge challenge to extract data from SharePoint to build sophisticated reports, especially if you follow best practices and segment data into separate site collections and databases not to mention the challenges and pitfalls of working directly against the raw SharePoint databases (practically a must if you plan on doing any serious analytics across your data).
What's the Future?
For many organizations, I can see SharePoint 2010 being their last dip into the SharePoint pool, at least as an IT owned and managed solution. I believe that the experience that organizations had with owning 2007 and then migrating to 2010 has left a bad taste in the mouths of many IT organizations (not to mention the business sponsors). Microsoft is making a strong push with Office 365, but many organizations are understandably reluctant to put their data into Microsoft's cloud (or any cloud, for that matter). Other organizations might opt to migrate onto less costly, open source solutions like Alfresco, Liferay, or perhaps any number of cloud-based platforms including Google (one of our very large pharma customers has already moved their mail systems from Exchange and also use Google Docs).
It will be interesting to see how SharePoint 2013 and the future of SharePoint unfurls given much of the challenges organizations have had with 2007 and 2010. In life sciences -- and I suspect with many other industries as well -- there has also been a large movement to downsize IT budgets and IT ownership of platforms, making ownership of SharePoint and delivering useful business solutions on top of it an increasingly challenging task.
While SharePoint 2013 is still plenty expensive when you factor in all of the licenses and expertise required to deploy and manage it, I think it addresses many of the key problems with regards to the deployment of custom solutions -- where I think the most business value is realized -- into SharePoint and is a huge leap forward from 2010 (a much bigger gap, in my opinion, than from 2007 to 2010).
At InnovoCommerce, we have yet to see any of our customers move in this direction (but then again, life sciences companies tend to move slowly anyways -- some of our customers are just going live with 2010) so it will be interesting to see how the landscape of enterprise portals and application platforms evolves over the next year or so.
We are increasingly mulling moving more and more of our codebase out of SharePoint as a mechanism for insulating against the cost of upgrade cycles as well as ensuring that our platforms can be deployed, managed, and integrated more readily and preparing ourselves for a future where our customers may be looking the other way when it comes to their enterprise portal and business application platform of choice.
I'm not sure, but I don't want to find out either.
I'm currently tasked with recommending a new source control platform and a new defect tracking platform as well.
I'm late to this post from March 2010, but Martin Fowler posted an internal ThoughtWorks survey of version control tools:
I conducted the survey from February 23 2010 until March 3 2010 on the ThoughtWorks software development mailing list. I got 99 replies. In the survey I asked everyone to rate a number of version control tools...
...there's a clear cluster around Subversion, git, and Mercurial with high approval and a large amount of responses. It's also clear that there's a big divide in approval between those three, together with Bazaar and Perforce, versus the rest.
The biggest offender? TFS with a 0% (yes, z-e-r-o) approval from the ThoughtWorks staff. Scary.
Team Foundation Server advocates claim it’s unfair to compare TFS to other source control tools, since it’s not just source control, but an integrated end-to-end application lifecycle management solution. Comparing TFS to, say, Subversion, is like comparing Microsoft Office to Notepad, so they say.
Now where have I heard something like that before? Oh yes, Lotus Notes:
The main focus for frustration is Notes’s odd way with email, and its unintuitive interface. But to complain about that is to miss the point, says Ben Rose, founder and leader of the UK Notes User Group (www.lnug.org.uk). He’s a Notes administrator, for “a large automotive group”.
It’s regarded by many as an email program, but it’s actually groupware,” Rose explains. “It does do email, and calendaring, but can host discussion forums, and the collaboration can extend to long-distance reporting. It will integrate at the back end with huge systems. It’s extremely powerful.”
The thing is, it wasn’t the detractors who were missing the point. It was the Lotus Notes guys. You see, e-mail is right at the heart of any groupware application. It’s the part of the application that users interact with the most. It’s where usability matters the most. And it’s what Notes got wrong the most.
Is TFS really that bad? I haven't used it or recommended it (mostly out of concern for cost), but 0% approval?
On a related note, I've been digging into Redmine the last few days to try to examine its suitability for a project that I'm taking over and new products that I'll be bringing online. I've been really impressed with it, even compared to the excellent Trac. Compared to Trac, Redmine just feels more well put thought out (i.e. native support for multiple types of source control systems, native sub-projects, so on) and the UI is a bit cleaner and easier to use. I expect to be blogging about it frequently in the coming months.
Lev Grossman has an article in Time this week (not available on Time.com) that pretty much hits it on the mark -- at least in my book -- with regards to The Cloud. I look kind of befuddled when people tell me we should do this or that on The Cloud or how their product is a Cloud solution.
Grossman lays into this in his opening paragraphs:
The best thing about cloud computing is that word: cloud. Telling consumers that their data is in the cloud is like telling a kid his dog has gone to doggie heaven. There is no doggie heaven, and your data isn't in a cloud. It's in a windowless, fortress-like data center somewhere in the rural U.S.
Cloud computing is just a buzzword companies use to describe what they're doing when they move data and processing tasks you're used to hosting on your personal computer onto their servers, which you can access via the Internet. It isn't new; far from it. It's at least as old as webmail services like Hotmail. It just didn't have a cool name back then.
Of course, The Cloud has its merits and convenience (for consumer applications) is surely one of those merits as is scalability (for enterprises and businesses); however -- as Grossman argues -- one of the biggest pitfalls of The Cloud is the lack of control over you data. Grossman continues:
But in some ways, the cloud is a step backward. It harks back to computing's primordial past, when everything was cloud computing -- dumb terminals connected to central mainframes.
The thing is, I'm not sure I want my computer to be just a device. Cloud computing goes hand in hand with another trend: the netbookization and iPadization of the PC, with its transformation into a beautifully designed but lobotomized device that relies on an Internet umbilical cord to do most of its actual computing.
As for me, from a development perspective I'm not too caught up in The Cloud hype. For most purposes, unless you really know that you have a hit on your hands, you can host your applications much, much cheaper on shared hosting for about $10/mo. which is still probably the best way for a small business to get started. And when you need to scale, well, hopefully, you'll have tons of investment capital at that point, too and you can just port your app to The Cloud.
Arstechnica has another feature on the aftermath of the Microsoft's game-changing Windows 8 + HTML5 announcement.
First, a quote:
The lack of broad platform support meant that Silverlight could never quite rival Flash on this front, but it was there, and it worked well on those platforms that were supported. With Internet Explorer 9, however, Silverlight took a back seat. HTML5 became the way forward. If Silverlight were to be used at all, it should only be used for those things that HTML5 couldn't do very well, such as streaming video. For anything else, the message was that developers should use HTML5.
Microsoft did have a point. If you're really wanting to target people on any platform, HTML5 is the way to go. For Web-facing applications that don't have any special needs such as DRM video, HTML5 is the long-term bet.
Excuse the smugness, but I've been saying this from the day Silverlight was released (you know, because it's basically Flash and we all know how everyone loves the Flash website experience...). It's plain silly to suggest using Silverlight for anything other than an intranet environment where DHTML could do the job.
While Peter Bright opens the article with a discussion of the teeth-gnashing that many Windows platform developers are going through, I -- for one -- could not be happier that we'll finally see HTML5 on the desktop. I think it's a beautiful thing Finally: the richness and variety that we've seen in web based applications will manifest on the desktop because the skills and techniques that folks have used for over a decade to build beautiful web applications will now finally translate.
However, I do disagree with a few points that Bright makes:
Where Silverlight programs can deal with buttons, icons, list boxes, tree views, and other interface controls, HTML5 applications must generally deal with boxes of text, with no higher-level concepts to work with.
There are a few points to address here. The first is that -- obviously -- HTML has buttons and icons (<a class='icon'><img /></a>) The second is that, to a large degree, deficiencies in the area of higher level UI abstractions in the DHTML world have largely been handled by any number of open-source UI script and widget libraries which provide even better alternatives to those on the Windows native platform. jsTree is one example of an excellent tree view library that is incredibly rich. Third, having worked with tree views via DOM and tree views via WinForms and WPF, my personal feeling is that it is many, many times easier to deal with the creation, manipulation, and styling of HTML than it is with Windows forms controls. And finally, I believe that Bright misses the point of HTML+CSS; it's really not much different from the concepts put forth in WPF and Silverlight: that of applying visual styles to otherwise generic controls.
I also take issue with this assertion from Bright:
Another weak area for HTML5 is tooling. Design and development tools that work with HTML5 are not as developed or as robust as those that exist for Silverlight, making HTML5 development more complicated
Uh....HELLO?!? The term "HTML5" is a bit misleading as it's really nothing more than HTML4 with some new tags (and some new skills required to take advantage of those new tags). Why are current HTML tools insufficient? I'm not getting his point here as HTML development tools have been around for WAAAAAY longer than Silverlight or WPF development tools.
Bright closes the article with more doom-and-gloom and a bit of hope for going back to the good old days of the same-old, same-old:
The details aren't clear yet, but next time we'll take a look at the pieces of the puzzle we have, and we'll learn why Windows 8 won't be a HTML-driven horror after all.
Contrary to Bright's doom-and-gloom, I'm fairly optimistic and I really, really, really hope that Microsoft sticks to its guns here. I can't be the only person who, while working with WPF, longed dearly for a jQuery-esque framework to traverse and manipulate XAML the same way that jQuery enables in web applications. I can't be the only person who's turned to using the WebBrowser control in Windows applications from time-to-time because it offered the simplest way of handling complex document layouts and, in some cases, interfaces that would require developers to resort to low level drawing of rectangles and custom painting of the UI controls and dozens to hundreds of lines of code that could be accomplished by HTML in a few lines of markup.
As a developer who has worked with DHTML, WinForms, and WPF, I -- for one -- look forward to an HTML5-on-the-desktop future.
PS — Is it just me, or are MS developers -- generally speaking -- a particularly whiny bunch that can't handle radical shifts in technology or methodology very well because Microsoft and Visual Studio has been holding their hands and enabling their ineptitude for so long? The comments on that Arstechnica article shows the straight FEAR that this news has instilled in the hearts of those legion developers. I love it.
A couple of commenters hit it right on the mark:
slogger: If you have a CS degree and you can't functionally use a new language within a couple months, you fail and are worthless. Switching to preferring some sort of JS API is hardly the end of the world.
jaman4dbz: First of all: Man up MS developers. This is why you should pay attention when you get your formal education. If you did you can switch languages easily. The language and libraries should not matter much.
Maybe now all those retarded MS developers can learn some theory, rather than what buttons to hit in their program maker.
deet: Nobody's talking about using HTML to write drivers, for fucksake.
One of the huge problems of WPF/Silverlight is that they're very *low-level*. WPF doesn't have a sane styling system. In fact, styles are implemented as effectively side-effect laden getters+setters. This means it's quite hard to separate the content and behavior from the presentation.
WPF comes with a widely-used grid-based layout scheme (as opposed to HTML's tables). This is nice in some ways since it's easy to precisely specify where something goes on that grid (i.e. it's low-level). It's a terrible pain to use by hand however, since grid-alignment is done by row/column *number*; moving things about generally means renumbering everything.
WPF/Silverlight as general UI-specification language, I'd say: good riddance. And as a special-purpose tool to make particularly intricate, tightly controlled UI's? Well, it's not disappearing, is it; if you want more control but with helpful automatic layout system to do the basics, WPF/Silverlight will still be around.
This comment by bouncing deserves its own shoutout:
Hmm. Peter Bright makes an interesting case.
In fact, a crack team of usability experts, computer science PhD candidates, and Seth Godin impersonators recently compiled an exhaustive list of native apps which are, to any reasonable observer, far superior to web apps:
- Various CAD programs
Although only two native Windows apps that do not suck were ever found, researchers believe the third "non-sucky .exe file" may one day be discovered. Unfortunately, locating the mythical trifectapp has proven a daunting task, as finding it requires digging through tens of thousands of incredibly crappy, hard to use, slow, confusing, mind-numbing, rage-inducing, serial-killer-inspiring "line-of-business" apps that IT managers force their interns to use on their behalf after booting a USB thumb drive flashed with a version of Windows 98 that's compatible with the version of Microsoft's far-superior C++ libraries the IT department develops on.
Perhaps Peter Bright, who wrote this passionate defense of the unnamed third native application which does not suck will tell us as to what, if any, business application is better in native Win32 than HTML 1.0. While he's doing so, a 22 year-old Ruby programmer will create a superior product using "primitive" technologies in exactly 1/100th of the time it takes a team of Certified Win32 Development Professionals to follow a stack trace in Visual Studio.
VoodooTrucker: Is JS as mature as C#? No way. In fact its totally painful, which is what I think developers are afraid of. No strong-typing, no obfuscation, no refactoring, no generics, no direct casts, no direct disk access, minimal properties, no LINQ, no IEnumerable, no interfaces, crappy inheritance, crappy dictionaries....
Badass? Most definitely.
Now I'd be way more impressed if those monitors were 30-inchers.
That's gotta hurt:
Windows Vista is Windows ME
Part 2. It took five years to develop because three of those were spent
building a brand new code base that didn't work at all and wound up
getting scrapped, and the remaining two were spent just tweaking the XP
code base. Almost all the features we were promised early on were
discarded and what we end up with is a warmed over Windows XP that
doesn't even do us the dignity of working properly out of the box. I
think it's particularly telling that they've already announced the next
major Windows release for late 2009.
Not everyone can appreciate the simple elegance of the ethereal structure that we know as the Internet. It is not the average person that will sit and contemplate the transmission of data from one node to another, thousands of miles away in mere milliseconds, and be impressed and appreciative of the amazing times we live in (I mean, just 20 years ago, you had to actually walk into a store to buy porn (*aherm*...not that I know anything about that)).
Most people are just happy that they can log on in the morning and get their mail in Outlook or check the weather on their local news sites, never taking a moment to bask in the glory of the immense amount of data that flows through copper, fiberglass, and the very air that we breath (isn't it weird to think that right at this moment, several megabits of data are probably bouncing off of me (or worse, passing through me (and you!))), each picosecond.
But then again, not everyone is a software engineer.