In my experience, I have seen two classes of enterprise applications. The first involve those built on an application platform (like SAP, Oracle Apps, etc) – and the second that are fully-custom developed each time around.

For the first class of applications – there are about two or three ‘levels’. First, there is the application platform or infrastructure itself. This can include web servers, workflow engines, portal infrastructure, presentation & reporting engines, etc. Then come the pre-assembled applications based on this infrastructure. And finally, there is ‘content’ which can be loaded into the applications.

I tend to see platform & infrastucture upgrades as critical to ‘stay in touch with the times’.

Modifications to the applications themselves tends to fall along the lines of what you have written about. Basically – if you REALLY want to do it – then do so with your eyes open. There are rarely ‘magic bullets’ that will let you customize the application logic AND upgrade easily too.

Upgrades to the content make sense only you have not directly modified & repurposed the content to your own specific purposes. In cases where content is reference material, pre-built data connectors, etc – then the need for an upgrade path is clear too.

Regards.

I agree that outta the box workflow in sharepoint is quite basic. But its not to difficult to go deeper using sharepoint designer…or much deeper using visual studio and cutting serious state engine based workflow.

For my part, I would encourage integration with sharepoint, particularly the workflow capabilities. Workflow foundation, which backends is rohbust and has serious investment….it would be an easy soap integration imho. Just like your remedy integration…this would be a very serious value add……(remedy is not workflow…its ticketing of course)

In short, Stateful worklows can play a huge part in grc risk processes and I would argue that leveraging best of breed workflow like MWF with sharepoint integration should not be overlooked.