Beyond Chat: Re-engineering Social Networks for Collaborative Enterprise Execution
Collaborative management of applications in enterprise social networks
The paper introduces "CollaTo" (formerly Unity), a specialized Enterprise 2.0 social networking platform designed to facilitate Social Business Process Management (Social BPM). It utilizes an extended social network data model to support role-based responsibility delegation and data-driven application composition, enabling the execution of complex business tasks within a social interface.
TL;DR
Social networks in the enterprise have largely been "water coolers"—places for talk but not for work. This paper introduces a framework to transform these platforms into Social BPM (Business Process Management) engines. By extending the social data model with "Responsibilities" and a data-driven application registry, the authors enable users to execute complex, multi-stage business processes (like university graduation) directly within a social stream.
The "Orphaned Task" Problem in Enterprise 2.0
The "Enterprise 2.0" vision promised a synergy between social collaboration and business efficiency. However, a gap remains: while we can chat about a project on Slack or share a document on SharePoint, the actual execution of business logic—triggering services, validating credentials, and cascading tasks—usually happens in siloed, rigid legacy systems.
The authors identify three critical pain points in existing enterprise social tools:
- Rigid Roles: Most systems assume a user has one role, whereas real-world tasks often require temporary "responsibilities" (e.g., a substitute signing a contract).
- Manual Coordination: Users must manually figure out which application to run next to complete a workflow.
- Data Isolation: Applications inside social networks coexist but don't talk to each other; they cannot consume each other's outputs to form a chain.
Methodology: The Social BPM Blueprint
To bridge this gap, the researchers evolved the Unity Framework (now CollaTo) using two strategic architectural shifts.
1. The Responsibility Abstraction
Rather than binding application execution rights directly to a user's role (e.g., "Student" or "Professor"), they introduced the Responsibility entity. This allows for fine-grained control where specific individuals can be granted temporary powers regardless of their permanent rank, mirroring the ad-hoc nature of corporate projects.
2. Data-Driven Application Composition
Instead of hard-coding "App A leads to App B," the framework uses an Application Registry.
- Input/Output Mapping: Developers register applications with defined semantic concepts (e.g., "ThesisID").
- Dynamic Discovery: If App 1 outputs "AccountStatus" and App 2 requires "AccountStatus," the system automatically links them.
- The Application Stream: Unlike typical user streams, this specific stream acts as a data bus where applications "post" JSON-formatted results that other applications "read" to trigger their own execution.
Figure 1: The extended ER diagram showing how Applications, Data Concepts, and Responsibilities are decoupled from the standard User-Role model.
Real-World Validation: Academic Workflows
The system was tested at Harokopio University of Athens to manage the Student Graduation Process. This is a classic "wicked" workflow requiring clearance from the library (no overdue books), the registrar (credits completed), and the department (thesis submitted).
By using CollaTo, the student doesn't need to know the workflow. They simply see a "graduation" dashboard. When the Library Officer executes the "Clear Record" app, the output is posted to the Activity Stream, which automatically unlocks the "Submit Application" app for the student.
Figure 2: The dependency graph generated by the system, allowing administrators to visualize how ad-hoc applications chain together to complete a business goal.
Critical Insight & Future Outlook
The brilliance of this approach lies in its Inversion of Control. Instead of a central BPM engine forcing a process, the data produced by social participants drives the process forward organically.
Limitations & Next Steps: The authors admit that Semantics remain a hurdle. If one developer names an output "UserID" and another expects "Member_No," the composition fails. Future work involves integrating semantic web technologies (Ontologies) to allow for fuzzy matching between applications.
Conclusion
This paper pushes the boundary of what a "Social" platform can be. It suggests that the future of the enterprise is not just "socially aware" but "process-integrated," where the boundary between a status update and a financial transaction becomes invisible.
