ATTENTION: This blog has moved to a new location. Please update your bookmarks, browsing habits, and aggregators.

	Tuesday, April 22, 2003

Visual Tools vs. Coding This post (and this weblog) has a new home. With WS-BPEL going mainstream and a corresponding upswell of interest in executable business processes, the choices between coding, modeling, scripting, and visual design are going to be presented to many potential technology adopters.  There are valid arguments for any of the above with the complexity of the deliverable, the skills of the target users, and the degree of obscurity of requirements all bearing on what the "right" choice would be. My experience has been that a mixture is best.  (The maxim "One size fits none." is apt.)  High-level modeling at the outset of a project to facilitate communications and extract requirements.  Identification of available technology assets and some initial work in low-level Java or other languages to wrap those assets as deployable resources (e.g., JCA adapters or components for a visual design environment).  Visual assembly of components and objects into processes with scripting and some light custom code to fill the gaps.  In an ideal world, the executable visual artifacts are identifiable as more detailed renditions of the original high-level models and provide value as a mechanism for inspection and incremental modification. For visual design of executable processes, the oft cited and touted benefits are strongly dependent on the objects on the canvas, the mechanisms of combination and composition, and the means of deployment.  This is true as well in service-oriented architecture, where the selection and sizing of services as well as communications and wire protocols determines the level of benefit provided to the adopting organization.  For web services orchestration and web services, the issues of sizing in the design environment and sizing in the execution environment coincide. With over three years invested in building visual programming tools in and for Java, FiveSight is not new to the visual programming space as far as process execution, web services, etc. goes, but in the grand scheme of things, we are absolute newbies.  The reason being that the concept of visual programming is not at all new. The first dataflow tool dates from 1965(!), and reasonably useful languages, e.g., ProGraph have roots back in the early 1980s.)  From the time that we launched the first version of our product in early 2000 to present, we've worked our way through a variety of different paradigms (data flow - like an electric circuit, control flow - like a flowchart), levels of representation (more coarse, more fine), fanciness of wizards, and different contracts for types and objects that can be used in the design environment.  Throughout, our experience has been that there is an economical object size for visual widgets that varies by the customer and project.  In some cases, it's individual operations against an SAP implementation, in others it's high-level operations against a content management system (check-in/check-out of a document, approval/sign-off), in others it's wrappers around scripting constructs such as XSLT or XQuery.  Ensuring that a product provides a good variety of starting points and hooks for extension at different levels is the responsibility of the vendor in designing the software.  Ensuring that a project selects and works with econonmically-sized objects for its goals is the responsibility of training and implementation support. For the low-level developer, visual tools are also useful as a point of aggregation for information derived from an existing or evolving codebase.  One of the coolest visual tools for Java that I've seen recently is Code Logic from LogicExplorers (although an evaluation version that's usable for 5 minutes at a time isn't much of an evaluation version).  Small Worlds is another personal favorite.  I don't expect to be programming a la Tom Cruise in Minority Report anytime soon, but I wouldn't mind. 7:10:43 AM