The Future of CA Gen – evolution/revolution – 10 points to Utopia part 2
Looking back at this post – detailing 5 ideas for the future of the CA Gen product, where I thought about where CA Gen needs to go in the future, here’s the final 5 ideas that will see CA Gen evolve into a Next Generation Development Toolset.
Sixth: Complete Unicode support
Seventh: Evolve the action diagram syntax to cater for the new developments in technology, such as support for iPhone accelerometer sensor and tilt mechanisms, as well as new features appropriate to those new platforms. Maybe a common language for all CA development tools ?
Eighth: Offering a SAAS for CA Gen – difficulty in getting established resources to deploy and manage an encyclopedia and toolset should not be a problem – “Cloudify it” and offer a managed service to organisations, either as a partnership with Systems Integrators or from CA itself.
Ninth: BLOB and CLOB support needs to be there
Tenth: Wizards and tooling to “upgrade” existing technologies to use CA Gen, so older technologies could be modernized into CA Gen
There – I hope you have view on how CA Gen should develop in the future – please share them with the readership via comments – anonymously if you want – you don’t need to register and log in to share your views.
Cloudifying CA Gen Services would be a good option. There are many customers that are not aware of the CA Gen product or that CA Gen can be used to easily develop applications in Mainframe, J2EE, .Net easily and that it is a next generation tool. Also, the cost of the tool, finding programmers in this tool etc will take more effort [away] from the customers. If CA Gen can bundle all these and sell as Cloud Services it would be that much useful to the customers. Hence, for adopting this tool on a massive scale, it would be better would be better to provide it as a cloud compting services.
Much of what I thought about in the two previous posts can be realised in the way Estefan’s post described – the usage of Eclipse to extend the modelling capabilities and tools that CA Gen can use. These capabilities (I feel) should all centre around the model – by this I mean that to achieve all that both Danny and Estefan say, there needs to be a radical overhaul of the model – new properties, new relationships etc.
Some say that the model is already too complex – maybe it is, but the strength lies in its flexibility, but with flexibility comes complexity. There’s no reason why, at CA Gen 9.0, we can’t have a completely overhauled model schema – simplifying the 20+ years of additions and bolt ons.
Whilst its commendable for backward compatibility that nothing is removed from the model – maybe now is the time for some pruning to remove properties which are there for platforms no longer supported.
A new common metalanguage (as Estefan suggests) would also be good as would auto completion of code……
And ONE MORE COMMENT .. Those changes are fast and easy realizable .. Maybe at CA World 2012 .. CA Gen @eclipse could be reality..A very EXCITING thought
FUTURE OF CA Gen
As far as I am concerned CA Gen’s future is in Eclipse. Eclipse is THE platform for model based development. Eclipse has very powerful generation capabilities. CA Gen studio is the second step to this direction, which is because of the possibility of a bridging from toolset a very important one. The first step was the trace tool. The third step must be the migration of the toolset into eclipse. The pseudo code editor must be realized in eclipse as code completion component and must remain as the strength of CA Gen. CA should try to standardize the pseudo code as an alternative PIM language. All other features must be industry standards like UML etc… The next one is the ER diagramming tool. This must be replaced with a more modern one. Instead of writing the ER diagramming tool new for CA Gen an ER tool may be taken from the market. There are even open source eclipse ER editors, which are very appealing. The dialog windows, screen design must be done also with an open source editor or must be written for Eclipse as plug in from scratch. For process flow a BPEL tool can be used or an ECORE Editor can easily be written to accomplish the process flow and dialog flow parts of CA Gen. All other configuration are to be realized in eclipsein preferences or configuration panels. For the above mentioned tool parts also some UML diagrams may be used I.e. state chart machine for process flow. If you are once in eclipse you also have the ecore based metamodel such that you can define not only the existing CA Gen objects but also new needed objects in the metamodel. The other very positive impact would be the usage of other alternative modeling languages. Those are for example UML2 and even JAVA. The hand written JAVA code can be completed with CA Gen generated JAVA Code. The generation for Visual studio, I would solve with a plug in in Visual studio. It means, modeling is done in eclipse and start of generation from Visual studio and the results can be shown in build tool. Frameworks like struts can be used easily. The existing generators can be used as far as possible at the same time eclipse generation capabilities can be used for additional generations. The repository can remain the same or one of the existing products like cvs or subversion… Very important feature must be an open transformation tool to convert other systems into CA Gen models. Those are COBOL,PL/1,ADABAS… I would start a modernization incentive with CA Gen and try to get as many systems as possible into CA Gen new.
I THINK COOL GEN IS HOTTER THEN EVER…
In a brief response to Danny’s comment, what I’m proposing is storing all the artefacts relating to a system/enterprise etc WITHIN the model.
Model-based-development is powerful only when the information about the real-world is stored in the model-world. Dilution of that power comes when “bolt-ons” are applied, since the model of the world becomes then a model of a portion of the world i.e. the parts of the world within the model.
Retro-fitting additional capabilities and properties to an already existing model is a difficult (but surely not impossible) thing to do, but still should be achievable.
I agree with Danny when he says that we will lose an opportunity by focussing simply on platforms, whereas we should be focussing on development practices, then how we can bring those development practices to bear on technology platforms.
Concepts are key here – looking at how we model the real world and what things we need to know about the real world, then understand how we capture those things and how we then generate the physical implementations of those things.
Also, there does need to be a “nod to the deployment” – since with the best will in the world, there are technology constraints that need to be entered into the model such that they can be applied at construction time.
Considering the runtime – we should be aiming to reduce the reliance on a runtime, and increase native code generation, with sensibly constructed layers – which is where framework support comes into play. Frameworks give us the opportunity to abstract the deployed code from the implementation – so long as we can transform the model into a form (i.e. code) that can interact with a specific framework (STRUTS, Spring etc) we can have any number of abstraction layers that we need – be they horizontal (i.e. code generation with specialisation) or vertical (i.e. straight into native framework support).
What I miss in a feature list like this is that it does not explicitly calls out with what kind of development paradigm will be used to realize applications for all these new kinds of frameworks and infrastructures. As we are talking abut CA Gen I guess that somewhere it is implicitly assumed to use model-based design and development to meet these new challenges. Because if not, in what would the revolutionized CA Gen be any better or worse then the plethora of development environments that are already out there supporting these new technologies. And furthermore, again if not, then why wait on CA Gen version X.X, to start the integration with all new platforms via these new SDKs; turn it the other way around, use Eclipse with its wealth of (free) plugins and expose the (needed) CA Gen metamodel boundary in your native Eclipse environment via a tool like ProgGen and get started…
But Ok then, let’s assume we embrace these new technologies from our model-driven approach. However, what kind of modeling concepts do we have in the toolset to help us develop real-world applications in an efficient and productive way for these new technologies? How long can we continue to try to fit a square peg into a round hole by stretching the use of our procedural programming concepts (action blocks, procedures, imports, exports, …)in trying to map them onto the primarily OO concepts from which and on which all these new infrastructures are build?
If the CA Gen metamodel does not evolve by offering new high-level, platform neutral, design and development constructs then all of the integration will need to be realized in the CA Gen runtime and not via intelligent generators. That severely limits the possibility to implement anything that can be considered a complete application on those platforms because we will not be able to program business logic against some of the specifics of those platforms (e.g. things like the observer pattern with their callback functions, etc…). If the runtime is to handle the integration then CA Gen basically drifts toward a 4GL-paradigm whereby we have limited programming capabilities, but instead a bloated runtime environment…
However, that is not straightforward to map everyting onto the model is demonstrated by some of the new features in Gen CA Gen r8 Studio.These new features are only barely connected to the existing metamodel. E.g. no connection at all for Web Service Access Designer. E.g. a command-value entered for Pstep Interface Designer is just a string in the model, it is not a link to an existing command-object.
It has been since version r6.0 that any new structural programming concepts were added to the model allowing the designers/developers to write more intelligent programming logic (async pstep use, CBD concepts).
How about features that allow us to program according the OO paradigm, and to be able to generate a proper class and its implementation for those platforms were it makes sense? How about features that allow us to allocate “datastructures” dynamically so that we can start to program our logic using dynamic RGVs, or dynamic lists, collections, trees, or whatever is needed …
And this is where the user community comes in: the “whatever is needed” part! I believe it is a lost opportunity if the user community sits back and only prioritizes what new technology should be supported next. Instead the user community should start now to discuss about and define what new high-level, platform neutral concepts are needed to do productive development, not just for emerging technologies but also for current platforms.
The evolution of the CA Gen (meta) model can not be realized as an after-thought. It should be on the fore-front if one still wants the CA Gen model-driven paradigm to evolve and to continue to deliver high development productivity, ease of maintenance, application development compliance and governance…. If not, then we basically evolve to a situation where the CA Gen studio is just a customized Eclipse environment and the EMF framework becomes the main model-paradigm. I am not saying that this would be necessarily a bad thing, far from that, but it is not really a discussion on the future of CA Gen…