Right tool for the job

I picked up a post by Keith Harrison-Broninski on his IT Directions blog this morning. It talks about the use of collaborative tools and why they are fundamentally inadequate because of security and agililty to change.

Although Keith makes some decent points along the way, especially as he is leading somewhere over a series of post, I want to run with a counter argument.

My argument is that Enterprise collaboration tools:

• Secure your collaborative data well
• Enable flexibility for collaborative working
• Exercise users' minds, enabling them to make decisions in context
• Should not be used in business processes or with data not requiring collaboration

(1) BPM or collaboration
If you are talking a true collaborative world, where innovation thrives and structured business process is not a good fit, then avoid choosing tools like BPM in the first place. They are designed to enforce process and enforce inflexibility for several reasons:

• Compliance can only be achieved if you can demonstrate that a strict process was followed in every case (otherwise the auditors will tear you apart)
• Efficiency savings for high-volume tasks only come from the repeatability of the process
• Many business processes that choose BPM do so because after initial introduction and bedding in there is very little about the process to change - the decision making can (see James Taylor's Decision Management blog for more information) - but the process itself rarely needs to, since it often has a natural progression anyway.

(2) Collaboration around financial systems?
The ERP, billing system, etc follow strict rule for the reasons described in (1). These are rarely systems to be collaborating around in the course of everyday business.

Changing your ERP or billing system may have a serious impact on revenue recognition, or one of the other key processes you have identified, documented, remediated, tested and audited year on year for Sarbanes-Oxley (SOX). Tampering with it often makes little sense and will cost your company hugely to rework the compliance side of things - probably more than the team of consultants required to make the IT changes.

(3) Security of collaborative systems
Security of collaborative systems should be an issue - you are presenting corporate knowledge out to the web.

Enterprise collaborative systems typically provide the type of security that you would expect to see to keep data secure when presented on the Internet. This obviously includes security at a technical level for authentication, secure communication, isolation of data from attack (SSL, SSO, DMZ etc).

At a user level the collaboration tools provide role and group based security, enabling user administrators of your own workgroup to point and click to enable different access rights, available functionality, etc, for different groups and individuals, if these privileges have to vary from a default.

(4) SOA
SOA is a tough one. If badly thought out it can break every business process you have that your business depends on to survive, since there are many processes hardcoded into legacy systems. There has been discussion about this in many of the SOA and related blogs (e.g. Sandy Kemsley's discussion of SOA anti-patterns on Column 2) .

Making your backend systems available as services can free access to them so that authorized users can access them through a single UI (a portal) rather than a set of discrete applications. This adds flexibility and improved user experience for users performing free-flowing tasks. SOA also enables new, more flexible processes to be put in place, typical based on BPM tools, rather than collaboration.

Summary
In environments where collaboration is necessary, it is essential to give users the tools they need, otherwise they will invent their own approaches that lead to a completely uncontrolled workplace (see my post about this). This is not innovative, just dangerous. Word and Excel on users desktops are not collaborative systems - they are individual editing tools based around a file on a hard-drive.

In a truly collaborative environment there are few indicators to the system to enable it to make automated decision. Therefore to enable security, or select business process, you have to accept that there will be interaction required from users at all level - from the user administrator setting privileges for document access, through to the reviewer of a document to go and select who is best to read it next.

Without fundamentally changing the tools available to users, for example removing MS Word from the desktop and replacing it with something that does not yet exist, collaborative systems will be highly dependent on the judgement of the users.

In structured business processes, the business would collapse if you tried to artificially inject a collaborative model, so BPM is a great tool. Again, I believe that there is a place for collaborative systems at points within structured business processes. ECM vendors such as Vignette call this Case Management - it provides the structure of BPM, mixed with the acceptance that there are tasks in a business process where users must make decisions based on the context of work in front of them. I believe that we could go a step further than this, but that discussion is waiting for a quiet moment for me to write about it.

Final words: don't force collaboration, BPM or SOA into environments and processes where they are not suited. The use of these technologies is not a dogmatic decision. Use the best tool for the job.

Technorati tags: BPM SOA collaboration