View from the Edge

How Much Code Can You Write For $10,000

Server hardware is incredibly inexpensive nowadays. For example, you can get a Dell 710R with an Intel Xeon 5690 6-core cpu, 32 gigabytes of RAM, a two-port Fibre-Channel host bus adapter, and dual gigabit Ethernet for less than $8000. Folks, that is a pretty stout box. And you can get even larger ones and much more memory.

What it comes down to is that you can probably afford as much memory and as many cpu cycles as you will ever need. Disk storage is not very expensive either.

The question is, how will this affect how you design your applications?

I used to think that it was necessary to build "stateless" applications so you could have enough scalability and minimize the number of of AppServer agents you have to run.

Now I wonder whether it is worth it. It is definitely less work to build stateful applications and dedicate an agent to each client. With such powerful servers as the one I described above, it may even turn out to be practical.

 

Announcing AutoEdge|TheFactory, a new OpenEdge Sample Application

To coincide with the release of OpenEdge 10.2b04 and Savvion 7.6.1 we are pleased to announce a new sample application, AutoEdge|TheFactory which can be found on Progress Communities : http://communities.progress.com/pcom/community/psdn/openedge/architecture/autoedgethefactory

AutoEdge|TheFactory is an extension of the use cases illustrated by the original AutoEdge sample application.  Where AutoEdge is based upon the business functions of an automobile dealer, AutoEdge|TheFactory is based upon the business functions of an automobile manufacturer supplying vehicles to dealers.

The aim of AutoEdge|TheFactory is to introduce the concepts of an OpenEdge Reference Architecture based Business Process Application utilizing OpenEdge BPM.

Recorded guides

To see more about AutoEdge|TheFactory  there are a set of videos that guide you through the installation as well as the design and running of the  application:

• The installation guide is here ; it contains a walk-through of the installation process (approx. 15min)
• A recording describing the design process in SBM Studio is here (approx. 30min)
• A recording running through the process appears here (approx. 12min)

The Source Code

In order to run the complete sample application you will need both OpenEdge 10.2b04 and Savvion 7.6.1 installed.  AutoEdge|TheFactory is developed utilizing the Object Oriented extensions to the ABL in OpenEdge 10.2B so you can install without Savvion in order to get a closer look at the code.

Selected code highlights

• Inversion of Control Container: InjectABL
• Query manipulation and query row keys
• Data request and response
• Enumerations in OOABL
• Structured Error Handling
• Strongly-typed Events
• Object Serialization

 

There is also a wealth of documentation related to the project available that highlights & describes many of the coding techniques & decisions made on the project so far.

 

This is the first of a planned number of releases of AutoEdge|TheFactory over the coming months, you can expect to see more functionality and documentation being added as we work our way through the project.

 

Please feel free to give us feedback, good and bad through the discussion forums attached to the project.

 

Special thanks go to all those people who worked on the project, with particular mention to Peter Judge for his tireless efforts in making this a reality, along with support from a cast of many including Havard Danielsen, Sarah Marshall, Dr. Kamyar and Ken Wilner for his constant feedback, plus those who helped test in the final days before going public.

 

Many Thanks

Mike

Top 5 Signs Your Business Applications Are In Need of a Facelift

How can you tell if your application needs a facelift?   Here are some telltale signs:

 1.  You turn on your computers and the screen shows a 1980’s “Green Screen” interface from MS DOS.

Today’s workforce is full of young digital natives, but many of today’s business applications seem stuck in the middle ages. This younger workforce needs to have an intuitive user interface (UI), similar to what they are used to using on a daily basis in Gmail, iTunes, and smart phones. Reading email on a green screen interface is just not appealing.

And this UI issue goes beyond just being intuitive – some companies are finding it hard to recruit younger workers due to their older, prehistoric looking applications.

It is important that we modernize our applications to look like the things we use on an every day basis at home, and move away from the dark (green) ages.

2.     You have to go to nine different screens to enter one invoice.

Today’s application users seek simplicity and ease of use, and hope to avoid complicated entry methods at all costs. Having an application that requires multiple pages of entry is not only complicated, but time consuming as well.

For instance, imagine if in order to send a text message from your iPhone, and it was a character DOS based prompt or even worse if you had to use a rotary dialer. Today, phones are able to store countless phone numbers, and you can even dial by voice – making the phone much simpler and easy to use.

Whether it’s five minutes or five pages, if your applications are complicated and not easy to use, then it’s time to consider modernizing your apps.

3.     You have to run from desktop to desktop to download an application onto each computer.

 Today’s workforce is no longer in one place – employees are traveling, working remotely, and need to be able to access important information on their phone. Yet many companies still rely on a sneaker network, where IT professionals must run from desktop to desktop, adding applications to each computer.

For instance, it wouldn’t make much sense if Google had to visit everyone with a computer that used their search engine to load updates. That is why web-based applications are so great, they are easy to update, and very portable – accessible from your cell phone, iPad, laptop, or desktop.

If you have a fat client server, and applications that reside on every desktop then you need an application facelift. 

4.     Your application can’t integrate with other applications.

Today we live in an integrated world – where applications are constantly communicating with each other to make our lives easier. However, many companies still rely on stand-alone apps – where the information you enter into one app stays only in that app.

It would be like if you went to department store, and in order to use your credit card the cashier had to enter your credit card information manually, call the credit card company to authorize the charge, then enter a authorization code to finish the transaction. Today it’s just swipe and your done – all of the applications are integrated and communicate behind the scenes. A lot of places will even remember your information and what you bought last.

It is clear that applications can’t stand-alone any more. If your applications aren’t integrated, then your apps are in need of a facelift.

5.     Your customers are all running completely different version of your applications

Today’s application provider should be able to support a single, multi-tenant application, allowing for multiple customers who can each personalize the application. This won’t work if all of your customers have different versions of your application, and you spend all your time managing and maintaining each version.

Back in the day, you weren’t a software provider; you were a custom consulting organization. It would have take two to five weeks of a consulting engagement just to make a change to the application.

If you are looking to deliver better services to customers, your apps needed to be workflow enabled. If you can’t run your business with a single code, then you should look into modernizing your app and taking advantage of newer technologies such as business process enablement.

What is Application Modernization all about and why should you care?

For successful businesses, the saying “don’t fix what ain’t broke,” has long been the standby guideline. That said, while your applications may technically be running properly, they very well might be quite broken.  It just depends on your definition of broken.

Today’s developers and technology strategists look upon an application with additional scrutiny. A “broken” application can be one that carries any inherent risk to many companies in ways that you may not have considered, such as: 

• Lack of employee productivity
• Less than stellar business process efficiency
• Customer dissatisfaction due to speed of service delivery
• Negatively affecting employee/customer retention and/or acquisition

For example, one of our customer’s that I was meeting with mentioned that its point-of-sale (POS) system, while running quite well and doing everything the company needed it to do, however unknown to them -it was in fact an inhibitor to the recruitment efforts for new sales associates in the stores. 

In this case, it came down to the user interface. The company’s application was functional, but it seemed terribly out of date to nearly anyone looking at it for the first time. The company learned that potential employees, who were 17-24 years of age, not only feared a steep learning curve, but actually perceived the POS system to be difficult to use, as they were used to a more “IPod” look & feel.

This is because the 21st century workforce is largely made up of digital natives, people who have grown up with an electronic lifestyle.  They are quite used to the human-machine interaction – but they absolutely need to feel at home in the user-interface of the applications that they use.

There are many easy ways to update applications, without requiring a complete redesign or even rip & replace of the back-end.  Some, like in the example above, center on the user interface.  Other application modernization efforts may focus on adding devices that are more suited for data entry in the worker’s environment, for example, enabling the use of ruggedized scanners at loading docks, or inclusion of data arising from digital scales.

Updating your applications may also save money in the long run. Out of date, sprawling applications tend to be more expensive to support.  As an old application continues to age, fewer folks within the IT organization may actually understand how the application was built or how to support it.  Inefficient applications may also lead to extraneous resource use (i.e., Internet bandwidth, database size) or require more constant support on the back-end.  Further, quite often, developers must spend time managing various versions of the application, instead of being able to update just one set of code.

The bottom line is that business workflows are continuing to change to become more dynamic and efficient, so applications need to be changed as well to best support those new processes.  That is what we see as a sure sign for the need to undertake an Application Modernization effort.

The OpenEdge Multi-tenant Advantage

I was just reading a recent interview with Treb Ryan, the chief executive of OpSource by Forbes  and I think he makes some interesting points. 

His main theme during the interview is that multi-tenant applications and a multi-tenant architecture will become "dominant" and "present a challenge to the relevance and importance of a large amount of open source software".   The interview also touches on the point that even when you set out to create a new web application, "[with open source] you are going to have to do a lot of heavy lifting".  Of course, this isn't just true of applications created with open source platforms.  

As many of you know, our vision at Progress for many years has been about simplifying the job of creating the worlds best business applications, and if you've attended any recent OpenEdge presentations, (Exchange Online or Face-2-Face events), you cannot help but notice that the vision has been refined to position 'OpenEdge as the leading SaaS Platform for simplifying service development and delivery in the Cloud..".

One very real way this will be achieved, and that customers & partners of OpenEdge will be better positioned than any other application providers, will be the multi-tenant database capabilities that have been announced for OpenEdge 11.  This capability is truly a market differentiator and will remove much of the "heavy lifting" that Treb refers to, let alone the myriad of other features planned for OpenEdge 11.

By the way, if you've not seen a recent OpenEdge roadmap presentation and you're in Sweden or Canada, I encourage you to sign up for the remaining Face 2 Face events that are coming to you soon!

Alternatively sign up for Exchange Online 2010 where you're sure to hear a lot more about how OpenEdge is the leading SaaS Platform for application development.

   

My First OpenEdge GUI Application, And In The Cloud Too !

Last week I built my very first OpenEdge GUI Application. I even used OpenEdge Architect to do it (I normally use vi for programming). The whole development environment was running up in the cloud. I performed this remarkable feat at a workshop during the Netherlands PUG meeting near Utrecht.

The workshop was ably directed by Peter van Dam, from Futureproof Software. He made it really easy for about 60 beginners to learn how to build a simple but functional GUI application with a login screen, an updateable data grid, ribbons, etc with an Office-2007-like appearance.

Each workshop student was given a login for an AMI on Amazon EC2 where the OpenEdge development environment was installed and configured, along with a few image files for icons, and a database with customer records already in it.  This was accessed using Windows Remote Desktop. Nobody had to install anything on their own machine. Peter led everybody through the exercise in two 90 minute sessions with a half-hour break between them. Since he was speaking in Dutch, I had some trouble understanding him.

Nearly everybody finished their application. I had some cosmetic bugs I didn't bother to fix (labels in the wrong place and stuff like that) so mine was not 100% complete.

A few observations:

0) Amazon EC2 works really well for this sort of thing. Dev tools, code, database, everything was somewhere in the cloud. You could start as many machines as needed and run them as long as needed.

1) I was pleasantly surprised at how responsive the GUI was, running Remote Desktop over a hotel Internet connection to Amazon's data center.

2) Developing with the Eclipse-based OpenEdge Architect tool in the cloud is a lot nicer than using some crappy development tool running in a web browser.

3) The Infragistics UI controls have a lot of functionality and are very complicated.  Without a cookbook, I could never have figured out what to do and which properties did what.

4) Programming by clicking, clicking, and more clicking with the mouse is really boring.

5) Boring or not, it's powerful.  You can get a lot done quickly.

One more thing: at the very beginning of the workshop, the hotel's router had a meltdown. It took about 90 minutes or so to get a replacement. Being clever folks, the Dutch PUG meeting organizers had scheduled two talks for after the workshop. So we did these first, while the router was being dealt with.

All in all, an excellent outcome. If I can do this, you can too.

Exchange Online 2009 - Behind the Scenes

In early Spring 2009, when we began planning our first online conference, we had no idea what to do. We knew that we wanted to do something unique and different, but had no idea how long it would take get things done, what would be hard or easy, or how many people we would need. We didn't even know the right questions to ask. I spent a number of weeks educating myself, looking at and participating in online conferences other companies, universities, and organizations like the Smithsonian Museum were doing. Among other things, I spoke at BravePoint's Virtual InterChange conference, which allowed me to see what's involved in doing a live broadcast.

We eventually decided to do something akin to a TV "newsmagazine" style broadcast with a number of separate programs and "episodes", using a variety of media and techniques. What we produced in the end was, on the one hand, not too far from that, and on the other, not at all like that.

We had numerous discussions about what to do, how to do it, and who we could get to help.  Also many arguments about things which turned out not to be important in the end. Key to helping figure it out and get it all done was Cramer, a production company that has done a lot of work for us in the past for our F2F (face-to-face) conferences and all sorts of videos.

Among the things we discussed endlessly were how many technical sessions we should have and how long they should be. Would anyone come? How long an attention span would an online audience have? How many days would be people be willing to "tune in"? For how long? 2 hours? 4 ?  6 ? Would people leave if there was "dead air"?  What should we do about people in different timezones? How many sessions would we have time to produce? Is live or recorded better? Which is harder to do? We got many different answers to these questions. In the end we decided on two concurrent video "channels" starting with general sessions followed by a series of 30 minute technical sessions with a short question-and-answer period in the last few minutes of each one, and a live discussion channel. The sessions were recorded but the q&a period was live. Would that work? We wouldn't know until we actually did it.

When we opened the conference registration site, we got a huge surprise. After two days, we saw that about two hundred people had registered. Then, over the weekend, registrations spiked up over 3,000 and continued rising. At first we were thrilled. Then we learned that someone had posted a link to our registration page on several sites that enabled people to find places where they could get free stuff. We had free stuff. Anyone who registered would get a free T-shirt. Over 4,000 people who had no interest in the conference had signed up just for the free shirt. What else could go wrong? I loaded all the registration information into an OpenEdge database and wrote a 4GL program to rank all the registrations and identify the bogus ones so we could delete them.

Gradually, things came together and all the speakers got their materials prepared and practiced their talks. In early August, we began filming. I spent 4 weeks at Cramer's studios, working with the speakers while we were filming and then with Cramer's folks (thanks Theo!) editing video while others worked on the web site, registration, promotion, and many other things. It was a lot of work but it was fun.

Finally we were ready. The conference broadcast went live at 8:30 am on September 15. We held our breath. Everything worked, with only a few small technical glitches. Here's a picture of the control room for one of the channels.

When the broadcast was finally finished on the third day, we were relieved.  We made it.

As we discovered, 30 minute sessions worked pretty well. Almost. In hindsight, we learned that:

0) 23 minutes of content with 7 minutes of q&a time didn't allow enough time for questions for most of the sessions,

1) our speakers were not used to speaking for such short periods and had some difficulty with that,

3) there were (deliberately) no breaks between the end of one session and the start of the next. Feedback says we should have had them,

4) the "networking lounge" and discussions were hard to use and didn't work as nearly as well as they should have. In spite of the difficulty some good discussion did take place.

Still, I think those were relatively small problems.  In the grand scheme of things, I would say Exchange Online 2009 was a success.

Session videos for the Exchange Online 2009 conference are still available for viewing for another month.  If you haven't had a chance to visit, please point your browser to http://events.unisfair.com/rt/exchangeonline~sept2009

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!

Of OpenEdge, Toasters and Vacuum Cleaners

Are toasters and vacuum cleaners ultimate examples of commodities? Of course!, right? Well, think again.

A few months back I read ‘The Myth of Commoditization’ by Michael Schrage, an article in the ‘MIT Sloan Management Review’ magazine and ever since I find myself getting back to the facts and the concepts masterfully described by Mr. Schrage in his two-page article.

By know, I hope that you’re a little intrigued and you will want to read on this, my first, OpenEdge Perspectives blog. There are many aspects of what Progress Software has done with OpenEdge over the years that in my opinion share parallelisms with Toasters and Vacuum Cleaners not being commodities: Quite the contrary, retaining and extending our, as their’s intrinsic and perceived value. Progress (the product and the company shared the name back then) was first released in the early 1980s and throughout 25 years of innovation cycles driven by our customers (Thank you!), the market and the IT industry we have kept our mission: “Simplify the job of building the world’s best business applications”.

How many evolutions and revolutions!: From the minis, hosts, personal computers, client-server, application servers, to the Internet. From character, GUI, one-tier, two-tier to global all-tier. From procedural, event-driven, object-oriented to SOA and software-as-services. How many opportunities to become commodity! And nevertheless Progress is not.

As information technologies evolved, the more the unfulfilled promises from many for simple, easy to use offerings to build long-lasting and ever-changing business applications. Simplify is difficult!. First you need to make something possible. Many products stop there. Then you can simplify. Very few actually do.

Let me tell you a story: Long ago, when I was a programmer using Progress and working on-site, one of the company’s line of business manager said to me: ‘You see, I’ve been looking for a while at what you do and no matter what I ask you to do, or how complex my request may be, you always, always do the same thing: You start a tool that I noticed is called Procedure Editor. Then you type a few lines of code which for the most I can actually understand and voilà you have the information I needed. Quite often in a format that is not pretty I have to say, but boy you are fast!’

That company had Progress-based applications, and a bunch of other ones they had purchased, acquired or developed over the years. All in all a hodge-podge of C-ISAM and an early Oracle database, COBOL, BASIC and some C, and an IBM mainframe with RPG of course. We had installed Progress and the Oracle and C-ISAM DataServers (back then Progress called them Gateways). Many of the ad-hoc requests I was getting from LOB managers meant to cross-reference and join information from many of theses systems, and yes, I always started with the Procedure Editor, connecting to the data sources, looking at their schemas (nevermind some were not even relational), and writing a few lines of ABL. Such was the power of Progress.

Many customers tell me that today they are doing similar things with OpenEdge Architect with IntelliSense, auto-completion, dragging-and-dropping from database schemas to the code editor and the works compared to my character-based Procedure Editor. Perhaps some of them even have to gather information from web services. What’s the drill? Get and look at the WSDL, connect, and RUN, where I used to connect to Progress, Oracle and C-ISAM, check the schemas and RUN.

So what’s the moral? Our customers tell me that Progress OpenEdge’s unique, intrinsic and sustained value to them is its business focus. If we managed to simplify building complex business applications including reading, writing, and managing data from displarate data sources, now we are simplifying to build, extend and integrate heterogeneous business applications using messaging, Enterprise Service Bus, Web services, and SOA-principles with OpenEdge, .NET, Java and standard interfaces.

Progress cannot just make things Simple, because businesses are not.  We make things Simpler! As for Toasters and Vaccuum Cleaners, commoditization is a misleading guide to innovation, a race to the bottom. At Progress Software we prefer races to the top. In the long run, everything is not a toaster. Not even toasters.