Modular Approach for large scale Solution
-
I am to create an ERP Solution in .NET and I want it to be a module base application. I am unable to figure out how can I do this. Any suggection regarding modular approach is highly appreciatable. Thanks
-
I am to create an ERP Solution in .NET and I want it to be a module base application. I am unable to figure out how can I do this. Any suggection regarding modular approach is highly appreciatable. Thanks
Umair Feroze wrote:
Any suggection regarding modular approach is highly appreciatable.
Break your problem down into small modules and develop from there. This is too much of an open question to get a short answer, and you have not described what your application will do (what is ERP?).
Just say 'NO' to evaluated arguments for diadic functions! Ash
-
Umair Feroze wrote:
Any suggection regarding modular approach is highly appreciatable.
Break your problem down into small modules and develop from there. This is too much of an open question to get a short answer, and you have not described what your application will do (what is ERP?).
Just say 'NO' to evaluated arguments for diadic functions! Ash
Richard MacCutchan wrote:
what is ERP?
Enterprise Resource Planning, probably.
"I love deadlines. I like the whooshing sound they make as they fly by." (DNA)
-
Richard MacCutchan wrote:
what is ERP?
Enterprise Resource Planning, probably.
"I love deadlines. I like the whooshing sound they make as they fly by." (DNA)
Definitely ERP Stands for Enterprise Resource Planning and my project covers inventory management till payroll creation. It covers inventory mangement, sales and purchase, an Accounting System, an HR system including payroll system. Although I am developing all these as individual projects but the thing which is worrying me is how to join all these in a way that incase of adding another system I dont have to change the code for my project. I just create another project compile it and just plug into the system
-
Definitely ERP Stands for Enterprise Resource Planning and my project covers inventory management till payroll creation. It covers inventory mangement, sales and purchase, an Accounting System, an HR system including payroll system. Although I am developing all these as individual projects but the thing which is worrying me is how to join all these in a way that incase of adding another system I dont have to change the code for my project. I just create another project compile it and just plug into the system
I assume you are talking about dropping in different modules at runtime, without having to change any code to add them. If you are, then you are talking about creating a plugin based system - and I'd recommend using the Managed Extensibility Framework[^].
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
Definitely ERP Stands for Enterprise Resource Planning and my project covers inventory management till payroll creation. It covers inventory mangement, sales and purchase, an Accounting System, an HR system including payroll system. Although I am developing all these as individual projects but the thing which is worrying me is how to join all these in a way that incase of adding another system I dont have to change the code for my project. I just create another project compile it and just plug into the system
An ERP system is a huge project to tackle, and if it is to be a generic system, where the user can configure the ERP in a way that suits his business, then the complexity becomes multiplied. Having worked a lot with ERP systems, you are going to have to dedicate several years to it if you are working on your own. The practical solution would be first to buy a ready-built accounting system with APIs to hook into. Then you need to think deeply about the clients business, and decide what functions he will require - sales and order management, inventory management, inventory obsolescence, parts supercessions, labour billing, JIT ordering, bin location systems - the list is huge, and unless you are deeply familiar with the client's business, it is several months work on its own, before you even start to design the project. In the last five years I have seen three major ERP projects fail due to a failure of the vendor to understand the client's requirements, so think very carefully before you take this on.
-
I assume you are talking about dropping in different modules at runtime, without having to change any code to add them. If you are, then you are talking about creating a plugin based system - and I'd recommend using the Managed Extensibility Framework[^].
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
I am very gratefull to you for your guidance. It is the thing I was looking for. Thanks again :)
-
An ERP system is a huge project to tackle, and if it is to be a generic system, where the user can configure the ERP in a way that suits his business, then the complexity becomes multiplied. Having worked a lot with ERP systems, you are going to have to dedicate several years to it if you are working on your own. The practical solution would be first to buy a ready-built accounting system with APIs to hook into. Then you need to think deeply about the clients business, and decide what functions he will require - sales and order management, inventory management, inventory obsolescence, parts supercessions, labour billing, JIT ordering, bin location systems - the list is huge, and unless you are deeply familiar with the client's business, it is several months work on its own, before you even start to design the project. In the last five years I have seen three major ERP projects fail due to a failure of the vendor to understand the client's requirements, so think very carefully before you take this on.
I am very gratefull to you Chris. Your advice is very handy and I will keep these points in mind during analysis phase. Thank you so much :)
-
Definitely ERP Stands for Enterprise Resource Planning and my project covers inventory management till payroll creation. It covers inventory mangement, sales and purchase, an Accounting System, an HR system including payroll system. Although I am developing all these as individual projects but the thing which is worrying me is how to join all these in a way that incase of adding another system I dont have to change the code for my project. I just create another project compile it and just plug into the system
Yeah just like Pete said. But sooner or later the day will came when you'll need to modify almost everything at least in a module if not all. Situations like: Up till now you(not you personally, the company/people) moved a product from an area to another eg from production to warehouse for example. Then they decide that they want a more detailed transaction so instead of moving from production to warehouse you will have to move them from the production line to the warehouse. Or the other way around meaning that management decided that they don't need such detailed transactions. Such modifications are bound to affect many reports/modules. So the best thing you could do is make it pluginable(sorry if the word doesn't exist) and try to design the app/modules with such modifications in mind. Even then someday you(the team) will have to modify large bits of code. After all an ERP system is meant to accommodate the businesses of a particular company/plant. If/when that changes you'll have to change it too. I've done something like this a little while ago. Fortunately I was familiar with the business process and I anticipated some of the possible changes. But not all of them. Best of luck. :)
All the best, Dan
modified on Tuesday, December 28, 2010 10:10 AM
-
Yeah just like Pete said. But sooner or later the day will came when you'll need to modify almost everything at least in a module if not all. Situations like: Up till now you(not you personally, the company/people) moved a product from an area to another eg from production to warehouse for example. Then they decide that they want a more detailed transaction so instead of moving from production to warehouse you will have to move them from the production line to the warehouse. Or the other way around meaning that management decided that they don't need such detailed transactions. Such modifications are bound to affect many reports/modules. So the best thing you could do is make it pluginable(sorry if the word doesn't exist) and try to design the app/modules with such modifications in mind. Even then someday you(the team) will have to modify large bits of code. After all an ERP system is meant to accommodate the businesses of a particular company/plant. If/when that changes you'll have to change it too. I've done something like this a little while ago. Fortunately I was familiar with the business process and I anticipated some of the possible changes. But not all of them. Best of luck. :)
All the best, Dan
modified on Tuesday, December 28, 2010 10:10 AM
I am gratefull to you Dan for a very good piece of advice. It's very handy to have suggestions from the ones who have already done the work on ERP. Thank you so much. :)
-
I am gratefull to you Dan for a very good piece of advice. It's very handy to have suggestions from the ones who have already done the work on ERP. Thank you so much. :)
You're welcome. Oh, and it's not that hard really. Just a lot of work(huge if just one person) and most importantly carefully design of the businesses process. If you're not familiar with it, I suggest you take some time to familiarize yourself with it and then start designing/developing the app. :)
All the best, Dan
-
I am very gratefull to you Chris. Your advice is very handy and I will keep these points in mind during analysis phase. Thank you so much :)
One other thing for you to keep in mind, which latches onto MDL=>Moshu's comment - at all costs try to avoid inter-process communication, and make everything database-centric. If not, when you have to redesign a module, you will find the changes rippling through just about every other module that the first one touched. Modding the DB and a couple of modules is easy compared with a major rewrite.
-
Definitely ERP Stands for Enterprise Resource Planning and my project covers inventory management till payroll creation. It covers inventory mangement, sales and purchase, an Accounting System, an HR system including payroll system. Although I am developing all these as individual projects but the thing which is worrying me is how to join all these in a way that incase of adding another system I dont have to change the code for my project. I just create another project compile it and just plug into the system
Umair Feroze wrote:
It covers inventory mangement, sales and purchase, an Accounting System, an HR system including payroll system. Although I am developing all these as individual projects but the thing which is worrying me is how to join all these in a way that incase of adding another system I dont have to change the code for my project. I just create another project compile it and just plug into the system
This is would be a large project even for a relatively small company. The larger the company the more complexity involved in the integration. A simple example is a company might want to manage contractors as personal (human resources) while paying them as a project expense rather than a payroll expense. An inexperienced developer is unlikely to get the functionality of the individual components correct much less correctly architecting/designing the cross project needs correctly. As an example of this corrrectly implementing point of sale taxes for a retail company is a very complicated task. Not to mention of course that any cross project needs are directly dependent on the business needs of the company itself. Thus the first step is to learn the needs of the company.
-
One other thing for you to keep in mind, which latches onto MDL=>Moshu's comment - at all costs try to avoid inter-process communication, and make everything database-centric. If not, when you have to redesign a module, you will find the changes rippling through just about every other module that the first one touched. Modding the DB and a couple of modules is easy compared with a major rewrite.
:thumbsup: Totally agree. I mean we created separate let's call them apps, for moving a product(s) from one location to another, from Quality to Scrap from prod to qual .... The apps were available as some small asp.net web apps for desktops and as a "desktop" app(.net compact framework) for the wireless scanners/pc(windows ce). Specialized to the max. No big huge thingy.
All the best, Dan