• Phil Ly

Stuart Selip’s Closer look at: Model Driven Architecture

MDA Intro

Guess what?  You have legacy applications.  What are they?  Well, they are COBOL applications that are many years old.  Our loyal developer community is looking forward to retirement, so who will attend to the care and feeding of these “classic” applications? By the way, COBOL isn’t the only legacy technology You’re right if you think PACBASE, “C” and “C++” applications or fat-client solutions like those constructed in the 1990s using PowerBuilder, Delphi, and Gupta SQLWindows are legacy applications today.  These are all “legacy”, but the greatest volume of “good old code” was written in COBOL.

What is in your legacy applications? Usually they contain a mix of business rules, process flows, screen interactions, batch processes, and reporting that, through years of maintenance and enhancement, have grown in size, scope, and complexity. Some of those applications could be called “High Value”, while others are not unique or critical.

Is this good news?  Well, yes and no.  High-value legacy code might just form the competitive basis for your company. The intellectual property (IP) in legacy applications often competitively differentiates your organization from its peers, and you are subject matter experts (SME) of those applications. On the other hand, newly-minted IT professionals no longer study COBOL. Instead, they think more about Objects, Java, C#, and web technologies.   We have a good approach to this situation of legacy code and new coders. We think your high-value code could benefit from some intensive reverse engineering that extracts the intellectual value of the software, and gives it a new lease on life.  Finding the value in legacy applications has been a “holy grail” quest for more than 20 years, but only recently has modernization moved from alchemy to engineering.  How has this happened?  Think Model-Driven Architecture (MDA).


Simply, it is a graphical modeling approach to object-oriented software development, specifying both the static technology building blocks (the classes, information content, and operations)  and dynamic behavior  (“when the online customer clicks on “place order” the system will….”) of a software solution as elements of a model.  Using MDA, you, as SMEs, help capture the IP of your legacy applications, without retaining the code in which it was written.  Think of using MDA as applying an organized process to build a set of really powerful “flow charts” using Unified Modeling Language (UML).  UML wasn’t around when your applications were written, but today it is an industry-standard way of describing systems and programs, covering perspectives from overall system architecture, through internal program design. More than just pictures and charts, with the right companion technology MDA allows you to “generate” modern code, without having to sit there and write it up by hand.

No, we did not invent MDA.  MDA has grown from a standards-making process of the Object Management Group (www.omg.org) in the early 2000s to something practical and useful today.  Now, when you have a UML model ready to go, you can fire up an MDA application generator to read the model, and create modern code for your chosen target technology stack.  Frequently, technology stack choices are Java, or Microsoft platforms, and in an MDA approach, the usual software coding process has been replaced by code generation.  The trick is, you have to build your models right, and select the right generator technology.  With your expertise in your existing applications and TIC’s investment in training and technology, the time is right for MDA modernization.

How do you decide which legacy applications should be modernized?  It takes a rationalized IT portfolio to pinpoint your high-value applications for MDA modernization and lower-value candidates for alternative conversion, or replacement. If you’re not sure about your IT Portfolio, we can help your organization create one. Basically, you need to know about the value the legacy app delivers, vs. the cost to maintain and/or modernize it. For example, though perhaps convenient and familiar to your users, many software solutions (e.g. accounting, payroll) are not business game-changers that lead your organization to market preeminence. “Commodity” applications may not be worth modernization.  Other approaches, like replacement with commercially available “off the shelf” solutions for in-house or “Cloud” access might make more sense.  When you want to know more about legacy modernization, MDA, IT Portfolio Management, or any other forward-looking practice… we are ready and able to have that conversation, and deliver on what follows.

Feedback pleaseDo you find this tutorial blog helpful? Let us know what you think, and how we can make it even better. Don’t forget, you can subscribe to our blogs (top right-hand corner of this page) to get automatic email notification when a new blog is available.

 

#COBOL #HPENonStop #Modernization #TICSoftware

1 view0 comments

Recent Posts

See All