We are starting to write apps to replace several business systems that we currently run in FileMaker. Some of them are:
POS
payroll & employee scheduling - the internal employee management app
employee payroll app - lets employee order lunches, review time cards, etc.
CRM / main business management system
We are wanting to move to locally hosted web apps to replace these systems. The main question we have is whether or not it is better to write “one big web app” that uses workflow permissions to determine what a user can access within the app, or several smaller, more task-focused apps, which users access separately? I hope I did an adequate job explaining this. Perhaps an explanation of some typical access patterns may be helpful.
User 1 - basic employee - The employee will access their workplace app, which for this example, is the POS app, and they will also access the employee payroll app.
User 2 - manager - Employee will access the POS as well as the internal payroll management app to enter timecards, plus access the employee payroll app for themselves.
User 3 - operations executive - will access all apps
I would write one big app, mainly because it would be easier to maintain one big app than many small apps.
also you can share a lot of code in a single app, it would be more difficult to share between many apps (even though xojo can do it)
also how many code developers are on this project ?
I would write multiple apps for each major business category or sub category… but might lean towards a centralized database (with appropriate triggers etc internal)
Why?
Scalability… pure and simple
In the future you need to add a new business category, write a new app to add
One of the existing categories needs to be updated due to new laws or company policy? Why take down the entire system?
One of the companies I worked for had an Employee Timecard App… employees managed their time, and managers monitored/approved, and HR cut checks… but for security reasons not only were certain employees denied access to portions of the system, those parts were located on totally different servers.
Not only this, but it allows you to (if you desire) to deploy this project over time, instead of one lump …
I’d do one big app and do user security that only shows the parts setup for that employee. User3 gets to see everything, User 2 and User 1 see only their respective parts. Although you might want to make it more fine toothed as sometimes you’ll have that one person do that one thing that not everyone else of their category can do. So even though a User1 might be low level they need access to view some sales thing whereas no one else can even see it. We’ve implemented a bunch of View/Add/Edit/Delete permissions on the various forms. It can get quite complex.
Does it have to be complex? A single gatekeeper function with one parameter for the permission being sought can be used everywhere and checks the user (and group) settings.
Depends on the granularity you need. If you want simple either they get to it or not that’s one simple. But in some of our apps the client decided they wanted each form/function to have View, Add, Edit, Delete options and have default Security Groups that could be applied to a user and then have the ability to set each user differently from that group. Not hard, just complex.
It’s really about how much functionality you want (or need).
FWIW, we’ve done apps for clients for all 4 of your items. Payroll gives me nightmares, still, from several projects: One handled every state in the US and province in Canada, and the other was for teachers in the state of KS and I’d be hard pressed to tell you which one was a bigger pain.
Most of our security will not be granular. For the most part, security is handled by class of employee as opposed to on a per employee basis (although, the method we use in Filemaker which we plan to perpetuate makes it fairly simple to adjust workflows on a per-user basis as it’s all in a DB).
I think the main problem we are facing is how to handle sign-on across multiple apps (and if it’s even a big problem).
For example, User 2 needs to get into the POS to run retail transactions but switches back and forth on his downtime to build out the employee schedule. If it’s separate apps is there any way to log in one time and have that perpetuate across multiple apps securely?
We’re not sure that that use case is common enough to even factor into the discussion since we’re still working to break that Filemaker mentality.
Similarly, I think the concern with large multi-function apps is somewhat affected by the Filemaker way of thinking since each file includes all of your data, unlike Xojo + SQL where the scope of data any one application handles doesn’t necessarily correlate to application size.
@Dave S
Is it not possible to build the app in modules and roll out updates as progress is made?
Sorry if that is a silly question, like I said above, the migration from Filemaker is requiring a big shift in planning and thought processes.
@Kem Tekinay
There are approximately 230 employees. As for the shared code, there is not much other than the logins, and the DB requests. Everything else will be fairly task specific.
[quote=392053:@Jonathan Eisen]Is it not possible to build the app in modules and roll out updates as progress is made?
Sorry if that is a silly question, like I said above, the migration from Filemaker is requiring a big shift in planning and thought processes.[/quote]
Sure, that’s the great thing about using web apps. When you roll out the new modules you kill the old app and restart it and voila the new app is in place.
If you do one app this is a non-issue. If you go with multiple apps you can work with cookies and have a once-a-day/week login for each app they use.
@Robert Keeney The cookie solution won’t work as you wrote it…there needs to be tighter security control on many processes than that allows, unless I am misunderstanding it.
That might be the reason to NOT have a big app. We’ve got a CRM system in Xojo web that’s got around 100 concurrent users that’s got some fairly complex queries in it and it can get slow. We ended up moving from a Windows server to a Linux server because threading in Windows isn’t as good as Mac/Linux. You can get around this by having load balancing and having multiple web applications that can use more cores.
The one question I would ask is: Is the benefit worth the development cost? There are fine solutions out there already, and POS and Payroll applications are incredibly complex. I would try to go with standard solutions (read: maintaining the code is somebody else’s problem) and write a web app that glues them together and provides the additional functionality that they do not provide.
I have a Payroll app that we developed and sell. Still, I usually recommend a third party processor. But if they want to do it in-house, we can do it. I just cringe at the liability they are taking on.
I will never attempt to write a POS system. It’s been done and done well by much larger teams. I will, however, work around the edges and provide functionality that they don’t want to be bothered with.
CRM - depends on your needs vs. what salesforce et. al, can provide.
Business logic: roll up your sleeves. That’s the sweet spot.
@Tim Hare That call has already been made and without going into too many specifics the way our business operates we have yet to identify an off the shelf solution capable of managing our payroll (short of duplicating schedules manually which would be cost prohibitive). We actually have solutions in place for each aspect of the business already, theyre just written in FileMaker weve hit the limit for what FileMaker is really capable of doing.
Were already pretty far down the road of a payroll replacement for our existing FileMaker solution (and like you mentioned we do use an external processor) and its coming along quite well. I would guess that it wouldnt work well for nearly any other business in its current form but its custom tailored for us.
At this point the choice has become move this into one over-arching app that will eventually include a POS system, CRM and whatever else may be needed or have them segregated classified by business function and have users bounce around as needed.