robgillen.Blog()

In a number of the posts I've been writing on the SOA/BPM conference I've referred to the applicability (or lack thereof) of a given approach to "the problem set" that I'm currently working on. I thought it might be good to describe what it is that I'm looking for and a little bit as to why.

I'm working at an organization with roughly 4,000 employees that is in the process of "drinking the MSFT Koolaid". We are deploying nearly every MSFT product and working hard to bring consistency to the platform both from a services aspect as well as the development paradigm. We are focusing on SAP backend, SQL data store, and SharePoint/Office Suite front-end.

We are also focusing on bringing a consistent story to the workflow problem, and, by "workflow" I really mean (well, at least for the purposes of this post) business process. We have business processes in SAP that have workflows behind them and use various means of interaction to keep it moving (i.e. nag-mails, etc.). We have similar workflows in SharePoint for document approval processes and the like. We also have a third set of workflows (business processes) that are either not automated at all, or not in any sort of consistent interface. It is this last set processes that I'm trying to "fix".

I have a couple of "rules":

1. The interface must live in SharePoint (at least the end-user facing portion)
2. The "workflow" aspects of the system should utilize one of the two existing execution engines we have running (SAP or WF in MOSS)
3. The workflow designer should be comfortable for a business analyst to use, and preferably an extension to a tool they are already using (i.e. Visio add-in).
4. The workflow designer should be able to map actual requirements to the steps in the process (where applicable) and serve as a documentation source of sorts.
5. The process execution system must provide a webparts (or at least the ability to expose the data as webparts) for the following scenarios:
   1. Overall health of the system
   2. Current user's workflows currently in action
   3. Visual representation of a given workflow process
   4. Analysis relative to the execution stats for each workflow instance and type
      1. i.e. X step of workflow Y is over the planned duration without having completed. Some indication should exist that this process is out of line
      2. i.e. Workflows of type X average Y days with the minimum being Z days and the maximum being T days. (and trends over time)
6. There must be a hard link between process definition and process execution. The File | Print approach is not sufficient
7. The system should be standards-based. Meaning, I should be able to import/export the workflow definitions (at least at some level of granularity) to an industry standard such as BPEL or BPMN in order to be able to share or compare that process with other organizations.
8. The system should be able to provide governance over the models.
9. In all aspects possible, the system should provide a consistent story WRT the development paradigm we have selected (MSFT .NET, ASP.NET, Windows Workflow, SharePoint, etc.).

Reality...

1. I'm not exactly certain I'm ready to back down on any of the items above, however I'm coming to the conclusion that there may be a need for a "third" execution engine - meaning, all of the vendors that I saw that had platforms that did what I wanted, either used their own custom execution engine or hosted their own instance of WF separate from MOSS. Even MSFT pushed BizTalk as the "main" process execution engine for *serious* workflows.
2. If reality point #1 is in fact true, the process execution platform should be based on WF allowing the developers to have a consistent development paradigm.

General Development, Conferences soa, bpm

The sixth session I attended was entitled "Next Generation Business Applications" and was presented by Mike Walker of the Architecture Strategy Team (MSFT).

This presentation dove-tailed nicely with the one I had attended earlier that day on the human aspects of SOA/BPM. The real gist of this session was to challenge the user to reconsider the requirement to write distinct user interfaces for each of the applications he/she is tasked to build. In much the same vein as the earlier talk, he was encouraging us to think of ways to expose the user-facing aspects of our applications in the context of applications that the user is already familiar with, such as using the OBA approach and embedding the application in a common productivity tool such as Word, Excel, or PowerPoint. The point being, that the less you force you user to "learn" in order to use your application, the more likely they are to use it. Further, the user doesn't really give a hoot if your application is fully SOA compliant and uses your best-of-breed enterprise service bus, and blah, blah, blah... They care about, does it work. What do I have to do in order to do my job. Tell me that, let me do that, and then leave me alone. and... that's not altogether a bad view of things.

The point is not that OBAs, or "Composite applications" are the only way to go, but rather that it should definitely be on our "radar" and should be considered (at least) prior to beginning to build a full UI.  Another take-away from this session was the fact that the more consistency you can drive in your applications (or, more importantly across your applications), the better off you are. Building a "unique" or "fully custom" user experience is not likely a good thing.

Conferences soa, bpm