Compiere from the Source

Agile Development - the cure all?

2009-03-25T21:50:21-07:00

I just completed a 2 day class in Agile Development aimed at Product Managers. While I have a good understanding of the concepts and practices of Agile Development, it is always a good idea to validate what you know (or think you know). Also it helps to understand how others are using the processe and what issues and concerns they have.

What surprised me was that some people look to the Agile Development methodology as the 'cure all' or panacea for their devleopment woes. No development methodology can make a disfunctional organization functional.

What Agile can do for you is provide transparency and visibility to the development team that allows for predictablity with respect to the team's performance. So basically, at the end of each iteration (recommended length is 2 weeks) you have the following information:

How good your estimates are
If you are falling behind
What any roadblocks are

The big benefit is that you know this information after 2 weeks and can make the necessary adjustments (either in resources, scope or expectations), as opposed to at 6 or 12 months with the traditional waterfall approach. If you need to request resources, you have the information to support your request.

As someone who has done my fair share of testing, I appreciate that the testing is an ongoing part of each interation. Gone are the days of development finishing and then passing it off to QA. Usually with less time than planned to complete testing and no margin for rework if development assumptions were off.

With Agile you constantly validate the requirements and functionality through scrum meetings, demos and constant testing. At the end of each iteration there must be some demonstrable progress. In the early stages that may just be a code review, but as you progress it will be functionalty.

Developers get better at estimating effort. Business Analysts get better at describing the functional requirements and expectations are constantly checked.

Lastly, Product Owners and Project Managers are better armed with the necessary information if adjustments need to be made and these adjustments can be made earlier in the cycle.

In then end, I realize more and more how effective the Agile process can be for ERP Implementations. Involve interested parties early, keep them involved, constantly validate and make adjustments. The Big Bang approach of working in isolation with a small group and then presenting an ERP is gone. It has proved historically to be ineffective and inefficient. Time to use a different approach.....Agile.

Cloud Hype and Reality

2009-03-13T15:25:28-07:00

Cloud computing is "in" - and actually with the latest price change from Amazon it is becoming a bit more real.

I signed up with Amazon, installed the Java tools, created my own image, changed it via Windows Remote Desktop, saved that image and re-started that image - in half a day. Far easier than I thought - just another half day to install database, application, etc. As they have nice Java interfaces for the operations, I think that the entire process can be automated (or you could use the Management Console).

Realistically, the Amazon Elastic Compute Cloud (EC2) is just an alternative to dedicated hosting - but rather than paying for 24h/day, you pay just for the time you have your instance up. You still need to maintain the operating system, application, configure firewalls, implement a back-up strategy - the tasks which are included in a Software-As-A-Service (SAAS) model. Main benefit is that you can select from quite a few starting points, Amazon Machine Images (AMIs) - from several free Linux O/S as well as Windows or commercial vendors (Oracle, RedHat, IBM, JBoss, Compiere, ...) combining convenience and license payment.

We will be using it for our automated build with one instance and one instance per configuration for regression and load testing and are "burning" currently max 2 hours per day for the 3 configurations (4 planned). As these tasks are not essential, delays and non-availability is not an issue. As these are test instances, we just load the image, run it and remove it - no need to save as we are starting the tests always from a clean install.
As you know, persistency is "a bit" of an issue as you need to create a new AMI for any change to your configuration. If the instance crashes, you are back to the last saved image - only S3 storage is persistent. For 24/7 production use, you must solve external database backup and recovery. You might want also to save certain log files externally.

Looking at the cost side: Assuming a "serious" configuration (64 bit O/S, 7.5 GB RAM, 2 virtual cores, 850 GB disk) the hourly costs are $0.40 for free operating systems, $0.50 for Windows (or whatever you agree with RedHat for their cloud starter version) - resulting in $288/month for a free Linux image or $360/month for Windows - basically a slightly more than what you would pay for dedicated hosting with a longer contract. Note that in addition to the $228/360 per month you need to pay also for S3 storage and bandwidth.

With the new "reserved instance" pricing (only available for the free Linux AMIs), you can reduce the costs. So rather paying $228 ($0.40*24h*30days), you'll pay $184 for a 1 year contact or $141 for a 3 year contract per month (plus storage & bandwidth). The reserved instance plan makes sense if you use it for more than 12 hours/day with a one year and 6 hours for a three year plan.

Our way forward is to get experience with using EC2 for build & test, automating deployment and see what the real costs for data transfer and storage/snapshots will be. As we will use it for just a few hours per day, Windows is our choice - not everyone thinks that access via a ssh terminal is state-of-the-art and wants to set up remote X through firewalls.

Agile ERP Development

2009-01-23T01:47:50-08:00

When exposed to the German education system, you'll pick up the importance of methodology and planning. In the Business Administration classes, we learned how important it is to do your strategic planning (10+ years) and operational (2+ years). OK, in the late 70s the world turned a bit slower. So when introduced to the presessors of RUP (Rational Unified Process), a heavy top-down, big-bang approach seemed very sensible. Well, it worked (somehow) and I thought I just have to improve my planning skills and spend days with Rational Rose trying to get the full round-trip to work.

When starting Compiere in 1999, I know I had to do something else. Especially with Open Source, the traditional Big Bang approaches did not seem to work. So, I thought, I have to start "without a methodology". After a while, we managed to publish stable daily releases and incorporated feedback very quickly. Initially users and customers were concerned about using the daily releases in production, but our track record was persuasive. So, it became standard procedure to use a daily build in production, especially if an important bug fix /improvement was made available.

One day, a friend told me that "our agile approach" was working nicely. I was surprised that what we did had a name - so looked it up and was astonished to find the pricipals I was living actually written down. Happy to have found a name for what I was practicing for quite a while, I signed the Agile Manifesto in early 2002

As agile became more popular over the years, I saw quite a few "agile" projects. The ones which failed usually used "agile" as an excuse for no planning. Not knowing what the requirements (= intended outcome) are or even stressing that they don't want to know - is nice if you are just exploring or playing around, but in my experience the main cause for project failures.

As the founders of Compiere, Kathy and I will now concentrate on the "last mile" - the implementation of Compiere. In our trainings, we stressed the importance of Conference Room Pilots (basically an agile way of doing ERP implementations). To facilitate this process, we are looking for an Agile Project Management tool. There are quite a few good products out there. Our finalists are Rally, Version One and Target Process.

All of them have free Community Editions. We concentrated on the professional editions as we require for the support of multiple projects (= implementations). So, as usual, we came up with our list of requirements and evaluated the products. Well, this is tough - Kathy as the "requirements queen" and implementation project lead spent quite some time evaluating the products. Yes, there are differences, but from a business analyst point of view, you can achieve what we wanted with all products. Some menu systems were more helpful than others, but for the functionality we need they all are all quite suitable. The UI is always important, but also there after getting used to, there are not many differences.

So, seems it comes down to integration (Eclipse, SVN) and ultimately also Compiere. Well, I have not finished that yet - so our decision will be in our next blog.

Agile ERP Implementatation

2009-01-13T18:38:35-08:00

For some time the 'buzz' in development is Agile (aka Extreme) development. Its basic concept is that this method of development promotes project management processes that encourage frequent inspection and adaptation, a leadership philosophy that encourages team work, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. What is these same concepts and ideals were applied to the implementation process for an ERP application?

Would this work for all ERP applications? Frankly, No. The application would need to be flexible and allow the user to make changes to the basic set up parameters at any time. How else can you make adapations?
By its design, Compiere is ideal for using this methodology for implementation.

The basic Agile concept is to concentrate on the most critical point(s) at that time and solve it in a time period of about 2 weeks. The delivery of every 2 weeks allows customers to see the progress and adjust the plan based on what was learned.

A critical view is that Agile projects concentrate on short term tactics and are not appliable to complex projects like ERP implementations. I regard that actually as a misuse of the Agile methodology. A prerequisite is always that you keep the big picture in mind. So the initial planning of a traditional project and an agile project is the same. But rather going into analysis-paralysis, Agile projects concentrate on fast delivery.

Many implementations fail not because of the software, or the knowledge of the implementation team or the desire of the business community. They fail because the implementation uses the 'big bang' approach. Nothing is released for review or comment until everything is completed. If there are issues it can be too late to address them (or to costly to). By using the Agile approach, there is constant and regular disclosure and feedback to ensure that all objectives are met, or if all objectives cannot be met in the prescribed time frame, the objectives are appropriately prioritized.

Crucial to the success of any implementation is communication. Thanks to the populariity of Agile Development, there a many tools to help in communication and scheduling. These tools can also be used for an implementation.

If you do not already have a tool there are many to choose from. When selecting a tools some things to consider are:

On Premise or On-Demand
Support multiple distinct prjoects
Porject level security
Customizable user interface (this is important as you will probably want to change some of terminology like Sprint or Interation so they are more applicable to an implmentation like Phase.)
Ability to Customize workflows
Interface for external party interaction
Easy to use interface (this is of course subjective)

Many of the tools provide this and more. Some have community editions with limited functionality or limited to a single project that can be used to evaluate the product. Take advantage of the online demos and tutorials to make a better evaluation.

In the end it needs to be a tool that the team will use and will provide the necessary communication portal to help ensure a successful implementation.

Our three finalists of our current evaluation are:
- VersionOne http://www.versionone.com/
- Target Process http://targetprocess.com/
- Rally http://www.rallydev.com/

In my next blog, I will share my findings and our decision of what tools we will use.

For further reading on Agile check out the following:

The Agile Manifesto: http://agilemanifesto.org/principles.html

Overview in Wikipedia: http://en.wikipedia.org/wiki/Agile_software_development

The Agile Organizations: http://www.agilealliance.org/ and http://agilemethodology.org/

as well as a Waterfall vs. Agile comparison: http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/

Creating User Friendly Applications

2008-12-21T22:28:33-08:00

One challenge when creating an application or an extension to an application is making it easy for a new user to use and for existing users to learn new tasks. Compiere's Application Dictionary is a powerful tool as it is the engine that dynamically creates your user interface.

The functionality available in the Application Dictionary allows you to create these types of applications with very little additional effort. The main features are found in Elements, Context, Table and Column and Window, Tab and Field.

Elements

In Compiere, each field on a table (and subsequently a window) references an Element. The Elements allow you to centrally maintain field names, bubble help and online help. For each Element the Name is used for the field label in the window, the text entered in the Description field is used for bubble help, the text entered in the Comment field is used to generate the online help. Therefore when you create new Elements, if you have also entered values in the Description and Comment you automatically get help.

Context

There may be instances where for a given window you want a different field label or help. This can be accomplished in two ways. One way is to define a Context (e.g. Sales). In Context you define the new names/labels to use. Then you assign the Context to the Window. This method is best if there are multiple windows that will use the same Context. A good example of this is in the Sales windows (Sales Order, Shipment and Customer Invoice) where you want the Business Partner field to display as Customer.

The second way is in the Field entity in Window Tab and Field, change the Name, Description and/or Comment and then deselect the Centrally Maintained flag. This will prevent the system from synchronizing the terminology from the element to the window.

Another common customization is to display fields under specific conditions and hide them in other conditions. This can be accomplished by using the Display Logic in the Field entity of Window, Tab & Field. An example of this can be seen in the Sales Order window where the Rate Type field only displays if the currency of the price list is not the primary accounting schema currency.

Perhaps there are fields on a window that you do no want to display at all. In Window Tab and Field open the desired field and select the displayed checkbox. There are a few considerations if you do this however. If the field is required, make sure there is a default value. When you choose not to display a field, the screen layout may be compromised so you may have to make other adjustments.

Sometimes there are fields that users should see but you do not want them to be able to update them. This is a common requirement in Sales Orders where users can see the price list but they should not be able to change it. There are two ways to accomplish this. One is in Window Tab and Field select the Read Only checkbox. If you have some users who should be able to update the price list and other who should not you would then need to create a copy of the Sales Order window, one with the checkbox selected and the other not selected and allow access to the appropriate window to each user.

The second way is to use the Read Only in Table & Column. For the given column (in this example M_PriceList enter the following in the Read Only logic field #@AD_Role_ID@=102 | #@AD_Role_ID@=222. This will check the role that the user logged in with and if the ID is one of the values selected, the field will allow updates and if not it will be read only.

These are just a few ways you can use the Application Dictionary to create an application that best suites your needs. Just remember, if you change any entities that are defined as Compiere or Dictionary make sure you select the customization flag in Change Audit so your changes are preserved during migration.