COURSE of the MONTH

Business model - how to handle properly?

I am re-making my accounting software (the idea is to support windows/web and mobile platforms) and I need to clarify something regarding the business model. Up to now my software was nott "properly designed", so I need to redesign it in order to make it scalable and multi platform. Currently I am creating a business model, and I am not sure where to put what.

I think I am ok with main entities so far, but, as with most of the software, there are usually some statistical information which is presented to client. Example, show all invoices for which payment day is overdue. Or, show me the sales amount per day/month/client, show me stack movement per month/year, etc. Many examples like this. In the past I have done this by executing stored procedure and populating some collection with returned data.

How will this fit into the model? What is the right approach? Should I have a class for each of the different data needed?

Who is Participating?

>>You say I should store generated data in arrays - ok, what about classes that generate data? Where is their place in business model? Is it factory method involved for retrieving data?
Report (array) should be created in business layer, by invoking DAL to retrieve information from database.
I think you can have some kind of "Reporter" class in BL.

I think reports shouldn't generate business classes, just fill an array with data from the Business Layer.
These arrays are passed to the presentation layer to be displayed as a report.
Report arrays can be made of pure string, or other fundamental types by declaring an array of objects.
The presentation layer can interpret array types for proper formatting and alignment.

I was originally confused by your use of Business Model and this being cross-posted in the Project Management area. A Business Model is typically a description or concept for how an organization (or an initiative) expects to generate revenue or value.

A Business Process Model is the definition for how the various functions within an organization interact with each other and process inputs to add value within the enterprise activities to satisfy customers and generate revenue.

Now, what you seem to be describing is an Application Data Model, and you seem to be seeking advice as to whether these metrics about the financial transactions should be stored in tables or generated at run time from procedures and calculations.

Assuming this is the case, my suggestion is to keep them as real-time calculations unless:
* The complexity of the calculations and/or quantity of data (considering data growth) would produce exceedingly long execution times, or
* You intend to provide some sort of business intelligence reporting, in which case the calculations might need to be trended over time or sliced-and-diced like a pivot table.

The two conditions, however, could have different approaches. For the first, you need to figure out how to pre-cache the calculations or perhaps store running figures and then just increment the calculations by-request. This might result in relatively simple data tables to store partial, current results.

The second scenario, however, will require more thought into how to dimension the tables so that you have the proper trends and drill-down categories.

And in either case, you'll need to figure out how the processing is initiated to populate the data: manual update by the user, automatic launch or termination processing of the client, or completely separate scheduled batch processing, or...

As for classes and programming structure, you seem to have really two paths to consider: first, what is the functionality needed by the user to interact with this data? Is it a static report, or an interactive pivot table-like thing? What types of filters and sorts will be allowed?

Then that will drive considerations of the data needed to support these use cases. As Jaime suggested, then this becomes a relatively simple processes of Model-View-Controller to give the user what they need.

However, that doesn't address the logic and rules needed to get the data into the proper shape to feed the reports. If you take a fully automated, batch route - or some real-time caching scheme - then you don't really need a "View" to manage the data - just your Model and Controller.

So, without knowing your existing app and your requirements, I can't make more detailed suggestions on what classes you need - but as I see it, these are the broad categories of classes you'll need to design.

@jaime_olivares
You say I should store generated data in arrays - ok, what about classes that generate data? Where is their place in business model? Is it factory method involved for retrieving data?

@cdbosh
I appologize if my terminology is confusing, theory is my weaker side, I have just started digging into this area. Considering the cross-posting, I usually add different areas which I find that can be fitted in. Since Business Model is part of Project Management as a wider area, and my first thought was to post this question in Business Model section, then Project Management section was just added as a "bonus"

So far I have read several books about modeling (intended for programmers mostly), and I have never met with the term Business process model. Usually the authors call it business model.

[quote]Now, what you seem to be describing is an Application Data Model, and you seem to be seeking advice as to whether these metrics about the financial transactions should be stored in tables or generated at run time from procedures and calculations.[/quote]

No, I am not interested in designing RDBMS, I agree with you that most of the times calculated values should not be stored in database.

I will try to explain a little more about the things that confuse me: generally speaking, user interface (UI) should interact with the business layer (BL), which interacts with the data layer (DL). There could be some in-between layers, but I will not include them for the sake of simplicity. When displaying some statistical data, which could be a static report, or can be filtered by user (like per day, month, year, etc), UI should call some method on BL (possibly some factory method), which will call DL to retrieve data. Now, my question is where do these classes fir in the model? I dont see them as some entity, so what is the method used in these situations?

As far as the existing application requirements, it is an accounting software, so if you have ever done something similar, you will know what I am talking about. I am not 100% sure what are the terms used in english language areas, but its about keeping tracks of things like: supply, stock, sale, tracking payment on time, calculating workers pays, and many other things. I could have reports like:

1) show me the supplier bills that should be payed on this day
2) show me the customer bills that should be payed on this day
3) show me the stock movement per year
4) show me sum of all invoices from particular customer per month, quarte of year, year, etc

Now, dont get me wrong, I am not asking you how to make this reports, I already have this working for several years. As I have said, I am not recoding my whole software to support n-layer architecture, in order to make it available to different platforms that windows (like web, for example).

Up to now I did it simply by executing some stored procedure from the UI and storing data in some array. Now I would like towhere to fit all this classes in business model, that should provide me all this statistical data, which could be the source from different entities (like sum of invoices from suppliers, sum of invoices to customers).

Thanks for the additional info, Priest - and on big on the English. However, I still suggest you Google "Business Model" and "Business Process Model" so you have an understanding of their typical use related to software. Also, you should check into Model-View-Controller. It is essentially the same as DL-UI-BL (respectively), but it is the prevalent terminology in a lot of more current (i.e web-based) development.

Anyway, using this 3-tier description, you still were using this in your old approach and stored procedure. The UI called the stored procedure, but even though it's "in the database", it's not data, but program logic. Therefore the store procedure was BL, resident in your database server.

So, I think most of the new function you're talking about will be classed in your BL. For example, in report #1 above, calculating supplier billing information falls in your BL. Being able to choose which supplier and for which days you want to see the billing information falls within your UI. Similarly for #2.

For report #3, your BL will have the logic to determine what a stock movement is and how to track it. Your UI will allow the user to decide which categories of stock to display and over what periods.

Now, for performance reasons, you don't want the UI to collect all the data then slice-and-dice it locally, so you will probably still want to optimize some queries on the database server, but these should be separate from true BL program logic that implements your business rules (i.e. going back to the report #3, the BL defines what is "stock movement" because that is a business rule).

Anyway, that's pretty much all I can say being so removed. However, one other piece of advice is to consider the UI-BL-DL generically and based on what it does, not where the code resides and executes. Your UI is typically in one location, but the BL and DL can be spread out into many physical execution environments - and like I said before, stored procedures can be used to implement BL, even though they execute on the database.

Thanks you guys, much appreciated. But (I think) I still didnt get the answer to the implementation method? Is it a Static report class with like 50 static methods, or...? Or the answer is to use MVC model (I will be reading about it today)?