ABL in a Pacific World

Over the years you & I have engaged in many a discussion over architectural philosophies, OERA, class & object based implementations as well as your passion for Model-Based Development (right the way back to the initial foray's with Enterprise Architect), and long may these discussions continue!  

I think your paper hit's the nail on the head when you say "…in the context of Pacific, where one has the OpenEdge database, ABL, Rollbase, Corticon, OE BPM, and Data Direct Cloud all available as a part of a solution, ABL still has a major rôle to play in any enterprise class business application as the tool by which the core, complex business logic is performed.", we absolutely agree.  If my memory serves me right, you attended my session at Exchange where you will have heard me say that we see ABL within Pacific, and the introduction of a Unified Application Server as major differentiators vs our competition.  Not only does this provide a path forwards for leveraging existing ABL code and the investments that ISV partners & customers such as yourself have created, but it also provides the ability to build the "sophisticated logic" that you refer too that complex business applications require all within the Pacific platform.

You know as well as I do that Progress is built on the premise of simplifying the job of building business applications.  When we look at a modern business application today, we see 4 keys areas where people are looking for simplicity, productivity & customization.  Those are typically around Business Process, Business Logic, User Interface & Data Integration.  The foundation for all this is of course the right architecture, and as you mention, the OERA is a great foundation and a perfectly valid one at that, for not only OpenEdge based applications but also applications built on Pacific.  Combine the right architectural approach with a visual BPM tool, Decision Services from Corticon, the ability to chose the appropriate language for the business task in hand (ABL or JavaScript), Rollbase Productivity and DataDirect Cloud for Data Integration (with Easyl to follow) and we believe we have a Platform that is not only differentiated, but blows the competition out of the water.

I'm not 100% sure where you heard the comments around generating ABL code from templates as that's not something we're planning.  What we are planning is the concept of  Application Templates that could be a combination of ABL logic, Corticon Rules, a DataDirect Cloud DataSource & some Rollbase Objects & UI that would be used as a building block or a basis for building an Application, and we will be actively encouraging the community to participate in the creation of these templates. Hopefully we've learned lessons from the SmartObjects Marketplace :-)

The discussion around making ABL "sexy" is an interesting one.  I think we're certainly seeing the re-emergence of Domain Specific Languages or Purposed Languages and many of what people would consider to be 'hot' (or should that be 'cool')  languages fall into this category, R, MATLAB, erLang and even APEX from SFDC.  So why not ABL?  As we know there is no better language for building data rich, transactional business applications.  But we also have to be realistic, and whether it's perception or reality, there are many who see these languages as niche, so having the ability to offer a broad based language such as JavaScript, in conjunction with ABL I believe offers us the best of both worlds. Again, combine that with other aspects of Pacific and we really do have a powerful story, for both our existing community but also for new customers.

In terms of MBD, a lot of initial thinking around this came as you know from the Progress Field Organization, and in particular Phil Magnay and Team, with the work they did using Enterprise Architect.  This very much followed the approach you outline in terms of using UML as the lingua franca for the description of the problem to then generate ABL code.  Personally the downside I see to this approach is the immediacy.  Rollbase is model driven, not using UML but an object model approach which allows for instant feedback and therefore a more iterative approach.   In addition, as you rightly say, applications are made up of a number of different facets these days.  Some of the application is expressed in BPM, some in Business Rules and some in Business Logic, and providing purposed solutions for each of these areas I believe offers higher productivity in a more native manner than trying to express everything in UML. Having said that, did you realize that Rollbase has the ability to create a UML model of an application from within the Application Setup option?  

As you know I've been at Progress almost 10 years and I can honestly say this is probably the most exciting time I've experienced during that time. 

Once again, thanks for taking the time to put together the paper, but for also making it this far through my response!

Mike

On 10/23/2013 8:17 AM, Mike Ormerod wrote:

> we believe we have a Platform  that is not only

> differentiated, but blows the competition out of the water.

Agreed ... I'm just trying to make it even better!

> What we

> are planning is the concept of  Application Templates that could be

> a combination of ABL logic, Corticon Rules, a DataDirect Cloud

> DataSource & some Rollbase Objects & UI that would be used as a

> building block or a basis for building an Application, and we will be

> actively encouraging the community to participate in the creation of

> these templates.

While you describe a more complete solution than simply generating ABL code from templates, I don't think that the solution is any better in terms of the issues I raised about template generation. In particular:

1. Unless there is regenerability, if one makes any change in the desired functionality or implementation, the only way to incorporate that change in all existing work is manual.  This implies substantial effort and is very error prone.

2. If one makes any fundamental architectural change, the rework is likely to be even greater since the whole structure may be wrong.

We who have been in the ABL world for a while have gone through several of these major architectural revisions -- from the initial BBoM ChUI applications to client-server to event driven to persistent procedures to OERA to multiplication of UIs to most recently the addition of BRM and BPM.   It will happen again. Multiple times.

I can even tell you when it will happen.  Next year with the next-gen AppServer there will be a transition from best practice being aggressively stateless to best practice being statefull.  If Sunil gives me AppServer to AppServer calls, it will enable a form of AppServer multi-threading.  If he gives me multiple clients using the same session, it will enable Sonic-like services in the AppServer.  These are all going to have substantial impacts on the architecture.

Model-Based Development allows the same model to adapt to any of these changes.

> The discussion around making ABL "sexy" is an interesting one.  I

> think we're certainly seeing the re-emergence of Domain Specific

> Languages or Purposed Languages and many of what people would

> consider to be 'hot' (or should that be 'cool')  languages fall into

> this category, R, MATLAB, erLang and even APEX from SFDC.  So why not

> ABL?

The problem with DSLs, of course, is that they are domain specific and the universe of ABL applications covers a multitude of domains. I also have yet to see one that is as platform independent as UML can be.

> there are many who

> see these languages as niche, so having the ability to offer a broad

> based language such as JavaScript, in conjunction with ABL I believe

> offers us the best of both worlds. Again, combine that with other

> aspects of Pacific and we really do have a powerful story, for both

> our existing community but also for new customers.

And, I agree that they are niche by virtue of being targeted on a specific domain, so one needs a general purpose solution.  ABL is certainly far ahead of C, C#, or C++ in terms of productivity and platform independence, but it is not as productive and resilient as it could be.

> In terms of MBD, a lot of  initial thinking around this came as you

> know from the Progress Field Organization, and in particular Phil

> Magnay and Team, with the work they did using Enterprise Architect.

Phil and I were both working on this before he went to Professional Services.  His going there gave him the context to show what he could do with it.  And, he did, because the model-based approach there made about a 2X improvement in the cost and effort of doing a transformation, despite the fact that he was only generating skeleton code that was finished manually.

> This very much followed the  approach you outline in terms of using

> UML as the lingua franca for the description of the problem to then

> generate ABL code.

Except that I am talking about 100% generation.

> Personally the downside I see  to this approach is

> the immediacy.  Rollbase is model driven, not using UML but an object

> model approach which allows for instant feedback and therefore a more

> iterative approach.   In addition, as you rightly say, applications

> are made up of a number of different facets these days.  Some of the

> application is expressed in BPM, some in Business Rules and some in

> Business Logic, and providing purposed solutions for each of these

> areas I believe offers higher productivity in a more native manner

> than trying to express everything in UML. Having said that, did you

> realize that Rollbase has the ability to create a UML model of an

> application from within the Application Setup option?

No, I didn't know about that.  Nice, but, of course, mostly limited to what amounts to an ERD since there isn't very much logic there.

Perhaps I have not communicated this clearly, but I am by no means suggesting a UML model for the whole application.  Inherent in my work is the expectation that rules will be in Corticon, processes will be in OE BPM, and the UI will be in one or more visual designers.  If the application includes an appropriate web component, then I would expect that to be in Rollbase.  The UML is only about the part which is going to be rendered in ABL.

For new applications, the UML process also allows for a lot of feedback.  The requirements gathering ... which one needs to do in some way whatever technology one is going to use to deliver the application ... is designed to create feedback between the business users and the modelers in terms the business users can understand. Once modeling of the solution has begun, one can generate code and put that in front of users very quickly.  The argument can be made that MBD provides the ultimate agile process - www.cintegrity.com/sites/cintegrity.com/files/Agile Model-based Development.pdf

There are two key points which I feel make a really compelling case for MBD.  One is that it provides higher productivity in developing the initial application, typically about a 2X improvement.   The other is that, once developed, it is incredibly responsive to change in the same way that you have been touting Corticon recently.   This is more like a 10-20X improvement in the time and effort required to produce a new system with changed requirements.  To me, this make MBD incredibly compelling.

> As you know I've been at  Progress almost 10 years and I can honestly

> say this is probably the most exciting time I've experienced during

> that time.

Next year will make 30 years since I wrote my first ABL code and I agree with you!