Level 1-2-3 Apps for SMBs

Small to medium businesses are inherently efficient, or at least have the potential to be inherently efficient, as decisions are made close to the action. In Systems theory terms, the SMB is a closely integrated system.

Points of pain for SMBs often arise because of integration needs, whether it’s off-the-shelf software that doesn’t talk to other off-the-shelf software, or missing pieces in the software puzzle. These pieces tend to be small, but can have major impact.

Using our tools, small apps that fill in the cracks can be produced quickly and cheaply. We are calling those Level 1, Level 2, and Level 3 applications. These applications will all run on a local network, but also be accessible by secure connection from the internet. The applications will, as all our applications do, be accessible by computer, tablet, or phone.

The levels describe complexity, time to delivery, and cost. Level 1 delivers in 2 weeks and costs $2,000 including provision and installation of the Cloud Server software on one of your computers. The Cloud Server serves up the apps on your network and, if you wish, over the internet. Level 2 is 4 weeks, $4,000, Level 3 is 6 weeks, $6,000.

We like Level 1 apps the best: breaking a large problem into easily solvable little problems has the best likelihood of success, in life and in software development.

We will ask you what makes this expenditure worth it to you. Why? Because if you’re looking forward to having the software because it solves something you want solved, you will be motivated to work with us and make it work. If you’re doing it because you are forced to, well, let’s say the result often is not pretty.

We will have our level123.com website operational shortly, so we can lay out the process and so forth in greater detail, in its own context.

The Rule Of The Domain

The word "domain" has more than one meaning in software development. It can mean, as it does in xCase, the collection of field types that specify more than just the basic field settings, including things such as default caption, allowed values, etc. That way when adding a field (column) to to entity, all that other metadata flows to the initial field definition. Another meaning for domain is the particular set or collection of knowledge that the software expresses or articulates. The Retail Inventory Management Domain is different from the Point Of Sale (POS) domain, which in term is different than the Logistic domain, and so forth. A domain in this latter sense is characterized by having boundaries, and by having great depth.

Generally speaking, looking at areas of activity that embody complexity, it takes a minimum of 10 years to master a domain. Within 2 or 3 years some proficiency will have been gained, but the internal map that guides in new situations takes longer than that to develop. 

The great impedance mis-match in software development is between domain knowledge and software development ability. The old "waterfall" approach was to specify everything the software needed and have the knowledge flow down, through the system architect to the software engineer. It doesn't work. Putting aside workflow issues involved with the waterfall development  paradigm, there is a critical mistake made in assuming that a domain can be fully articulated by a domain expert. Can a surgeon articulate that internal map that let's her deal with the unexpected? Can a baseball shortstop? Can a psychologist articulate that internal map that guides him when helping a unique individual (and we are all unique)? The fact is, that internal map is articulated only in context, in the context of use.

What this argues for, and what we have been doing for over 15 years now, is getting the professional software developer out of the way of the domain expert. In this model, the domain expert is given the tools to articulate the domain in context -- the context the software is being made to serve. The role of the professional software developer, in domain expert software development, is to provide the tools the domain expert needs to express the domain. The domain experts with whom we have worked extensively (in the fields of HR, Trash Management, Retail Inventory Management, Nuclear Facility Management) are among the best in the world. They are not professional programmers, but their software is professional software, and competes well with software written by large teams of programmers, at great expense.

Our use of metadata and frameworks makes all this possible. That plus custom improvements to our libraries based on their needs. And working with the developers of the tools we use to foster integration with our tools. No where has this been a better match than with our current (and future) choice of the Lianja development and deployment stack.

Import, No. Import To Migrate, Yes

"The whole is larger than the sum of the parts." That's an idea I ran across some 45 years ago, and it's something I find useful in looking at software applications. We have all these parts that relate to each other, and somehow get things done that are far beyond the capability of any of the parts. Systems Theory says the same thing, but with more detail, encompassing the idea that ihow the parts relate to each other creates an entity of its own, called a System.

Looking at a VFP application, we find that, in one way or another, there is a starting point that has one important component, after which the system takes over. When that starting point was created (during a FoxPro beta in 1992) it was called The Mother Of All Reads, in humorous reference to the first Iraq War, which was billed by the then-Iragi dictator as "The Mother Of All Wars."

If you have programmed in VFP, you recognize it as 


Lianja has no READ EVENTS. It has a CLEAR EVENTS, as a Form (which is different than a section, the principal Lianja UI object for displaying controls, much like a VFP form is the principal UI object for displaying controls) issues an implicit READ EVENTS, which is cleared when the form exits, or when a CLEAR EVENTS is issued. In other words, the Lianja "application system" is configured differently from the VFP "application system." This is not the only way that the two systems are configured differently, in fact.

So this means that you can't look for a one-to-one match between your VFP program, and the Lianja program that you are building to take the place of the VFP program. You need to work within the Lianja System, not the VFP System.

And that means learning to understand the Lianja System. There are many great documents on the Lianja site that give you a comprehensive map of the Lianja system. To quote the founder of Systems Theory, "the map is not the territory." If I give you a comprehensive map of downtown Manhattan, you can study the map all you want, and you still won't know downtown Manhattan. Using the map will help you get around Manhattan, and as you spend time there, you will get to smell the fresh bagels at Ess-a-Bagel (1st & 21st) and observe the patient line of people waiting to pick up their bagels. And if you stay long enough, you'll get to know the patterns of what people do, and recognize the small, unnamed neighborhoods  defined by who goes to what Greek coffee shop the same time each morning, and who goes to which dry cleaners and which Korean neighborhood store.

In other words, to go beyond the map to the territory, you will have to spend time experiencing the territory, working from the map (in order to save a lot of time). You need to enter the Lianja System, just as you would enter a somewhat foreign culture, in order to know the system, how the parts relate to each other, in detail, beyond what any map can give you in the way of in-depth knowledge. In fact, what you are doing is creating an experiential map that is far more complex than the paper map from which you learned.

That's why you can't simply import your VFP programs to Lianja. Your job as a developer is to deliver an application that takes certain inputs and products certain outputs. In order to do that, you need to work from inside whatever system you are using. Lianja, as did VFP, gives us a system we can get to know rather quickly (compared to many other systems, which shall .not* be named <s>). Lianja and VFP are different systems, for good reason. Each is consistent with it's purpose, and designed to fulfill that purpose: that's the nature of Systems. You can use the parts of the your VFP program, you can not use the VFP system within Lianja.

Import, No. Import To Migrate, Yes.

* To be fair to .NET: is is a brilliantly architected software framework, from a Computer Science perspective. It was not created from the perspective of application developers. For example, it shipped with some 44,000 classes, and one estimate has it having 200,000 classes now. In other words, it is a system that has to be approached from the map, not by an internalized map created by experience. When I realized that, back in 2001, I realized it was not going to work for what I do with software.