4 Replies Latest reply on Nov 6, 2015 10:29 AM by golife

    Application Design for complex systems

    golife

      Even though we started developing an ERP system for small companies, we are considering how to design a system using FileMaker which has the possibility to scale, and allows not just one developer to work on the system at remote places, making maintenance not a nightmare, and shipping new versions and fixes to multiple clients just as easy as it can be.

       

      Imagine a complex piece of business software with many customers who are using the same application, but everyone also with some specific individual needs. Individual needs are a problem in its own.

       

      Reading a lot lately, the decision is still not yet clear.

       

      • We are thinking of dividing the application into modules which are represented by Filemaker files. So, not everything will be in one file. But one file will contain a data structure with many tables and be designed with the Connector-Selector model in mind. This would also allow us to sell modules (e.g. CRM, Accounting, Sales, etc.)
      • How then will these modules best be able to inter-connect and talk to each-other?
      • Some basic tables (e.g. files which contain tables for general things like list of languages, list of country codes, list of tax rates, list of user interface elements in different languages, could also be kept separate and therefore accessible to every client. Such data almost never changes and will be accessible to everyone.
      • Also thinking to maintain a database that holds all the meta data about the application with all tables, all field names, all attributes, even SQL queries, and which could not only serve to make functions and modules behave in a more generic sense referring to names, functions, etc in these meta or system tables.
      • Also we are thinking of separating data from the user interface. The UI file would contain all validation for entries, but we do not yet understand the limits as to how far this can go in a complex environment. Are there performance issues? When to break the rule?

       

      My questions - and I hope they are of general interest - and certainly not discussed the first time.

      • Is there any "best practice" around for implementing such more complex multi-client, multi-language, multi-user application?
      • What should be avoided? What problems are associated? What does not work?
      • What are the problems in completely separating data from the UI?
      • With a separation model: Does it make sense (not in terms of logical divisions, but in terms of technical usefulness) to use different files representing modules as opposed to have all in one data file, and in one UI file?
      • Is there any "framework" around which supports such development to not have to invent the wheel again and again?

       

      With greetings

      Roland

        • 1. Re: Application Design for complex systems
          bigtom

          Multi client? Well if it works for one client it will work for many.

           

          Multi language? Build in provisions for at least 5-10 languages for growth. Maybe more if you have a need. Adding this later can be a pain and it is usually fairly easy to just setup space for a bunch.

           

          Multi user? If you are using FMS I do not see this as an issue at all. FM14 seems to have better security for simultaneous edits of the same record.

           

          Best practices? I would say come up with a naming convention that makes sense and stick with it.

           

          I recently moved a complex system into data separation model. I was warned of a few issues but nothing really caused big problems. The issues a few but workable.

          Value Lists need to be available in the UI file.

          You need to realize that some scripts may be disconnected a bit.

          The use of global variables usually goes up.

          Some data, fields and merge fields, will not update in the UI client display even when the data file shows updates. Use refresh object with an object naming convention that makes sense as well as refresh page to get the fresh data.

          If there is data from both files on a layout and one file is not available nothing on the layout will display. Weird, but it happens.

          Security in both files needs to be the same.

          Some people like abstracting everything between the files.

           

          Separating the data into different files is up to you. You may consider that with the proper security the entire solution can be kept in one data file and with a UI file update the new modules become available. This may provide a better upgrade or expansion path for your clients. You may even have the solution doing many of the extra things but not giving visual access to it with the UI file update. This reduces any downtime in the data file.

           

          Separate UI files can be an issue in FMGo as each new file needs a new window. I would lean on one UI file with Layouts available as you specify them to be. Essentially, everyone gets the full suite and you limit usage of the modules through security. I think this makes it easier to manage overall.

           

          No idea on a framework. You may be able to get something to start off from a good developer for a fee.

          • 2. Re: Application Design for complex systems
            golife

            Thank you very much bigtom ))).


            Yes, you are underlining what I was and what I am thinking about. It is very good to receive such confirmation that thoughts are going into the right direction.

             

            I am continuing to think about details. The devil is in the "details" - or not?

             

            Hoping to continue the discussion.

            Roland

            • 3. Re: Application Design for complex systems
              miler24

              Roland,

               

              I believe we've tackled everything you mentioned with our "Kosmas" solution.  It's likely the "framework" you're looking for.  It's a fully FileMaker based ERP designed for small to mid-sized firms (3 - 1000 employees).  It has specially designed interface files for desktop, tablet, phone, internet browser and client web portal using FileMaker Pro 14, Go 14 and WebDirect.  It's fully data separated with two data files residing on FMS 14.  It can be deployed either on-premise (Mac or Windows) or hosted on Azure.  Most of our users our unaware that it's FileMaker they're using and don't handle any hosting or other IT issues since we've made initial deployment and updating of the solution 100% automatic no matter where they are.

               

              We can host between 25 - 60 clients per server.  Each client has around 3 to sometimes hundreds of users.  This allows us to have a relatively low cost per user that's reflected in our pricing.  The system works very well in low-bandwidth environments due to data separation and heavy use of PSOS.  Our FMGo solutions include both offline and online features which including syncing.

               

              At any given time, we have up to 10 developers working on the solution simultaneously.  When we're ready to push an update, our automatic update process handles all the schema, layout and server configuration issues as it batch processes multiple client updates in sequence.

               

              We have clients using it for construction, field service, manufacturing, healthcare, trucking, laboratory, hospitality, retail and more.

               

              There are over 80 modules included with the solution which cover everything from initial CRM through full job-cost based accounting on the backend.  It's also fully multi-lingual, includes over 1500 access permissions, tracks usage history and keeps an audit log of changes users make to records.  Keep in mind, development of an ERP isn't cheap.  To date, we've spent over 40,000 labor hours on it's on-going design.

               

              There're a lot of lessons learned along the way.  I wish you the best of luck in your solution's development!

              • 4. Re: Application Design for complex systems
                golife

                Dear Eric

                 

                How to get involved? There are some specific user requirements though which are needed to be done for my client, and we would need our own user interface and have an open version to work with.

                 

                Otherwise, sure, such work you are doing is what I was planning to do with a team myself, and instead of reinventing the wheel, it is better using such modules already developed.

                 

                There is so much more to be developed and done... I see no end. )

                 

                Currently for me it is mainly construction industry. And there are local specifics, and quite a sophisticated way of calculating and offering to clients also based on a certain industry standards used.

                 

                Let me know. What does it cost to get involved? You could contact me off-list any time. Or what should I do?

                 

                Or write to babanin.ltd@gmail.com.