Question

In an application I’m currently working on, and acting as primary architect, we have two pretty much distinct types of users (say Employees and Managers), with 99.9% non-overlapping needs. At the present time, in building up our application in a new platform, I’m suddenly faced with a crisis: Do I use one UI layer/application, or two? I keep thinking about the Single Responsibility Principle applied at a macro-level.

My application is broken down pretty well along the basis of a layered architecture, in that I can pretty much put a new UI on things quite easily, as all business concerns are properly contained in a separate domain layer, and not in the UI.

That said, once a user is past the login stage, there is very little overlap in the functions that they perform. Both types of users are acting on the same data–just in different ways. As an example, an employee may “submit” something, and a manager then “approves” or “rejects” it. (a contrived but apt example).

The way I see it, my choices are reasoned like this:

1. One massive UI, containing all UI functions for both types of users, and available functions to a given user are maintained by the existing roles/permission structure.
   PROs: In this case, it’s easy for UI helper functions, scripts, CSS, etc. to be commonly maintained. CONs: It’s more difficult from an organizational structure, deployment of “employee” functions necessitate “manager” downtime, etc.

2. Two UIs, essentially an EmployeeUI and a ManagerUI, along with a new library that contains common helper functions, static script/CSS, etc. PROs: Separate functionality means that concerns for one type of user can be deployed without affecting the other. There is less concern about overall security (that is, a smaller number of roles/permissions per UI), and maintenance of specific features is easier. CONs: Now I have two applications plus a library to maintain. And I do have a handful of users that have logins to both systems. (This is the existing approach in our legacy apps). I also have to ensure that both systems are on a reasonably similar deployment schedule, as the business logic does change over time.

Last week, one day I was 100% convinced they should be separated. The next, I had enough doubt to hesitate.

What thoughts do you have on that? Can you provide some examples?

Answer 1

Answering my own question here, not out of ego, but just to provide an explanation of the route I wound up taking:

I chose option 1. Less code to maintain. The users’ functions are segregated nicely by permissions/roles, and a nice little benefit that came out of it was that in the long run, the multiple logins will go away for the very small percentage of users that work in both systems.

Yes, I’ll take the downtime in both systems when it comes time for updates, but a scheduled maintenance window generally takes care of that, and regardless of which approach I chose, I’d have still had to schedule it.

I’m also safer in knowing that my UIs won’t be acting on different business logic (versions), as there will simply be one, not two.