Radar Networks has announced their “first mainstream semantic web application”, called Twine. It looks to be an intriguing blend of some of the elements of wikipedia, facebook, and a sprinkle of digg and del.icio.us thrown in for good measure. You can see some screenshots, and get a better overview over on readwriteweb. (Twine is currently pre-beta)

It’s a hosted service, that allows for people to create semantic structured web content around themes and topics, called twines. (In some ways, it reminds me of squidoo, too.)

I’m not going to stick my head in the flamebox that is “the semantic web”(because I know Dean is working on that post), but I will say that I really like the way that twine is shaping up to manage relationships with entities other than people. If the semantic web can deliver this in a meaningful way, I think we’ll all be a bit happier.

(But the “Web 3.0″ moniker makes me cringe. I can’t help it. And I’m all about the buzzwords, too…)

Continue Reading

Well, it happened a lot sooner than we thought, but infovark has made the front page of Joel On Software:

Dean and I were at Crystal City yesterday to hear Joel talk about the new features in FogBugz 6.0, which looks like a great product.

My favourite feature was the evidence based scheduling, which uses the history of individual developers estimating accuracy to calculate a series of projected shipdates and probabilities, shown in a fancy AJAX chart. Feature/Schedule tradeoff decisions have never looked easier than they did on the big screen yesterday.

Kudos to the Fog Creek team for bringing a whole lot more reality into the software development process, and for building a system so easy that developers might actually use it.

Continue Reading

Jim McGee has a well worth reading post about emergence and its importance in enterprise 2.0. He contends that:

“In some respects, “emergence” is a fancy organizational development word for “messy.” The more our systems must deal with the complexities of the real world, the messier they must be to accommodate that messiness.”

There’s definitely some truth to this. Part of the appeal of these “2.0″ technologies comes from the fact that they are easier to adopt and less rigid. The innate flexibility of tools like del.icio.us and flickr is an important part of their acceptance and appeal. Billy Cripe also weighs in with his idea of where to find the ROI in Enterprise 2.0:

“Don’t be a hammer looking for a nail. Someone “implementing Enterprise 2.0″ is either too high up to understand what problem is being solved by a particular approach or simply wants to impress with the latest buzzwords.“

Both of these points got me thinking about how best to define emergence and Enterprise 2.0. In order to fully understand this notion of emergence within the enterprise, I thought it might be worth taking a look at a few different models of “Enterprise Software” and how this concept of emergence affects their ability to actually improve the way that an organization functions. As an example, let’s take the following enterprise:

Figure 1: An enterprise of people with no necks.

This typical organizational hierarchy consists of various layers of management and knowledge workers performing tasks. Some of those tasks require software that is only used by specialist teams. For example, an ERP accounting system like SAP or Great Plains requires training and subject matter expertise to use effectively. Systems like these are a critical part of the modern enterprise, but they aren’t emergent, nor are they designed to be emergent. There’s not much, if anything, that additional flexibility, or ‘messiness’ can bring to this aspect of an enterprise. (If del.icio.us only allowed me to bookmark my favorite financial transactions, I doubt it would have the same appeal…)

Figure 2: Adoption of an ERP tool within an enterprise.

 

So we probably aren’t going to see things like Great Plains, or SAP Financials implement a bunch of Web 2.0 features (unless they get really caught up in fad-thinking).

However, not all enterprise software works like this. There is a class of enterprise software that requires that it be adopted by the whole organization. Because of my background, I think automatically about Enterprise Content Management, but the same is true for groupware like Notes or Outlook, and to a lesser extent, for collaborative systems like eRoom or SharePoint.

Let’s use the ECM example. In any organization, people have systems for managing content. Most of them suck, because they are messy, ill defined, inconsistent, and often made up on the spot. So far, the only approach to solving this has been to implement a new, improved, well defined content management system. Of course, this only really becomes effective if you can implement it across the whole enterprise – otherwise you’ve just added yet another method of managing content to a messy, disorganized enterprise. So the goal for something like ECM is this:

 

Figure 3: The Ultimate Goal of ECM (that’s what the E is for)

 

Anyone who’s tried to deploy an ECM system to an enterprise knows that this is no easy feat. In fact, I can’t think of a single enterprise where this is true. (Although I’m willing to entertain the possibility that one may exist. Maybe some of the ECM Bloggers like James and Laurence can set me straight.) In my experience, most efforts at deploying ECM within an organization end up looking like this:

 

Figure 4: What lots of “Enterprise” Rollouts really look like.

How did we get here? The system was sold to someone in middle management with purchasing authority, who encouraged his direct reports to use it, and maybe they did, and maybe a couple of other teams somewhere along the line jumped on board, and maybe Harold from Accounting moved teams to HR, so he uses the ECM system properly, even though his colleagues still plonk everything onto a share drive… and so on. You get the picture.

This is precisely the problem that Enterprise 2.0 can solve.

The traditional approach is to build something autocratic, and deployed from the top down, that works along vertical reporting lines. Working this way, silos of information are preserved. and communication is kept within the traditional areas.

The emergent approach is work from the bottom up, in a manner than allows the system to spread virally along horizontal functional lines. By making the system less restrictive, and easy to use the system is more likely to become the solution of choice for knowledge workers. And as they communicate better, they share information and increase their awareness.

Figure 5: An Emergent system, on the path to Enterprise 2.0 domination

It’s very elegantly explained by Euan Semple, discussing the quickest way to ‘do Enterprise 2.0′:

“Do Nothing! And then your bright, thoughtful and energetic staff will do it for you. Trouble is they will do it outside your firewall on bulletin boards, instant message exchanges personal blogs and probably on islands in Second Life and you will have lost the ability to understand it, influence it, and integrate it into how you do business.”

So, in an enterprise context, does ‘emergent’ have to mean ‘messy’?

I don’t think so. For a system to be emergent, the emphasis needs to be on how quickly the users will adopt the system rather than on its structure. That explains why a hallmark of these Web 2.0 technologies is that they are accessible and less restrictive.

I don’t think this notion necessarily precludes systems that offer a traditional structured approach to enterprise information, but it does mean that if your notion of “best practices” don’t ‘t fit perfectly with your users are actually doing, you will find that your enterprise solution won’t emerge very far at all…

 

 

Continue Reading

I enjoyed reading the Socialtext response to Assembla’s piece on why distributed teams are great.

When it comes to distributed teams, I’m more in the ‘suck’ camp, than the ‘rule’ camp.

From my perspective as a developer, and a manager of development teams, I think that the biggest problem with distributed teams is idea decay.

Once somebody has a thought in their brains, most of us need to get it into another brain quickly to validate it. The quickest known route, even in our super connected “universe 2.0″ is:

brain>mouth>ear>brain.

Instead, if you have something like:

brain>fingers>keyboard>XMPP>monitor>eyes>brain

there are too many connection points. People seem to somehow sense that they are more inhibited, and they don’t end up sharing as much. Or good ideas seem to never make it across the wire.

This is a challenge for people who are making software – but it’s also more of a challenge for people who are developing business systems. As good as the latest collaborative tools may be, they still aren’t close to co-location for maximizing the innovative process.

When you’re trying to figure out the best way to solve a business problem, it’s probably worth bearing this in mind. (like lots of nerds, I automatically try to solve problems with technology. Sadly, sometimes – low-tech is better : )

Continue Reading

For most people, the use of the nominative plural pronoun (‘we’) tends to refer to themselves and to the other significant people who happen to be sharing their lives.

If you work for a company, or any kind of collaborative venture where there are multiple people working towards a similar goal, you’ll find that you use the word ‘we’ an awful lot. For example ‘We need to refactor that code, and we should probably add some comments’ or ‘We need to get our TPS reports done by Monday’.

I think that the use of the word ‘We’ is one of the nicest things about being at work. That one little word indicates collaboration is occurring. It shows that you accept some joint responsibility for your success (or failure), and it reminds you that you’re all in this together. Whenever you start a new job, or a new project, the first few times you say it, you notice that you just said it. It’s a thing, at first. Then it quickly becomes part of the corporate vernacular, and you aren’t as aware of it anymore.

Personally, in the last five years, most of the time I said ‘We’, I was referring to TOWER Software. TOWER make a well regarded ECM suite called TRIM Context, which is designed for the government and highly regulated markets. After 5 years, I decided that I was brave/crazy enough to try something on my own, and was fortunate to find a kindred spirit in my TOWER Colleague, Dean.

And so for both of us, Infovark is a new kind of ‘We’. We‘re a small startup based in Northern Virginia, who have a vision for changing the way people work together.

Anytime somebody says ‘We’, we want Infovark to be there supporting them. To make it easier to share information. To help them make decisions. To help them get to know each other. And to take away the burden of complex, enterprise software that is hard to use and understand.

It’s an ambitious goal, but it’s one that we’re utterly committed to.

And so, it starts! We hope you’ll stick with us, and share the journey.

Continue Reading