INF20001 Electronic Communications and Applications

101

Requirement

Your tasks
Read the case carefully and if students need more detail either about the business or the assessment, they should talk to the online tutors, preferably before starting the task.
1. Draw a diagram representing the logical networkdesign for the proposed DRUB network.Document any assumptions you make regarding the network requirements/usage etc.
2. Describe any one technology or standard that you think would be particularly relevant at each of the three layers and explain why you believe it may be relevant to the DRUB network needs (Back up your discussion of each technology or standard by using reputable references other than the text and the learning material). This discussion should be consistent with your assumptions and design from Task 1.
3. Develop a plan for the proposed network that lists three key assets relevant to the scenario, identifies at least three risks and nominates at least three controls. (You need to make sure that each asset has at least one applicable threat and each combination of asset and threat has at least one reasonable control).
4. Describe the measures you will have in place to assure customers and staff of a 99% availability of the network and its systems. (This will include redundancy recommendation for all aspects of the proposed system).
5. Additionally DRUB wants to develop a mobile application to better reach their customers and improve their competitiveness against their rivals. Your task is to discuss, recommend and illustrate the following:
a. Should DRUB develop a native or mobile web based mobile presence. Briefly discuss the difference and recommend one of those options.
b. Produce a mobile app prototype (paper based illustrations only) and show three (3) of the main screens, also include a recommended design for the mobile app icon. Support your designs by aligning them to the design principles and techniques discussed in the unit resources.
c. Recommend a brief marketing plan that will take into consideration their website, mobile app and social networking. Include in your recommendation how analytics could be used to improve their engagement with their customers.

Solution

ENABLING GROWTH FOR DEALS-R-US BROKERS (DRUB) AND  PROPOSAL FOR MY STOCK ANALYSIS TOOL (MSAT)    

In this paper, we consider a small growing brokerage firm. We focus on a new software tool to analyze stocks. The tool will be based on a three-tier client-server architecture and will be made available as a website. We explore the technicalities, vulnerabilities, controls, design, marketing plans for the software. We also recommend going with a web-based mobile presence first and provide our rationale for such a recommendation.

Enabling Growth for Deals-R-US Brokers (DRUB) and Proposal for My Stock Analysis Tool (MSAT)

Deals-R-US Brokers (DRUB) is a small brokerage firm based in Australia, that helps clients sell and buy stocks on the Internet. DRUB has been growing and is also nearing the completion of the acquisition of another firm. All in all, we are seeing an addition of further 20 employees with a requirement to grow office space. To this end, the current office in Melbourne will be expanded to three rooms on two levels and a new office in Sydney is being arranged which will initially house 10 employees.
Also, to focus on the core service of the company, a current project on the rollout of a wireless network has been suspended and instead resources are being diverted to a stock analysis tool, to be used by both customers and staff. This tool is called the My Stock Analysis Tool (MSAT).
The purpose of this paper is to report on the current scenario, propose solutions for the implementation of the DRUB network and MSAT, which may be used as a basis for discussion with Information Systems or other domain experts. This paper has been commissioned by Fred Chang, the president of DRUB.

DRUB Network Proposal

Three-Tier Client-Server Architecture
The DRUB network will be a three-tier client-server architecture by which we mean that there will be a separation of responsibilities i.e. various tasks required in running an application will be clearly distributed among computers maintained at different physical locations and they will communicate with one another using a common network e.g. Internet. Now, the task of the first tier is to accept user input and forward to the second tier as well as accept results from the second tier and present them to the user in his desired way. Thus, this tier is also called the presentation tier. The task of the second tier is to act as an intermediary between the first tier and the third tier. The second tier accepts inputs from the first tier, forwards it to the third tier and then accepts results from the third tier (discussed next) and then forwards the results to the first tier. This tier is also called middleware (Shelly and Rosenblatt, 2010) or application server (CCM, 2016). The task of the third tier is to receive user requests via the second tier, perform business logic and interact with the data and return the results to the second tier. This tier is called the data tier (Tarhini, 2011).
As per Khosrow-Pour (2000), there are many advantages to such an architecture and only one disadvantage which too is becoming less of an issue with the development of new techniques. This division brings with itself lower network traffic between client and server (as most interactions happen at the servers and only the result is forwarded to the client) resulting in higher performance overall. Also, we see lower initial costs and lower maintenance costs on the client-side as the hardware and software requirements are relaxed. After all, if only a browser is required to access an application (which has its complexity hidden in the servers), then even a lower configuration and thus cheaper computer can meet the requirements. Such a client is usually referred to as a "thin client" (Ansari, Tiwari and Agrawal, 2008). However, we do see a more difficult development process for three-tiered client-server architecture applications but these concerns are now being managed by component-based designs. Khosrow-Pour (2000) explains component-based designs as developing a big application into smaller steps, reusing components and incorporating off-the-shelf software to build better and more secure software. Next, we discuss the logical network design.

Logical Network Design

A logical network design ignores the physical aspects like the actual cabling, physical locations of the computers, etc and focuses on providing an abstracted view of the system from the point of view of data and logic. Complementary to it is the physical design which only focuses on the physical characteristics of the design. We agree with Partsenidis (2004) and appreciate that both these designs are important to maintain a system and are a confidential asset of the company to be restricted only to administrators and engineers who are responsible for the network.

Assumptions

We have assumed a growing demand and thus will reserve a base machine for tiers 2 and 3, and allow for automatic upgrading of resources (like processor, memory and storage) as and when demand peaks. Such a requirement dictates choosing a cloud service provider as opposed to having a piece of on-premises equipment (Kim, 2009). In addition, we anticipate attacks from competitors, financial criminals, and hackers and thus will develop the application with security as a fundamental requirement and will choose a provider that supports the latest security technologies. Also, we assume our users to be using lower-powered machines and mobile phones and thus will have a lightweight tier, so that the customers (and our staff) can access the application without any delay or disruption. 

Relevant Technologies

We have a three-tier client-server architecture and at every tier, some technologies have a pivotal role to play for the software and thus our business. In this section, we will discuss the most important technologies for each tier.
Tier 1
This is the client tier and we have assumed for the benefit of as large a customer base possible that our customers have lower-configuration computers and mobile devices. Thus, it is imperative that our tier 1 be as lightweight as possible. To ensure this we need to demand the minimum possible resources (network bandwidth, processing, memory) from the customer's device. For this, we require Web Standards technologies as websites built using these are shown faster, download quicker, have lower development and maintenance costs (Sikos, 2014). 
Truly, all of our concerns regarding web development at the client-end (customer's device using a web browser like Mozilla Firefox, Google Chrome, Microsoft Internet Explorer, Safari, etc) can be remedied using Web Standards. The technologies included in Web Standards are HTML (HyperText Markup Language), CSS (Cascading Style Sheets) and JavaScript. Thatcher (2006) explains that HTML is used for content and structure, appearance is handled by CSS and behavior is controlled by JavaScript. 
Tier 2
This tier will be acting as middleware, organizing the flow between tier 1 and tier 3. This is the tier that will be loading the website into the user's browser. As mentioned earlier, we assume growing traffic with spikes in incoming traffic. In addition, we anticipate and want to be prepared for attacks and hacking from our competitors, criminals, hackers, etc. Also, we want the site to be loaded on the user's browser as soon as possible eliminating all delays. For this, we will be taking advantage of Content Distribution Networks (CDN) also. A CDN replicates the content of a website to multiple servers all over the Earth in various geographical regions and then serves the user from a server that is physically closest to him (Peng, 2008). This helps reduce the latency as much as possible. Latency is the time delay to physically move the digital information from one geographical place to another. In addition, we require a secure, scalable cloud service provider with the capability to automatically increase the resources as per the demand.
Tier 3
This tier houses the database. We mention here that data is the most important thing in any software and for any business. It has been likened to the "new oil" (Palmer, 2006), to indicate its importance in the current marketplace. For data, we anticipate lots of activity reading, writing, updating and deleting data from many users simultaneously. Thus, we require a scalable database system that supports transactions. By transactions in the database we mean that if more than one change has to be done in the database to record an operation, then either all of them will be done or even if one of them fails, then none of them will be done to the database. Transactions also ensure that until a transaction is complete, the interim changes are not visible. Next, we need a reliable server for our database. We recommend a cloud service provider with facilities like support for the latest security technologies, active backups, etc. Inactive backups facility, a replica of the database copy in use in maintained and updated after every operation. In the event of failure of the main database due to any reason, the backup copy is made the active copy instantly, thus improving the resilience of the system. 

Threats and Risk Control

Any worthwhile thing is always at risk for being exploited, stolen or taken advantage of. Such is the case with our software which will be handling real money and stocks for clients. As mentioned before, we expect and will be prepared for attacks from competitors, financial criminals, and hackers. Now, we discuss some threats to our assets and controls to handle them.
Cross-Site Scripting (XSS) is a threat that becomes possible when a website shows any content without sanitizing it first. By sanitizing we mean removing any reserved characters or those patterns which may execute a command. As per Spett (2005), an attacker who is successful in an XSS attack can compromise confidential information and present himself as the genuine user to the website and execute malicious code on the user's device using a web browser. To control this threat, the website development team will sanitize before showing any content created by the user.
SQL Injection is a grave threat to websites that use the database, like our website. Since we have to allow users to input data to our databases, this opens up a vulnerability in that malicious users may send database commands in their input which may inadvertently get executed on our database server. Such a serious weakness can allow an attacker to reveal our database, change data or delete it all. Surprisingly, it is very easy to eliminate this threat. Our development team needs to be alert and use modern programming techniques like parameterized queries that compartmentalize user input and thus anything they send can never be executed.
Denial-of-Service (DOS) is an attack that aims to bring down a site by making incessant requests on the webserver, which are not genuine user requests and have been generated only to cripple the working of the server and thus deny the server capability to serve genuine user requests. To handle this threat, we will use the services of providers who have network bandwidth capable of handling terabytes of requests (which will give us time to handle the DOS attack without compromising serving the genuine users' requests). Controls for handling this include logging requests meeting some threshold, automatic alerts to webmasters (email, text, etc) when such activity is noticed by server software, rate-limiting or banning access by IP address, geographical location, etc,

Assuring 99% Availability

A website is composed of many components each having its own vulnerabilities and points of failure. For our three-tier client-server architecture, we will discuss each tier and provide recommendations to help ensure a greater than 99% uptime.
Tier 1
This is our presentation layer and is focused on loading our website on the user's browser. The data for this tier comes from tier 2, which means our point of failures include the network between tier 1 and tier 2, and tier 2 itself. Now, we will be using a reliable and time-tested service provider for our website with a guaranteed Service Level Agreement of 99% or more. That ensures a basic level of availability. Next, as a second line of defense, we will use a Content Delivery Network (CDN). As explained above in the paper, the CDN will maintain replicas of our website on servers spread all over the Earth and a user requesting our website will receive the website from a server physically closest to it (Peng, 2008). This helps improve user experience but does not address the concern of availability. CDNs also provide an additional feature of monitoring our website round-the-clock and if the website goes down, then it serves the latest copy it has in its records, in addition to alerting the website maintainers via email. Thus, our customers will always have something served to them and will very rarely be shown an error that the website could not be loaded (Adams, 2012). In addition, HTTP (HyperText Transfer Protocol) headers can be used to request the user's browser to cache our content. By caching we mean that a local copy of some static assets (like CSS (Cascading Style Sheet) file for styling, JS (JavaScript) file for behavior, images) will be saved once downloaded and will not be requested from Tier 2 server again.
Tier 2
Tier 2 is the application tier which will be housing the application's server-side code. Server-side code is the programming that runs for each request and generates a different content as per the request and authorization (Bidgoli, 2004). Now, to ensure availability, we will rely on the Service Level Agreement (SLA) of our service provider. Care will be taken while choosing a service provider that has footprint all over the world, has been time-tested and has lots of resources at its disposal. Also, we will be choosing a plan that allows for autoscaling. By autoscaling, we mean that if demand peaks suddenly and unexpectedly, then resources (processor, memory, storage, etc) will be allocated automatically. This will be helpful in mitigating during some forms of attacks also (e.g. during a DoS (Denial of Service) attack, endless requests are made on the website server in an attempt to bring the website down) autoscaling will help keep the website live. 
Tier 3
This is the data tier where the data is stored and updated. This is the heart of our software. Just like tier 2, we will depend upon the SLA of our service provider to guarantee us availability. In addition, we will utilize the autoscaling facility to have resources provisioned for us at any time our base plan resources be insufficient to meet the demands. In addition, we will optimize our data store by splitting the read and write operations among separate databases (which will automatically be synced by the service provider)

Mobile Applications

What Kind of Mobile Presence?
There are two primary operating systems in the market currently about whom we should be concerned as a business - Apple's iOS and Google's Android (Holzer and Ondrus, 2011). Now, we may choose to build native apps (separate app for each operating system) or have a mobile website. To help arrive at an informed decision, we will explain both and present the advantages and disadvantages along with a comparison of their development costs.  
A native app is built using the programming language of the mobile operating system (Charland and Leroux, 2011) and as such requires separate development for separate operating systems and thus costs more. However, native apps provide a better user experience and allow for utilizing features of the device which a website cannot. A mobile website is simply a website that is optimized to be viewable on a small screen and is designed to work without certain functions that are not available on a mobile device (e.g. mouse hover is only available on desktop computers and laptops). It is cheaper to develop in that an existing website can be made "responsive" and thus not require any extensive additional effort. As per Marcotte (2010), responsive web design uses techniques like media queries to automatically adjust the web design (e.g. same button shows small on a large screen and shows big, say for easier tapping, on a small screen).
Considering the current scenario, we recommend a web-based mobile experience in which the current website is made responsive. We advise this so as to avoid the costs and time required to develop (and publish in the app stores) two separate apps. Also, later when the company sees even more success, then apps can be developed in addition to the mobile website being maintained and made available to mobile users who do not have the app installed.

Mobile App and App Icon Prototype

Now, we present a prototype of the app's three screens and an app icon. We mention that in case a decision is made to go with a mobile website based presence, then the mobile website can mimic this look and the app icon can be used a favicon for the website. A favicon is shown along with the title of the page and in the favorites when the website is saved in the web browser.

Also, we propose an app icon as follows:

Our rationale for such an app icon is to have a green colour background which evokes positive feelings of affirmation, growth, stability and matches with general colour of Dollar (A Monsef IV, 2007). On top of it we have an image depicting the tussle between Bull and Bear of stock market along with an upward rising line graph. It is our hope that the proposed app icon aligns with the requirements of DRUB.

Marketing Plan

We propose a general outline for marketing our application. We are already live in the market and have customers. We will advertise the application and provide discounts to our existing customers. Once logged in, each customer can generate a referral link using which they can invite new users to try the system. Successfully referred leads can be used to compensate promoters of our application. Besides this, we will open up application's pages on Facebook, Twitter and will maintain these pages with regular updates in the form of photos, announcements. Also, we highly recommend engaging with the users on these platform and interacting with them to satisfy their concerns and queries about our software. Next, we will spend on online advertising using Google AdWords, Facebook Ads and Twitter Ads to target the ads to the relevant demographics. Finally, we recommend combining the statistics from all these to get an idea as to which fronts are bringing in business and which require remedial efforts.

Conclusion

In this report, we analyzed a stock analysis software -  My Stock Analysis Tool (MSAT) for Deals-R-US Brokers (DRUB). We propose our solutions to enable the growth of the company in addition to analysing the MSAT software from a technical point of view. We took care in this report to explain technical terminology in simple terms and invite the interested  reader to explore more resources available in the references. In addition, we analysed the software's threats, design and marketing plan. 

Reference List 

• A Monsef IV, D. (2007). Color + Design Blog / The New Colors of U.S. Money by COLOURlovers :: COLOURlovers. [online] Colourlovers.com. Available at: http://www.colourlovers.com/blog/2007/09/21/the-new-colors-of-us-money [Accessed 8 Nov. 2016].

• Adams, C. (2012). Does a CDN still work even when my server is down?. [online] Serverfault.com. Available at: http://serverfault.com/a/452017 [Accessed 7 Nov. 2016].

• Ansari, N., Tiwari, S. and Agrawal, N. (2008). Practical handbook of thin-client implementation. New Delhi: New Age International (P) Ltd. Publishers, p.4.

• Bidgoli, H. (2004). The Internet encyclopedia. Hoboken, N.J.: Wiley, p.770.

• Charland, A. and Leroux, B. (2011). Mobile application development. Communications of the ACM, [online] 54(5). Available at: http://www.yildiz.edu.tr/~aktas/courses/CE-0112822/20-05-3-2.pdf [Accessed 7 Nov. 2016].

• Holzer, A. and Ondrus, J. (2011). Mobile application market: A developer’s perspective. [online] Available at: https://www.researchgate.net/profile/Jan_Ondrus/publication/229316928_Mobile_application_market_A_developers_perspective/links/00463533db92b61041000000.pdf [Accessed 7 Nov. 2016].

• Khosrow-Pour, M. (2000). Challenges of information technology management in the 21st century. Hershey, PA: Idea Group Pub., p.22.

• Kim, W. (2009). Cloud Computing: Today and Tomorrow. The Journal of Object Technology, [online] 8(1), p.2. Available at: http://www.jot.fm/issues/issue_2009_01/column4.pdf [Accessed 6 Nov. 2016].

• Marcotte, E. (2010). Responsive Web Design. [online] Alistapart.com. Available at: http://alistapart.com/article/responsive-web-design [Accessed 7 Nov. 2016].

• CCM. (2016). Networking - 3-Tier Client/Server Architecture. [online] Available at: http://ccm.net/contents/151-networking-3-tier-client-server-architecture [Accessed 6 Nov. 2016].

• Palmer, M. (2006). Data is the New Oil. [online] ANA Marketing Maestros. Available at: http://ana.blogs.com/maestros/2006/11/data_is_the_new.html [Accessed 6 Nov. 2016].

• Partsenidis, C. (2004). Why is it useful to use both a physical and a logical network design?. [online] SearchNetworking. Available at: http://searchnetworking.techtarget.com/answer/Why-is-it-useful-to-use-both-a-physical-and-a-logical-network-design [Accessed 6 Nov. 2016].

• Peng, G. (2008). CDN: Content Distribution Network. 1st ed. [ebook] Stony Brook University. Available at: https://arxiv.org/pdf/cs/0411069.pdf [Accessed 6 Nov. 2016].

• Shelly, G. and Rosenblatt, H. (2010). Systems analysis and design. Boston, Mass.: Thomson Course Technology, p.459.

• Sikos, L. (2014). Web standards. 2nd ed. Apress, p.5.

• Spett, K. (2005). Cross-Site Scripting. 1st ed. [ebook] SPI Dynamics. Available at: http://people.cs.ksu.edu/~hankley/d764/Topics/SPIcross-sitescripting.pdf [Accessed 8 Nov. 2016].

• Tarhini, A. (2011). Concepts of Three-Tier Architecture. [online] Ali Tarhini. Available at: https://alitarhini.wordpress.com/2011/01/22/concepts-of-three-tier-architecture/ [Accessed 6 Nov. 2016].

• Thatcher, J. (2006). Web accessibility. FriendsofED, p.8.