This post is about frameworks, toys, design, usability, copy/paste and education.

I recently had the chance to help some friends to build a new on-line store.

The are called www.HandsOnEducation.ro and promote and sell educational toys all over Romania. Education is good, more if it’s for kids then it’s good for the long term. As I am a supporter of our own products I proposed them to use o ur own ERP OptimusERP to handle the accounting, financials, billing and other important aspects of their business.

The story line is important because it reveals important aspects about application architecture. This new and soon to be famous HandsOnEducation on-line store for educational toys begun in November 2009 when they bought some famous brands and started their business. Because the friends I am talking about had experience with other ERP software I considered a minimal introduction would be enough, so I explained to both of them the basics of the OptimusERP, gave them the CHM manual and decided to offer support if things go bad. It was a pleasant surprise to hear that they managed to discover very quickly how to input in the application the “Received Invoice” and to follow all the steps which will make the products appear in the stock. Due to an exhibition they were supposed to be present (something about kids) they did not have the time to input all the received invoices.

The OptimusERP is based on a 3-Tier architecture functioning very well on low speed connections (even 64Kb), but due to the crowded atmosphere at the exhibition they decided to sell “off-line” and to input the data in the application afterwards. Finishing late and starting early, everybody was too tired to be able to type in the data at the end of the day, so they decided to type in after the show.

Immediately after the exhibition, the first customer came on-line and made a significant order (it was about 100euros, a hand constructible Eiffel Tower). The invoice was introduced in the app, the warning messages ignored and everything went well. The customer paid, money received. Other customers came, things got busy again, but well it’s good to sell…

Several days passed and they managed to enter in the application all the invoices, received and sent. I was asked to help them see the stock values. It is now I realized we missed an important point. A part of the application was configured to allow negative stock, and we used it as it is. So actually we informed the system to sell me objects which I hadn’t yet in the database. No problem I said. Let’s call a consultant and see what options we have.

As you might imagine the only option was to remove all the sent invoices which were introduced before the stock was populated with items, and input them again. I kindly asked them to do this, while helping them to do it faster. After finishing with this we found out that due to fatigue we missed the selling documents at the exhibition. So decided to input them also. As you can imagine that is prior to all the selling we performed. After typing them in, the stock was OK finally, but with one problem: the prices in the stock. This is another important accounting thing because of a FIFO option we had, so this must be corrected also.

In conclusion this lead to two late evenings working the OptimusERP to retype in almost all we had, in the correct and proper order. Doing this on a daily basis, 5 invoices per day is ok, but to type 20 per hour is not so funny. I cannot tell how much I missed the old copy/paste, the EXCEL tables and the undo of Word. I discovered in these hours some major improvements we should perform to our app which I will share with you.

Please note these are not particular problem of our ERP, we designed and implemented it according to “proven” architectural guidelines, well marketed techniques, using best-of-breed frameworks and so on. A lot of the products on the market are designed this way.

Here is what I learned:

1. No complete training course leads to many later phone calls.
2. Critical warning sign ignored might lead to inconsistency in stock values
3. Adding in selling invoices in the improper order and skipping invoices messes up your stock operations
4. A document is not a set of records, it’s a document. It should be kept as a whole until you decide to input it in the application and be processes.
5. Undo is a bless, undo should exist for everything. I know a certain order should be preserved but it’s not impossible.
6. People like to be able to type in a document even if it’s not consistent with your database. Let the checking of consistency/validation for a later step.
7. People like copy/paste of documents or cells in tables/etc. Record based/web based systems are not copy/paste friendly. Hardly you can copy a set of records.
8. The critical reports should be presented to the user early on.

Starting a new business goes with a lot of enthusiasm and I believe my friends at HandsOnEducation have more than what it takes to make this move. Helping them starting off helped me realize once again how important is to actually put yourself in your customer’s shoes.

In the next post I will share with you the changes we performed in the architecture and usability of our app and how did the educational startup receive them.

This article is inspired by Udi’s post Non-functional Architectural Woes.
“This is how the business has been done for decades and will continue to be done for decades more” (Udi Dahan 2010)

As we build enterprise systems we are confronted with continuous change in the business requirements while the business as a whole remains the same as time goes by.

In a previous post i was investigating the possibility to indentify and cover the entire scope of the project using fractal theory. Based on the fact that scope of a project is discovered as we and are constructing the system, a method for uniformly (in terms of distribution) discovery of new parts of project scope would be appreciated.

One might notice that business objectives resembles to its business area, but are also somehow particular. The more you add businesses objectives together the more they look closer to the whole industry pattern. The more you dive into one’s business speciffic objectives, the more you find differences from the industry though keeping an resemblance to the whole. Makes me think again to fractal theory. The attached movie shows how a mathematical figure (the Mandelbrot set) is zoomed in and shows us details about it’s composition and resemblances of the initial picture.

As Udi says, and I kind of agree, the architectural pillars we should be interested in discovering while building an application should be close related to the functional requirements, more specifically business objectives. Decomposing the business objectives into smaller objectives (specific to the particular business and not the the whole) is quite hard.

It is not hard to decompose business objective into smaller ones because we don’t know how, it is hard because we have no clear knowledge on how to identify the real valuable objectives and to cover all of them. We should seek the method for covering all, the method for identifying the processes valuable, all-in-one the method (the fractal function as one might say). And if this method is applied over and over it might guarantee that we are able to find the all the most valuable objectives which if implemented might lead us to a stable business architecture.

You might say that agile methods cover this by iterating and clarifying objectives as the software evolves, whereas Waterfall methods rely on well documented living documents. Both strive to complete the business objectives.

One method, which I can guarantee to work if applied over and over, is to read and comment what other great guys have to say about things you are trying to discover, to be inspired by them and to constantly learn about the targeted business domain.

I am very happy as I just received the 7 edition of the architecture journal.

Many thanks to the distribution services as they can reach Romania with this one.