Better Way for Workflow Design in Orchestration and Automation?

In my last article on orchestration, I talked about the issues with the current workflow design. Although intuitive and easy to get started, it’s really inefficient and hard to handle for complicated workflows. A natural follow up question is, “is there any better way to design workflows?”

Like everything else, there is hardly an approach that is better than others in every aspect. The alternative approach, coding, may not be as intuitive as the visualized flow chart approach, but it’s highly productive. So the quick answer for the above question is yes if you can combine them together.

Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.

Of course, you don’t want users to design a same workflow twice with flow chart and coding. On high level, either flow chart or coding is just a view of underlying workflow model that are bound by a schema. If you make a change with one of the views, it has to be seamlessly reflected in the other. Then, you can use drag-and-drop flow chart while getting started, and switch to text based editing/coding afterwards when you get familiar and want to move fast. Even you mainly use editing/coding, you can sometimes switch back to flow chart for a high level visualization.

It may sounds too good to believe. It would surely take more time and thoughts to make it happen. A similar idea has been used in Eclipse IDE already.

As you may have known, Eclipse IDE has a great extensibility framework on which you can build plug-ins [BTW, VMware borrowed the same idea for its vSphere Web Client]. For each plug-in, there is a configuration file, plugin.xml, which defines extension points.

When getting started with the plug-in, developers use form based GUI. After a while, most developers switch to the pure xml text editor for most of the work. My personal experience is the xml editing is much faster than clicking through the GUI. I do switch back to GUI after editing mostly for validating my free editing.

Here are the two screen shots that better explain what was talking about. The first is the form based GUI for adding extensions; the second is the pure text editor for plugin.xml file.

Following the same idea, the orchestrator can provide a pure text editor with which developers can modify the workflow model file. The risk there is what if a developer breaks the schema with invalid keys and values there. It should be easily taken care of with error checking. The bottom line is that it does not get saved unless it’s validated.

I know it’s not as easy and simple as the plugin.xml in Eclipse IDE. But I think it’s a must have for better productivity, and whoever gets it done in product will surely have enormous advantages over its competitors.

This entry was posted in Software Development, Virtualization. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. Posted May 28, 2013 at 11:31 pm | Permalink

    Better Way for Workflow Design in Orchestration and Automation? (DoubleCloud)

  2. Posted May 29, 2013 at 12:11 am | Permalink

    Better Way for Workflow Design in Orchestration and Automation? (DoubleCloud)

  3. Posted May 30, 2013 at 3:44 pm | Permalink

    With so many drag and drop programs less people are getting involved with coding because it can be a very time consuming process especially if you are not an expert.

  4. Posted May 31, 2013 at 4:51 pm | Permalink

    Good point Alex. GUI with drag and drop is always easier to get started with. Most people will find it not as productive as coding(scripting) for repetitive tasks once they become experts later.

2 Trackbacks

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.