March 8, 2010 8:45 AM

There was a question the other day by some folks (in the Enterprise irregulars) about the capabilities and the pitfalls of modeling and code generation -- something that's been dear to me since the 1980s. We have definitely moved the ball toward the goal, but there is still a long way to go.

EDS actually wrote quite a bit of model-based and model consuming software back in the 1980s. There were also some fairly powerful VAX implementations of CASE tools  (software through pictures was one) and some fairly lame mainframe based solutions (e.g., Telon which is now owned and maintained by CA and is hopefully much better). Here is my off the cuff response about model based efforts:

A couple of areas of concern:
1) lock-in: EVERY tool I have ever seen has been proprietary in how it stored its models and the company that created the modeling software  (or at least the project) has been on the edge of being canceled. When that happens all the code generated is relatively unsupportable (at least at the level of productivity expected when you bought the tool)? Will you move the model to another tool manually???
2) standards: there are a number of standards (e.g., BPML and BPMN) for modeling and they continue to churn every year. Just because you modeled in today does not mean that it will be as valid in a couple of years and will likely need to be reworked every few releases, since the generating software will advance.
3) level of automation: The question for me is: "Will the tool actually model the issues that are causing the organization pain over the long haul." or are they modeling something that is done once and unlikely to change? Does it support round trip engineering??  It is relatively straight-forward to model the generation of the user interface or the data connection, but what about 3-5 years from now? Is that are of the environment likely to change the most and need increased productivity to address the change? Basic modeling advances as products advanced as well --many of the capabilities of MS Access today (or even IDEs like Visual Studio) exceed the capabilities of the CASE tools of the 1990s. Each generation of a development environment tries to improve code creation. Few do anything about maintenance and yet that is where the most significant costs of the product life cycle reside.
4) Some developers hate it: modeling business processes is not what they signed up for. They want to solve technical problems, not business problems. A business analyst uses modeling tools.
5) Modeling makes certain assumptions that support the abstraction.  If the problem does not fit the assumptions, then the solution may be more difficult and less satisfactory.  You can't design an electrical system with a mechanical engineering CAD tool.

On the other hand there are tremendous needs to be addressed:
1) Software creation is expensive: Taking the people out of the development process limits the need to take work off-shore. Modeling tools increases the communications conduit significantly between the developer (modeler) and the customer. This should reduce the depth and breadth of rework. These tools are part of a strategic approach to addressing the high cost of code creation and maintenance.
2) Software creation is error prone: Automatically generating the code should significantly reduce the number of errors since the software will be generated the same way each time.
3) Software creation is increasingly complex: A code generator can crank out WSDL and read SOAP quickly and portray it in a visual context for most developers much better than staring at XML will ever allow. Most developers are near average and average developers may not handle the complexity of today's enterprise environments -- especially as we move to parallel processing in the cloud. Mere mortals don't write code for many cores in the 3rd generation language.
4) Modeling can enable applications to survive technology change, so the code can be re-generated when the supporting technology is upgraded or the application is transferred to a new platform.
5) Modeling opens the door to automated analysis at a higher level, so the modeling tools can have built-in assists and quality checks.
6) Modeling usually provide better support for rapid prototyping and collaboration on the solution with the customer.

I am sure there are a number of others aspects of the issue that I've left out.

Originally posted on The Next Big Thing blog

Blogger Profile: Charlie Bess

Charles Bess has worked in the Information Technology industry for about 30 years supporting a variety of large organizations and industries. Charlie has performed a variety of formal and technical leadership roles throughout EDS and now HP. He is a licensed professional engineer and in 2002, a senior member of IEEE and was recognized as a Fellow within HP for his focus on value delivery and innovation. Currently he is focused on the Chief Technologist functional relationship between HP and its largest clients. In addition to these activities, Charlie has also worked as a public speaker, advisor to SMUs MBA program and supported engineering and computer science activities at Purdue University and University of North Texas. He’s been blogging on technology and business value related topics since early 2003.

Posted by Sue Ansell at March 8, 2010 8:45 AM

Categories: General

Comments

CASE Tools email - http://case-tools.org

Great Article.

I think there are not silver bullet, there is not pitfall only a lot of faith wasted thinking that code generetation will be magic, is not magic and after the first generation, in general you are slave of a bunch of really pour code...

neither CASE tools or code generation are magic, its are just tools.

mike

TrackBack Link