none
Advice on Architecture for customized application RRS feed

  • Question

  •  

    Hi to all,

     

    This post is to claim for your wisdom and experience, I’m developing an application that provides certain standard functionalities: inventory management, orders, invoices, accounts receivable, etc. (I’ll call them core functionality) The problem here is that features solves the 90% of my customers requirements, BUT always need to make some customizations in order to fit each customer policies and special processes. So, the main challenge here is to design an architecture that allows me to make customer specific changes (most of the time they affect the database structure adding fields and/or tables, changing their corresponding UI’s for entering or viewing these new fields, adding validations, etc) without duplicating the core functionality, so if I made a fix or enhancement to the core functionality I’ll be able to distribute the changes to all my customers.

     

    I hope I explained it clear, I already tried many alternatives but none likes me at all, hope any one can help me, I’m sure most of all ever have an scenario like this, when the customers says “all is great BUT it needs just some “little” changes to fit me 100%”. At this time I’m at design stage, so I’m wide open  to fresh ideas.

     

    Thanks in advance, regards

    Tuesday, May 20, 2008 2:24 PM

Answers

  • Ruben,

     

    Ideally you would be able to find out what the finite set of variations upon the core functionality are, and put them into the design in such a way that they might be altered.

     

    Other approaches could be:

     

    • Have a fixed set of overridable functionality, where settings can switches features in or out, and customize them;
    • From a database perspective have a very fluid column definition table that can define the small number of special columns within the application.  Obviously you have to still have some idea what these might be.  Design some plug-in code, such as a provider pattern (strategy and factory patterns) to them write custom implementations for those custom columns;
    • Write the core functionality in such a way that it has a public API, in so doing view the core functionality as part of a framework, but a part of that framework that is always available with a solution, then the custom development effort then works around adding that specialized bit of functionality to the core to make it do what the customer wants.

    The first options requires that you know all customizable aspects of the system before designing it.

     

    The second option would be a less coupled design, but that could possibly lead to lowered performance since the functionality is forced through a plug-in enabled design pattern.  I would pick this design if performance was less of a concern, or the amount of extra customer specific client code is relatively small (thus having a lot less opportunity to affect performance)

     

    The third option would be for all the opposite reasons.  The solution would probably be less maintainable, since it is likely to be more directly coupled to the API, and any maintenance issues arising from managing changes in that public interface.  You're more likely to be able to get extra performance gains due to being able to hook into 'the guts' of the solution, but that obviously comes at the cost of it being less maintainable.

     

    I hope that this helps,

     

    Martin Platt.

    Tuesday, May 20, 2008 10:53 PM
  • Take a look of this demo made by Miguel Castro on Extensibility: http://dnrtv.com/default.aspx?showID=69

     

    I feel that for your particular description, achieving the last mile of customization, Miguel's ideas on extensibility could be fine

     

    I found also some comments on a famous presentation Miguel has been lastly doing, called "Sexy Extensibility Patterns"

     

    Take a look at Scott Hanselman's blog

    Tuesday, June 17, 2008 11:49 PM

All replies

  • Ruben,

     

    Ideally you would be able to find out what the finite set of variations upon the core functionality are, and put them into the design in such a way that they might be altered.

     

    Other approaches could be:

     

    • Have a fixed set of overridable functionality, where settings can switches features in or out, and customize them;
    • From a database perspective have a very fluid column definition table that can define the small number of special columns within the application.  Obviously you have to still have some idea what these might be.  Design some plug-in code, such as a provider pattern (strategy and factory patterns) to them write custom implementations for those custom columns;
    • Write the core functionality in such a way that it has a public API, in so doing view the core functionality as part of a framework, but a part of that framework that is always available with a solution, then the custom development effort then works around adding that specialized bit of functionality to the core to make it do what the customer wants.

    The first options requires that you know all customizable aspects of the system before designing it.

     

    The second option would be a less coupled design, but that could possibly lead to lowered performance since the functionality is forced through a plug-in enabled design pattern.  I would pick this design if performance was less of a concern, or the amount of extra customer specific client code is relatively small (thus having a lot less opportunity to affect performance)

     

    The third option would be for all the opposite reasons.  The solution would probably be less maintainable, since it is likely to be more directly coupled to the API, and any maintenance issues arising from managing changes in that public interface.  You're more likely to be able to get extra performance gains due to being able to hook into 'the guts' of the solution, but that obviously comes at the cost of it being less maintainable.

     

    I hope that this helps,

     

    Martin Platt.

    Tuesday, May 20, 2008 10:53 PM
  • Hi Martin,

     

    Thanks for your ideas,

     

    The first approach is the most desirable, however in my experience it's very hard to find out all the customizable aspects, because it depends on each customer policies. Until now in my current version of the system I added all the custom code in a same unit as it becomes with each customer, and using parameters enables/disables functionallity, this is the better way I found to reduce maintainance on the core components. But it's not an elegant and practicall way to do this.

     

    The second approach is closer to what I'm expecting, the database is not my main problem, I already have a solution for that, my main problem is in the user interface and your sugestion of using plug-in sounds good for me, but I'm not sure how to implement it without complicating so much the core. I want to deploy the core functionality (DL, BL and UI) and when a customer comes with a new requirement I'll like to create a new UI (derived from the core UI) and add it's requirements. Then just deploy the plug-in with the customer, and the core functionallity needs to call the plug-in, instead of my own code.

     

    Do you have any advice on this approach?

    Friday, May 23, 2008 3:04 PM
  • Take a look of this demo made by Miguel Castro on Extensibility: http://dnrtv.com/default.aspx?showID=69

     

    I feel that for your particular description, achieving the last mile of customization, Miguel's ideas on extensibility could be fine

     

    I found also some comments on a famous presentation Miguel has been lastly doing, called "Sexy Extensibility Patterns"

     

    Take a look at Scott Hanselman's blog

    Tuesday, June 17, 2008 11:49 PM
  • Diego,

     

    Thanks for the link ... that's exactly what I was looking for

     

    Regards

    Wednesday, June 18, 2008 11:13 PM
  • Hi to all,

    I'm having a similar problem that ruben originally did, where I have a core program, needing small form-level as well as code and database level changes for each client. I checked out Miguel Castro's video, but I had trouble understanding exactly what he was doing, and moreso, how to implement his strategies into creating a core program with different 'branches' for different clients.

    In the past, I would copy the entire solution and reprogram it for a new client. The real problem with this being, that if I made any updates to the program, I would have to go back and program those changes into every other client's solution, thus adding hours of needless work.

    Should all of my clients be getting the same solution, with different plugins for each? Or should they each have their own solution, all of which reference a set of core classes? Should the code/database level changes lie in the solution's configuration file? I feel like I am missing a key bit of knowledge in the realm of architecture for this type of program.

    Any help would be greatly appreciated.

    Thanks in advance!
    -Bassil
    Wednesday, July 30, 2008 3:47 PM