Infovark

I sat in on the enterprise architecture session on the third day of the Enterprise 2.0 conference. We spent much of our time in that session attempting to come up with shared definitions for core E2.0 concepts. Then we attempted to find where those concepts fit within a traditional enterprise architecture stack.

Here’s my definition of social software: Social software is software that incorporates human behavior in its system functions. This contrasts with a traditional software engineering approach, which considers system users to be external forces that act upon software. Including human social factors in our software designs is a real challenge. You have to have a team familiar not only with writing code, but psychology, group behavior, organizational theory, ergonomics, aesthetics, and a wide array of other “soft” sciences.

But it’s not something new. Even in the earliest multi-user systems and groupware, software engineers have had to deal with the messy human element. Many of the business rules baked into enterprise applications have as much to do with corporate culture as with policies and procedures.

Er…Where does the Social Go?

So naturally the session attendees had a hard time trying to place the collaborative social elements into an architecture diagram. Corporate culture permeates all aspects of enterprise systems. You can’t point to any one place on the chart and say, “the social stuff goes here.”

(Incidentally, this is also why issues of security and identity management are so difficult. They are social constructs that cut across system boundaries. Like Enterprise 2.0 communication and collaboration technologies, they are both everywhere and nowhere.)

Stowe Boyd listed 10 suggestions for next year’s conference. I seconded his call for more participation from the social sciences. We’ll need help from designers, economists, psychologists, and practitioners from many other disciplines if social software is going to live up to its name.