Technology comes in all shapes and sizes. IbleSoft has a diverse development team that can develop new technology or integrate existing technology within the following areas:
Logram Framework
1. Technical Components
2. Logical Components
3. Implementation
Flexibility
Use of constructs within status framework can be used to represent any business process in a simple, logical, temporal, and easy to understand manner. Much like a structured language for business objects, the framework empowers the modeling of business rules into a working application.
With flexibility as its core value, its ability to change and adjust to our understanding of the business model is its greatest strength. It makes possible the ability to develop application in an “adaptive iterative” manner.
The reality of application development is that when you implement a design, it brings change to the business process. This change begets new ideas and new opportunities that build on the understanding of the new implementation. This manifests in the never ending requirements phase, or analysis paralysis, or in large and constant maintenance backlogs).
It is hard enough to understand how to design a process - it is impossible to design a process based on assumptions regarding results that the process may bring. A basic understanding and surrender to the complexity and changing nature of application software leads us to believe in a process that embraces change as its core value. This we can call “adaptive iterative” application development.
Adaptive Iterative
This is the simplest and easiest way to develop application software. You gather requirements, implement, get user feedback, and begin again. In this fashion you let realities guide your design, and complexities manifest themselves at appropriate times. The focus is always on delivering something and making something work. However, this is cost prohibitive from a programming point of view.
The framework solves this problem by taking the coding out of the structural and temporal issues of an application development process. It is the structural and temporal issues that determine the basic business flow of an application. By allowing rules based non- programming manipulation of this application dimension, we empower the analyst and users to easily experiment with various iterations.
For instance, a business process for clearing a credit card is needed. Whether the card is cleared when “the goods are shipped”, or when “the goods are received by the customer” is a decision made at the business model level. In traditional implementations, coding occurs to attach this “clearing” to the “received” or “shipped” event so that process code and model code become one. In the framework model, the “clearing” code stands alone. When to call the code is left up to the framework, so that you can try calling at “ship”, then try at “received”, or even process some at “ship” and some at “received” based on additional framework logic. Notice in the framework, process and model codes are separated.
The framework creates a development environment where a premium is placed on the understanding of the business model in a temporal and structured sense. This dimension of application development is often misunderstood and difficult to implement. In traditional implementation this is viewed as a one time, one model dimension, and it’s built in rigidity keeps us from experimenting with the most volatile dimension of an implementation.
The focus and flexibility placed on the business model allows for a deeper and more intimate understanding of the requirements, and allows us to truly partner with the user to build applications that better react and support the business.
Logical Mechanics of the Framework
Think of the framework as the skeleton of your application. As you identify and add “statuses” which a transaction might experience to the Framework, you are adding the “bones” to the skeleton. As you add rules and program to the “statuses”, you are adding the “meat to the bones”.
The “mental image” which guides the design of a business model to the framework, is to view the framework as a set of stairs from which a transaction must descend. When a transaction approaches the stairs it has a generic level status of Work-in-Process (WIP). Each step on the stairs is defined as a “status” in the Framework, and within each of these statuses you may attach a fatal error, a warning error, a program, or a message. If the transaction is not capable of completing all the steps of the stairs, then it falls off the stair, and it is “cancelled” (CAN, a second generic status). On the other hand if the transaction completes all the steps, it is considered “completed” (COMP, the third and final generic status).
The “business model”, or steps, or statutes within the framework should be designed in a structured and temporal manner: Structured in the sense that the statuses need to reflect an ordered processing of the transaction. So if your statuses are created in a manner in which the business process skips several statuses forward, this is incorrect and akin to the “go to” statement in programming. You can use it and it will work, but it is not structured logic. For the statuses to be properly structured the transactions must progress in sequential order. Exception processing occurs by sending an order backwards, and asking it to repeat steps. This will yield a simple and effective framework modeling of the business problem.
Temporal in the sense that each sequential step must be built on its predecessors. Using the stairs analogy, each step brings you closer to your goal but it is built upon the previous step. This logical progression through a set of steps is the essence of designing the application. By converting the business model to ordered steps that achieve the goal, you have basically designed the business application flow.
With the four constructs supplied by the framework you can exercise the logic needed to support your vision of the business model.
This first construct is a “fatal edit”. It is simple, for each step, either you go forward or you fall off the process that is you become “cancel”. If you want to apply “cancel” logic then, you would implement a “fatal edit”. That is, an issue that must be fixed, before the process can move forward. For instance, if the credit card is not approved this is a fatal error-the only fix is to get it approved or cancel the transaction.
The second construct is a “warning error” that is the process stops, but allows you to go forward by “by passing the problem”. For instance you might have an order limit the required management approval for orders over $2,000. When an order is over $2,000, the framework will add a history message, which must be viewed and approved by a manager.
The third construct is a program. For example, you want to check for available inventory, and if possible, reverse your transaction. A program is written to achieve same and it is called whenever the transaction passes through the status.
The fourth construct is a message to history. The framework will put messages in history for the user. So in the above example we can put a message, “only 10 units where left in inventory after the order, and t we have sent an automatic e-mail to purchasing for more product”.
Physical Mechanics of Framework
Each logic point, or rule, is recorder as exercise. This leaves a complete audit trail of what the framework did.
This is used in support of application to confirm user bug reporting, ease of maintenance, support and debugging. This is also used for metrics of business process for the business. No other application can give such insight to the business.
For auditing purposes, the system is working as designed.
Tree View
This is the transaction representation of the framework for the user. The transactions are presented to the user in status and edit order and message order and the user is allowed to drill down to the order level. In essence you are presenting the data in the logical way in which that business does its work. The framework representation is basically the “to do” list for the day. This is convenient for training since you can train staff to only process one or two statuses, and can easily monitor staff progress.