View from the Edge

OpenEdge 10.2A coming soon

OpenEdge 10.2A is scheduled to be available soon.  OpenEdge is the only platform that is optimized for the building of Service-Oriented Business Applications.  It differentiates from other offerings in the market because:

• Its purpose to simplify building your data- and transaction- and service-centric business applications with the highest productivity
• Integration and interoperability features are built-in, thus making it easy for you to connect to any application regardless of the technology or platform its built-on
• Support of a broad and rich set of open interfaces and integrated UI capabilities to ensure your applications can be built with any UI technology you choose, and even support multiple UIs with a single set of business logic
• High performance and scalable embedded database that ensures that all your data management needs can be met

OpenEdge 10.2A focus on the commercialization of the OpenEdge GUI for .NET which provides developers with the ability to build competitive, state of the art, contemporary user interfaces for their applications using Microsoft .NET Winforms technology.   What makes OpenEdge 10.2A offering better is that developers can do so in a highly productive manner because the new functionality is built into OpenEdge, integrating in OpenEdge Architect the new development tools such as the brand new Visual Designer and the extended Class Browser, empowering you to use only ABL, the best business-purposed programming language, and being fully compatible and interoperable with your existing OpenEdge GUI, to adopt at your own pace.

No one else provides such ease of use, productivity and business functionality, all within a single purpose development environment.

But 10.2A is anticipated to have much more than the GUI for .NET!  From a host of customer-driven usability and performance enhancements in OpenEdge Architect, as well as new XML and WSDL editors, to more OO extensions including garbage collection, through a new TIMEZONE session attribute to ease the deployment and reduce the operation costs of global applications, or sparse ProDataSet XML serialization for lower resources and increased performance, or OpenEdge server products support for Windows 2008 64-bit, to mention just a few.

The very high number of members and level of participation in the 10.2A Beta program, one of our largest and exciting beta programs ever, should be a good indication of the enthusiasm and anticipation that the Progress community is showing for OpenEdge 10.2A.  So, stay tuned for more information coming soon, and hang on, just a few more weeks to go!

Salvador

* For informational purposes only. Information in this posting may not be interpreted as any commitment on behalf of Progress, and future development, timing and release of any features or functionality described remains at our sole discretion.

Business-orientation and object-orientation

With enhancements in the OpenEdge 10.1x release family, ABL (Advanced Business Language) is being extended with standard formal object-oriented (OO) functionality: objects, classes, methods, polymorphism, inheritance, delegation, statics, properties, strong typing, and more.

A big differentiator from other traditional object-oriented Languages is that ABL does not exclude other programming methodologies though: ABL is not “pure OO”, and at Progress we think that is a good thing for our customers!.   With ABL, developers can combine and integrate classes with procedures and vice versa.   As a matter of fact ABL is the only business application's development language with this capability! 

In addition, ABL’s unique and powerful built-in data awareness further differentiate it from the rest of mainstream development languages.  Again, ABL is the only business application’s development language that provides uniform and comprehensive built-in capabilities to access, manipulate and store data from different data sources and formats (including relational databases, XML, structured and unstructured files, user-defined formats, etc.) intertwining it with sophisticated business logic, making ABL particularly suited for world-class business applications.

The requirements of modern business applications for modularity, open access and reusability through disparate interfaces have never been higher. The object-oriented extensions ease the implementation of robust business applications that adhere to SOA principles, and integrate with other systems, platforms and applications --- including non-OpenEdge ones of course ---  in today’s interconnected and heterogeneous business environment, thus furthering our commitment to openness.

Where encapsulated, modular, reusable functionality is required, developers can build on the inherent capabilities provided by ABL’s formal object-orientation. Where tasks, workflows or processes are needed they can take advantage of its continued support for procedural development methodologies.

We are very excited to hear from customers using ABL object-oriented extensions (OOABL for short) reporting that they are indeed helping them simplify their Service-Oriented Business Applications, and in some cases make their code up to 40% smaller --- your mileage may vary ---, with less integration points which makes the code more uniform and easier to reuse. 

I encourage everyone to take a look at the OOABL extensions.  Even if you are not familiar with object-orientation I think you’ll be pleasantly surprised with their ease of use and you’ll be able to quickly realize development productivity benefits, and will make your applications even more robust.  And remember, you can adopt and use them at your own pace alongside or integrated with procedural methodologies.   And stay tuned, there’s much, much more to come!

Now Featuring...

With the OpenEdge Advanced GUI right around the corner (well, coming soon anyway), I thought that it was appropriate to start a discussion on one of those four application pillars - Features.  As you may recall, I defined features as those characteristics of the software that aid in usability but are not domain specific.  Most features are somehow related to user interfaces - navigation systems, look-up systems, sizing attributes, etc.  But there are others:  Reporting, security and access, personalization and customization methods, etc. For this discussion, I'll concentrate primarily on the user interface features.

There are a number of subjects that we need to cover in here, so I will likely spin these out through multiple blog entries.  And if anyone else has ideas or questions, we can weave them through the process.  Here's the most important place to start:  To be effective, any feature that you put in your software must meet these rules:

1. Any user interface feature that you put in your application should be as intuitive as possible.  If you have to spend time learning it (or re-learning it), then it really isn't much or a feature.  Remember that some percentage of the users of your application are occasional users.  If they can't easily understand or remember how to use a feature, then they won't use it.
2. All features, particularly user interface features, must be consistent.  If navigation works in a particular way in one part of the application, then it should work the same way in other parts of the application.  That doesn't mean that there is only one way of doing something, but it does mean that the methods offered are consistent in every part of the application.
3. As much as possible and applicable, a feature should be implemented everywhere throughout the application.  The excuse of "Oh, that's an older part of the application, so it doesn't work there" is an internal excuse - it makes no sense to the user of the software.
4. An the design and implementation of any user interface feature, be very conscious of the habits of the users of the application.  Some people in some roles are very comfortable in using a mouse and a highly visual environment. In other cases, the interruption caused by having to look at the screen and move the hand from keyboard to mouse back to keyboard can be very irritating.  That's why so many features need a non-visual equivalent.

With those rules firmly in mind, let's look at how to think about and design features for your application.  It's tempting to jump right in to the particulars of a given feature or a given UI, but here's something I learned many years ago:

• The user interface is the prospect's window into your application.  Your competence, currency, and understanding will be judged by what the prospect sees in that window.  Features are emotional, functionality is factual.  If a prospect does not "feel good" about your feature set, that feeling will likely trump great functionality.  If you don't believe that is true, just look at Microsoft's success.

There's an important idea buried in that statement.  For functionality, we tend to look to customers, domain experts, and direct industry competitors.  For features, we should look at prospects and the wider software industry.   The applications that we tend to build  don't directly compete with Outlook, but we will compete with Outlook for the perception of our software in the user's eyes.

This makes it more difficult to design and implement good application-wide features.  We're out of our comfort zone.  So here's a method for prototyping and implementing features that I learned many years ago:

• Mock up two or three screens of an application that are working on.  Make them standalone so that you can run them and work with them without impacting the entire application.
• Using those two or three screens, prototype up every single user interface feature that you intend to support:  Navigation, look-up methods, menu options, linking methods, drill-down methods, message boxes, error systems, access controls, personalization methods, help and learning - everything.  We call this "hanging ornaments on the Christmas tree."  Just load it up with everything you might support some day.
• Use those screens to validate your efforts.  Try them out on current customers.  Show them to salesreps and see if they can be demo'd well.  Compare them to what you see in other places in the software industry and to your competitors.  Bring in analysts and usability experts and have them test-drive the features.  Do everything you can to lock down the feature set using just this small number of screens.
• When you have all the right feedback and have made all the appropriate adjustments, use these same screens to lock down the implementations and the usage rules of these features.  Turn the feature itself into a reusable object that becomes an automatic part of the implementation of any part of the application (templates work great here).  But more important, make it very clear that these implementations are a part of the specifications for the applications.  Developers are not allowed to deviate from these features without express permission of the application owner.  Each feature must be implemented as-is in all appropriate places - no exceptions.
• Finally, set up a small committee (by now you'll know the right people) that controls any changes to this feature set.  Individual designers, developers, and product managers are not allowed to implement new features nor alter existing ones without the express approval of this committee.

Those last points may seem a little harsh, but inconsistency inevitably leads to application degradation.  And none of us want that.

That's enough for this first posting on features.  We'll follow it up by getting in to the various types of features and how to think about each as you use the new Advanced GUI to build a new application or freshen up your current application.   

The Four Pillars of a Successful Application

When working with OpenEdge partners, it is not unusual to hear some statement like, "It's a great product, but I just can't through the demo."  Or perhaps, "We have better functionality, but we still lose deals."  These laments point to a common problem with business applications, particularly those applications that might have, to be polite, "a little age on them."

For an application to have both initial success and longevity, it must be built of four pillars of strength:

1. Functionality:  The domain-specific capabilities addressed by the software.  It might, for example, be about inventory, or order management, or credit management.
2. Features:  The non-domain capabilities of the application.  These usually include user interfaces, integration capabilities, search and navigation methods, reporting or inquiry systems, etc.
3. Architecture:  The under-the-covers construction methodologies used by the application.  Like most things in the world, applications should be build on a solid base with a solid design.
4. Technology:  The basic technologies and infrastructure components that support the application.

All four of these areas are worthy of full discussion and we'll try to hold that discussion in future postings.  But right now I'd like to talk about balance.  Here's an old story from my past that perfectly illustrates the concept of application balance.  About a dozen years ago my sister was on a committee to select new software for maintaining accounts and processing information for the university alumni association where she worked.  The were down to J.D. Edwards and another specialty vendor - one that I'd never heard of and that you won't know either.  She wanted some advice from her brother in the software business (tell me that never happens to you!).  I told her that she was likely to see some very good looking software from J.D. Edwards with some very impressive technology underneath.  But I told her to press them hard on functionality that truly fits the nooks and crannies of her job.  I also advised that they would probably come up short.  My advice on the other vendor was the opposite:  That the software would probably be a perfect fit for the business, but would not look as impressive and that the salesrep would likely shy away from technology questions.

Needless to say, she called back a month later and her first words were, "How did you know?"  Right now, your heads are nodding up and down because you've seen the same thing; software companies that focused on functionality to the exclusion of the other three areas, and software companies that focused on features but didn't real have good, industry-specific functionality.

In the OpenEdge world, application partners have always put the greatest weight on functionality.  It's an easy thing to do.  New functionality keeps current customers happy, helps close the next new deal, and further cements the partner as an expert in their field.  But if the imbalance is taken too far for too long, serious damage occurs.  The application becomes unwieldy, non-competitive, and eventually, obsolete.  Let's look at those four areas again:

    Functionality:

• Keeps current customers happy
• Provides advantages over other industry competitors
• Belongs 100% to the partner (Progress doesn't contribute)

    Features:

• Keeps prospects happy during demonstrations
• Provides advantages over other general-purpose competitors
• Is enabled by Progress, but must be implemented by the partner

    Architecture:

• Makes IT departments and development departments more productive
• Adds longevity and agility to the application
• Is enabled by Progress, but must be adopted and evolved forward by the partner

    Technology:

• Can become a barrier to future sales if not kept current
• Adds interoperability and flexibility to the application
• Is primarily addressed by Progress, but partner can adopt and extend

When you look at the four areas from this perspective, the importance of balance becomes immediately obvious.  Sure, you might put more weight on functionality overall, and there might be periods of time when one of the four areas gets the lion's share of your attention, but overall every application must keep these four areas in relative balance. 

Last summer, I had a customer ask me when an application becomes obsolete.  My answer was this:  With proper attention to all four areas, an application never need become obsolete.  After all, applications are just bits and bytes.  But if any one of the four areas is ignored for an extended period of time, the result will be application that faces the need for massive overhaul.  And that's when applications become obsolete.

We'll explore this idea of the four areas and the balance between them in future postings.  In the meantime, I'd love feedback on this and any other topics of interest.