Process Visibility

"Succeeding at process optimization requires a user to have unrestricted visibility to all process elements, their relationships and how those have changed over time."

The preceding is a quote from one of Lombardi Software's training manuals, and I think it highlights a key guideline for architecting successful applications in a Service Oriented environment (Obligatory disclaimer: I work for Lombardi, but the opinions and ideas expressed in this blog are my own).

If you can't see it, you can't fix it.

"It" in this case refers to any of the activities or services that must be performed in order to successfully complete a Business Process.

In a SOA environment Services are not generally created for a specific Business Process. Services somewhat mirror their real-world namesakes... Businesses seldom provide a Service that is only of use to a single customer (unless that customer is very, very important).

In a similar vein, Services are seldom unadvertised. Generally speaking, the ROI for developing a Service is closely related to the number of customers who consume the service (which is why advertising is crucial).

I recently worked on a project that required delving into employee details that were spread across LDAP and a relational data base. Much to our chagrin we were far into the project before learning that a WebService provided all the data that we needed in a one-stop shop (so to speak).

If you don't know that it exists, you can't use it.

The bottom line in Business Applications is to get the job done in as reliable and efficient a manner as possible. As experience is gained and external conditions change, the procedure for "getting the job done" may change.

The Holy Grail for Business Programmers is to never be the limiting factor for how quickly the business can adapt... Actually it's beyond that... The ideal Business Programmer should be able to help the Business Analysts know when and how to adapt.

Business Applications do not require fancy and finely tuned User Interfaces... They require effective User Interfaces that can be quickly adapted when the business process needs to change. Sadly, many well-meaning Business Analysts focus more on the aesthetics of the applications that they want rather than on the business tasks that the application supports.

If elements of the UI don't closely map to Process Steps, then it probably won't be easy to change the UI when the process has to be changed.

Back when OO first came into vogue many UI developers made the mistake of tying their UIs too closely to the underlying objects. While this is not always a bad thing, as is evidenced by the popularity of NakedObjects, it often led to quite unnatural interactions between users and applications (unnatural from the human's perspective). We could make a similar mistake by tying a UI to closely to a Process Step... but it's a risk worth taking.