The first time I listened to the song “sweet in the Middle” by Davido my mind immediately flashed to the diagram above (yes I’m a geek like that). It is a continuing tussle between developers (the various categories inclusive) and security experts to find that “sweet in the middle” spot. Application and systems development often involves uncomfortable compromise by these experts.

Functionality deals with the various tasks that a system needs to perform. A website that shows users videos posted by other persons would most definitely possess a video player. The video player might have an offline functionality to allow videos play without connection to the internet. It is possible to display the number of times someone clicks the play button. The person who posted can know the suspected area from which the video is being watched and much more. All these are the functionality of the video curating website. It is highly unlikely that we would find a lot of these features in a banking website. Such banking website would present its own set of functionalities. A budget planner or expense tracker might be appropriate on a banking website, but that would be inventive and odd if found on a video curating website.

Ease of use/Usability relates with the functionality in systems. How easy or intuitive is it to use features a system has to offer. If I arrive at the video curating website explained above can I immediately figure out how to play videos. As an intending uploader, how easy is it for me to upload my videos. If I save videos offline, do I have to do 10 distinct things to see the saved video making the process cumbersome. If they display the number of times we have played the videos, How accurate is it?.  The ease of use questions the likelihood of users being happy with the processes involved in using functionalities provided by the system.

Security often frustrates the effort of technocrats in the other two groups. Security looks at the functionalities and cuts some off just because implementing them would be too much of a risk to the security structure of the system. In the video curating website example, the ability to find out where the video is being watched can pose a security risk to those that see the videos. The Poster can use that information in ways that would tarnish the image of the website. The security team could even take some videos posted down for violating laws of the land or restrict such videos to places where viewing such is legal. All such issues would stifle the functionality unit. The ease of use unit could also find that authentication processes put up by the security unit make usability ratings reduce drastically. All these among others make the security review in the system development cycle a dreaded process. A secure system is however much more needed and good for systems than a non-secure one, so they usually appreciate the activities of the security team.

A brief description of what goes on in the unique points of the system development triangle shows the moot issues for specialists in each sector. The higher the number of functionalities allowed, the higher the likelihood that usability and security have allowed some compromise. If the developers decide on the most simple usability available, the security guys won’t be pleased and the functionality technocrats would prefer you left them out of the project entirely. Requiring so much information at registration to populate their logs and ensure no one can repudiate their actions has already irked the ease of use team, never mind retiring some functions because the risk exposure is too high. The battle is continuous and whenever they find that middle point; it is always so sweet.