Metastorm 9 : Development Productivity


Ok, so I’ve seen several forum posts and had a discussion with a fellow BPM Consultant this week about Metastorm 9 and two main ‘gripes’ that people have. Namely, the reduction in developer productivity against version 7 and the fact that version 9 now really requires you to be a developer and not just a business analyst. I wanted to provide some thoughts on these two:

Slow down in developer productivity

My colleague and several other developers in the community have commented on how many more button pushes are required to put together a functional process in version 9.  Now compared to version 7, yes you do have to click ‘into’ the product a few more times to apply some logic to a process, take the stage and action on start and on complete event handlers.  In version 7, these where two large free text area’s in the ‘do this’ tab of any stage or action.  You can could click on a stage and start typing (for those developer that knew the version 7 function syntax instinctively).  In contrast to this, version 9 requires a click on a stage, then a click on an event handler button, then the selection of a visual script activity (for example, assignment) and then the use of expression builder to make that assignment.  So a couple of extra steps.  I think what is being missed here however is the focus on re-use and overall maintainability.

Any Metastorm developer worth their salt has worked on a large project that has taken more than 6 months to plan, write and test due to either large processes or a number of smaller but more complex processes with many rules and alternative flows.  I have not long finished a 2 year project and if I could show you the amount of onstart and oncomplete code that is used and more importantly repeated, you would tell me that Metastorm was the wrong development environment to use. Whilst I agree, some companies run their entire operational application suite off of custom Metastorm applications, this client being one of them.  Now I can see that with all of their systems that maintainability using version 7 has become a nightmare, there are several full-time developers that are bug fixing as their day jobs. All because of the line by line syntax where no OOP patterns and principles can be used (unless you write the entire thing in Jscript.NET).  Important code support features like code dependency (knowing what may break if you change a variable value), automatic refactoring etc that make life so much easier with many development environments just don’t exist in version 7.  Finally I should mention the use of objects to represent business entities and the ability to loop these.  If you’re working with data, you’re looping it to run some row by row processing which again required extra programming in version 7 to accomplish (e.g. writing a static server-side method that takes a SQL statement and returns a dataset/datatable for enumeration).

My main point here is that yes there are a few more clicks in version 9 in accomplishing some goals, but the ability to reuse server-side code for assignments, create visual toolbox items for common process activities (thus avoiding writing code against a version 7 common stage with a bunch of conditionals attached as to only execute in some situations) and completely re-use visual scripts supports true OOP abstraction. You can edit the smallest part of a process to make a change and have everything else that depends on that code or visual activity be changed too.

When it comes to using version 9, you have to understand good design practices such as cohesion, low coupling, area’s of concern as well as OOP principles and patterns.  You have to look to the long term and understand that the OOP approach to designing processes in version 9 will mean longer term maintainability.  Anyone that has delivered a version 9 project (and I have) will notice that a good design is far more maintainable and will require less man power going forward than a version 7 procedure.  The design stage of a project actually becomes a lot easier too.

What is a few more clicks compared to putting together a solid consistent, sustainable and maintainable design? (and don’t get me started on the ability to debug in 9 and not in 7… how much time are we saving here?) The short term productivity does suffer, but only slightly and if you where to analyse the amount of time spent on a project long term, you might be surprised by the results.

You have to be a developer to create processes in version 9

Version 9 certainly has shifted its focus on to the developer.  You really have to approach the design of a process from a OOP perspective and use many techniques used in the design of a .NET application for example to properly plan and design a Metastorm 9 solution.  If you can not code C# or understand basic .NET concepts such as the heap, the stack, value and reference types, type conversion, type modifiers and commonly used namespaces such as System,System.Text,System.Data and System.IO namespaces then you might as well just close the application and take your lunch break.

In a way, I agree with this point but understand the move.  A custom Metastorm 7 syntax was never going to work long term in a world where open standards are king and compatibility is of major importance.  A Metastorm application at the end of the day is an application, it will execute in a business environment, handle possibly business critical data and need to be up most of the time.  Therefore it needs qualified designers (on paper or by experience, the latter generally being the most important) to design, create and adequately test the application.  There is nothing stopping a business analyst putting process actions and stages together using the ‘classic’ or basic process designer in version 9 and when they are doing so, it should be a must that the analyst collaborates with an experienced process designer who has a native technical knowledge but also understands how the functional requirements will translate into technical requirements, advising the best solutions to some of the most common process problems and bringing some sense to some of the more ‘out there’ ideas.

Some compatibility with a widely used modelling tool such as Visio would certainly reel the business analyst community closer, but in the age of BPM being an umbrella for many other technologies including Enterprise Systems Integration and Enterprise Content Management, the design of BPM systems is now at least 70% a technical field and I think the new version 9 product adequately represents that. If a client is going for a simpler process, then maybe Metastorm 9 is not the tool and they should be opting for a free open source alternative like bonita open solution.  I like to think that Metastorm 9 is not as ‘Fisher Price’ as it once was and is now a mature pure play BPM product.

Advertisements

5 comments

  1. Scott:

    Great post.

    Having used Metastorm from version 5.X to 7.X, I totally agree with your assessment of version 9.X. Prior to the availability of the Enterprise Class Library, which Metastorm has essentially integrated into the runtime, it was not really possible to create maintainable applications using Metastorm BPM.

    Please elaborate on the “good design practices such as cohesion, low coupling, area’s of concern as well as OOP principles and patterns” that is needed for a project using Metastorm BPM 9 when you have a minute.

    Stephen

    1. Hi Stephen. Thanks.

      I was thinking about writing a post soon that covered some application architectural points that I tend to use when putting any .NET application together, including using Metastorm 9. I’ve certainly learnt the hard way in the past (even with v7) about not creating a solid extensible design (at least a core foundational design that has been easily built on and plugged into during agile development iterations (or sprints)). I guess its the whole thing of closed/open (closed for modifications, open for extensibility).

      Anyway, it might get a bit technical but its an article I’ve been thinking about writing for some time. It also may also interest people in commenting on how they go about planning the architecture (i.e. layered) for their own Metastorm 9 (or .NET) applications.

      So your points, I’ll cover them soon!

      Cheers
      Scott

  2. I could not agree more. Thanks for the insight.

    One thing that is a kind of issue, is that Metastorm themselves do not seem to have a good understanding of what a paradigm shift it is for their customer base. That is disappointing, but I understand why, since the product was never widely used within the organisation while I was there (I fought to get the developers to use it!), and perhaps still isn’t.

    We have been concentrating on setting up good design practices with our customers and partners familiar with version 7. Many of them are very good Process Designers, but cannot write anything but very simple SQL, let alone code. The Visual Script idea is a great tool, and the best implementation of this technology that I am aware of, but it is still daunting for the non-developer.

    We have set up a good model whereby the Process Designers tell us what is required in terms of functionality, typically by using our ‘Task to do’ VS activity to describe it. We, as developers, then build the required VS activity or Expression Builder item in a Library, with all the ‘friendly’ help we can wrap around it. We also try to make the solution as generic possible to encourage reuse.

    In this way we allow the Process Designers to get on with what they do best, and we can get on with the coding and problem solving that we do best.

    It is, however, extremely important to design this right from the start. You can add the concepts to procedures migrated to v7 too, although it is much more work, but you still need to design well before starting. Measure twice, and cut once, as the carpenter would say.

    We have even built our version 9 training course as three distinct and inter-dependent modules for Developers, Analysts and Administrators, all based on this principle.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s