+972 52-548-6969
Desire features in software architecture
In architecture (physical building) there is a term called Desire Lanes. The idea is that users will take the path of least resistance, regardless of the intention of the architect. The image on the right is one that I have seen many times, and I got a chuckle out of that each time. That is certainly something that I have seen over and over again.
I had the chance recently to see how the exact same thing happens in two very different software systems. There was a need and the system didn’t allow it. The users found a way.
In the first instance, we are talking about a high security environment. The kind where you leave your phones and smart watches at the door, outside devices are absolutely prohibited. So far, this makes sense and there is a real need for that for their scenario.
The problem is that they also have a high degree of people who are working on that environment on a very transient basis. You may get people that show up for a day or two mostly (meeting, briefings, training) or for a couple of weeks at most. Those people need to be able to do… stuff with computers (take notes, present, plan, etc).
Given the high security environment, creating a user in the system takes a few days at least (involves security briefing, guidance, etc). Note that all involved have the right security clearances, that isn’t the issue. But before you can get a user account, policy dictates that you need to be briefed, login is done via smart cards + password only, etc. You can’t make that work if you have hundreds of people coming and going all the time.
The solution? There are a bunch of smart cards in a drawer belonging to former employees whose accounts were purposefully not deactivated. You get handed the card + password and can use the account for basic needs.
I assume that those accounts are locked, but I didn’t bother to verify that. It wouldn’t surprise me if they still had all their permissions and privileges.
From an IT security standpoint, I am horrified. That is a Bad Idea, but it is a solution to the issue at hand, providing computer access for short terms visitors without having to go through all the hoops the security policy dictates.
This is sadly a very widespread tactic in that organization, I have seen this in multiple branches in separate locations.
In the second scenario, there is a system to reserve appointments with doctors. The system has an app, where users can register for their appointments themselves. There is also the administration team that may also reserve appointments for patients. The system allows a doctor to define their hours of operations and then (as far as the system is concerned) it is first come & first served basis. The administration team, on the other hand, has to deal with a more complex situation.
For example, a common issue that I run into is that you can only set an appointment if you are registered in the system. What would you do with first time visitors? They are routinely setting things up through the administration team, but while they can reserve an appointment, they have to put someone that is registered in the system.
The solution for that is to use other people, typically the administration team will use their own accounts and set the appointment for themselves, to reserve the spot for the new patient. That can lead to some issues, for example, if the doctor has to cancel, the system will send notices to the scheduled patients. But the scheduled patient and the real patient are distinct. It also means that from a medical file perspective, certain people are “ditching” a lot of appointments.
In both cases, we can see that there is a need to do something that the system doesn’t allow (or actively trying to prevent). The end result is a solution, a sub optimal one, for sure, but something that works.
One of the key aspects for building proper systems for the long term is to listen and implement proper solutions for those sort of issues. In many cases, they are of pivotal importance for the end user, note that this is very much distinct from the customer. The customer is the one who pays, the end user is the one who is using the system. There is often a major disconnect between the two.
This is where you get Desire Features and workaround that become Official, to the point where some of those solutions are literally in the employee handbook.
Comments
I recently worked for a customer who locked their guest environment down tight, especially Internet Access was forbidden. That caused a small issue because we all are working from home and use Teams to collaborate. Except, that did not work from their guest environment. At the same time, the resources we need are also only accessible through the guest environment. That was a real problem and the IT refused to understand, let alone fix the problem. In the end we used a VM to be in the guest network (took some time to configure a VM so the paranoid guest net did not detect that they are VMs). But it shows the same problem as your first scenario - going for maximum security without considering how that affects your users and how the inevitable workarounds compromise your security. Would be an easier way to get guest access into your environment be less secure? yes! Would it be more secure than the current process. Also yes.
When thinking about projects i did (mostly business software), i was rarely competent enough to design the system properly for the customer. Spent hundreds of hours discussing the functionality, logic, user interface and business processes, but in the end the reality was always a bit different. One thing is the ability to absorb and comprehend information given by the customer, but the other thing is that people delegated by customer to provide the information rarely have the right information. They usually just describe what they think the reality is and what is their understanding of how their company works, but real work happens down in the trenches and the actual users of the software are rarely the ones who specify the requirements. So in the end the real users are forced to use some new software and usually there's a period of disappointment, panic, frustration when they complain it's making their work difficult or not possible (especially when the system is just a distraction in the real work they have to do, like production workers who are supposed to produce, not to fumble with some status reporting software). They're usually the creative folk who will try everything to optimize their work and avoid any unnecessary steps and no wonder they will find ways to abuse and misuse the software in ways you never thought of. So in the end, for v2 or v3 of your software you look at what they did and try to incorporate it into your 'proper' design, usually it makes much more sense than the initial idea.
Seems like agile development might be a good idea under such 'special circumstances' ;-) Jokes aside: collect user stories from real users, estimate, prioritize, plan a sprint/iteration with enough work to be done and ship some usable pice of work at the end which is used or played with by real end users. Collect their feedback and iterate again. It's as simple as that.
Regarding 'security procedures' in large cooperations - that's not especially a security process related issue. It seems to be a core property of larger organisations consiting of more people then our stone age human brain can handle. There is the saying each human can only personally connect with 150 different people max including home, family, friends and colleagues (they say this was the maximum size of a village or tribe in ancient times). More then that and we don't feel personal accountability, empathy, ... So in organisations we have to setup hierachical structures to organize cooperation towards major goals. And we need to setup formal rules. And the rules are getting more and more complex, complicated and superfluous. But usually there is a process or a person or a group dedicated to adding rules but not removing outdated rules. That's true for a 50 employee company as it is true for a whole country like the US. Some love to follow as many rules as possible, others just want to do their work, just want to live their lifes. Following is people following a lot of stupid rules or people getting used to bend or work around rules, for them it gets the new normal. Since more then 10 years BYOD (bring your own device) is something normal for creative people working in / for large corps. Sure, the company is providing everything IT wise and computing power wise you need to work - no sorry - you need to access the intranet and Outlook. But rest assured - this setup doesn't allow you to do your actual creative work. IT, processes and rules would never allow that. So people are using the expensive business PC from Dell or HP to use MS Internet Explorer 5.0 and Outlook to communicate in the corp and their own Laptop running WebApps, freely downloadable or even highly privately payed software on MacOS, Linux or Windows for their actual work.
John,
Note that the first part (auth for temporary users) isn't even about technical details, just organization.
The real problem is that agile assumes that you are talking to the end users, but you are usually talking to someone that is several layers removed.
For that matter, there is also the desire in many cases to "make them do it this way" because of policies. This isn't anything about the _software_, this is about the way it is specified.
For the scenario with the security, by the way, just writing notes to yourself on your own device about things that you are going to say about the meeting can land you in hot waters. That is part of the problem. The temp users have no issue with using their own devices, but there are concrete reasons not to.
Comment preview