Consultant Analysis Report

Student Name
Institutional Affiliation

Table of Contents
Consultant Analysis Report Student Name Institutional Affiliation 1
Consultant Analysis Report 3
Project Overview 3
Organization Overview 3
Current Systems 4
System Requirements 7
System Functions 7
Method of Delivery 7
Target Users 8
Architecture Selection 9
Why the Cloud? 9
Security 12
Multitenancy 12
Programming Language 12
Database 13
Scaling and Redundancy 13
Resources and Timelines 14
Hardware. 15
Software. 15
Personnel. 15
Timelines 16
References 17

Consultant Analysis Report
Project Overview
Organization Overview
Sales Engine Inc. is a software development firm that deals exclusively with the creation of business systems that streamline the operations for companies around the country. Sales Engine, their primary product, is a desktop-based suite that is used for marketing, sales automation, customer service, and business automation. Recently, however, the company made the decision to host their software on the cloud as a service. It was the opinion of the company that the customers would benefit from the lower cost of entry, reduced time to benefit and rapid prototyping, the pay as you go model, and the ability to work anywhere (Turner, Budgen, & Brereton, 2003). Moreover, since the company will be in charge of and responsible for upgrades, uptime, and security, Sales Engine hopes to see higher adoption rates.
Sales Engine Inc. is headquartered in Seattle, Washington. There are currently 64 employees working at the Sales Engine offices in Seattle. Members of staff are evenly divided between those involved on the business side and those that are in charge of the IT infrastructure for the company. The organization is housed in four floors in the same high-rise building within the Seattle Central Business District. Much of the company’s success can be attributed to their revolutionary CRM and business process management software, Sales Engine. Along with sales from the sale of software, the company also profits from business consultancy, third-party integration, and other professional services. However, it is worth noting that with the proposed changes, there is a pressing need to reevaluate the existing architecture with a view to establishing how well suited the system is to handle the new requirements (Frey & Hall, 2007). Preliminary reports suggest that the current systems that Sales Engine Inc. uses as a backbone for their services are not flexible and ill-suited to providing the infrastructure for serving their product as a cloud-based service.
Current Systems
Sales Engine Inc. presently provides marketing, sales automation, customer service, and business automation. The company owns a total of 9 servers which serves as the supporting framework for their existing architecture. Since their operations are primarily limited to hosting the software packages for download, a support and ticketing system, and a user board where software owners can share experiences and tips, there has not been a need for more servers, at least until now. In the present arrangement, the servers are distributed between those that handle downloads, web servers, intranet servers, and an email and print server. One challenge that the company has faced so far is that some users are using their software suite without actually paying for it. With the impending migration onto the cloud, it is hoped that software licensing on a subscription basis would alleviate licensing concerns.
Sales Engine has been in charge of maintaining the servers as well as ensuring that there are minimal cases of downtime on the servers. Moreover, Sales Engine was in charge of ensuring that the customers could access dedicated support at any time of day as well as other support services from their site. For their part, customers will be expected to update the software, apply patches and fixes to the software once they have been made available. More than that, they will be expected to seek support for any issues that crop up, provide their own infrastructure on which the software will run, and carry out an analysis to ensure that they have the minimum system requirements to run the application software.
The current system presents a heightened risk of server downtime, has no room for flexibility or growth, no fail-over systems, limited ways to address redundancies, and no load balancing implemented. Concerning the architecture, the key considerations are if the infrastructure in place can be used in the cloud, or an overhaul will be necessary. If changes are needed, emphasis will be on how they can be realigned to fit a cloud-centric architecture. Further, given the fact that Sales Engine clients are disturbed all over the globe, there is a need to ensure that the application is available on a global scale and any user documents and files are available irrespective of their geographic location (Greer, 2009). Some of the primary considerations include architecture changes, application level security, and how any shortcomings will be met (Erl, Puttini, & Mahmood, 2013). Security will be geared towards ensuring that that client data will be secure from any breaches (Turner, Budgen, & Brereton, 2003). Finally, the financial considerations will also be a factor in to ensure the costs remain within budget.
The consultant’s report was requested by Sales Engine as a way to evaluate the changes necessary to meet the changing company requirements. More than that, the aim of the report was to analyze how well suited the current architecture is to these demands. Five main areas will be examined at length in this report. First, the system requirements will be reviewed, followed by considerations about the system architecture. Specific concerns in this segment will investigate how to make the system efficient and effective will presenting minimum disruption to existing services (Turner, Budgen, & Brereton, 2003). Third, the report will concentrate the resources required along with a possible timeline for delivery. Finally, the report will focus on any analysis and recommendations that remain.

System Requirements
Specific requirements need to be defined for the system to operate as intended. A specification of the requirements will aid in System Design. Three sections are listed to describe the system requirements; system functions, a method of delivery, and target users. The proposed changes to the system are listed first and clarify what the system will require before becoming operational.
System Functions
Sales Engine, a software design firm dealing primarily with customer relations management and business automation, has opted to provide its leading software offering through the internet. The software will be delivered as a service (SaaS) to prospective clients around the globe. Clients will be able to access their accounts and provide their services to their customers through a web interface from anywhere in the world, provided they have an internet connection (Frey & Hall, 2007). For this reason, it is necessary for the system to be available across geographic locations. Moreover, since different clients will be accessing the same platform, security will present one of the main challenges of implementing the architecture (Greer, 2009). Even more important, the application architecture should allow for the system to scale to fit user requirements.
Method of Delivery
The application will be hosted on a centrally located server, with the users being able to access the website through the internet. Clients will access the system through a thin client made available through a web browser. Users will log in to their account, from where they will be afforded the chance to manage the services that they have subscribed to, add or subscribe to value added services, or even opt out of the subscription. Since the clients will be sharing a platform, the primary challenge in this instance will be how to separate concerns and provide some insulation so that one client’s data is safe and secure from another (Frey & Hall, 2007). At the same, any updates to the platform will be handled by Sales Engine team.
Target Users
The users that will be accessing the software application as a service are already familiar with the system. Since there will be minimal changes in the system, and clients will be accessing the website through a thinly veiled client, there would be little cause to worry about the need for training. Still, any subsequent changes to the user interface (UI) will be carried out incrementally, and interactive tutorials will be made available (Greer, 2009). Since the software system will afford clients the opportunity to manage and track their customers, with some allowance for the said customers to interact with the software service, training and tutorials will have to be made for them as well.

Architecture Selection
Why the Cloud?
Up until around ten years ago, a typical enterprise computing infrastructure consisted of powerful and very expensive servers. Infrastructure architecture was colossal, and each of these powerful servers could easily host up to thirty business applications. Major hardware vendors HP, Sun, and IBM dominated the market by providing servers that were expensive to purchase and maintain, and even harder to upgrade once configured (Greer, 2009). At the same time, they were primarily vulnerable to server outages that could last hours at a time, that is until the vendors, or their representatives delivered proprietary replacements. Since the operating systems were installed directly on hardware, and most servers hosted multiple applications within the same operating system, but without providing physical or virtual isolation, it was exceptionally difficult to move or rebalance requests across servers quickly (Erl, Puttini, & Mahmood, 2013). Thus, server resources were not utilized efficiently.
To solve the problem, distributed applications were introduced. Installed on multiple servers, these applications communicated with each other using DCOM or CORBA communication protocols over RPC (Greer, 2009). Still, these protocols had problems since that they were vendor-dependent, and one vendor’s implementation could turn out to be incompatible with that of others. To solve these, web services were introduced circa the beginning of the 2000s by the introduction of web services. Such services utilized open specifications that are language, platform, and vendor independent. And with the introduction of virtualization, things changed even more significantly since the new technology could improve resource utilization and energy efficiency, a result of which was a substantial reduction in server maintenance overheads and fast disaster recovery in cases of failure as well as high availability.
Virtualization is proved to be a significant advancement on the path towards cloud computing, largely for its ability to isolate software from hardware along with the provision of such mechanisms that would allow for a quick reallocation of applications across servers based on computational needs. However, this model lacked a service component, the major upgrade that was made available in cloud computing. To enable environments for the cloud, a layer of abstraction and on-demand provisioning is provided to hide the complexity of the infrastructure (Erl, Puttini, & Mahmood, 2013). Access to the cloud-based services is then provided via a cloud management interface that is running on REST or SOAP web services, a programming APIs, or other services. Cloud-based infrastructure thus has an advantage in that it can be designed with the ability to scale subject to a few calls to the programmable API or web service queries. Such elasticity ensures that systems are efficiently utilized most of the time.
Another key design consideration in cloud environments is the creation of a multi-tenant, infrastructure so that computing resources can be shared across multiple applications. Such an infrastructure paradigm is predicated on the assumption that all hosted applications cannot be busy or in use at the same time (Erl, Puttini, & Mahmood, 2013). When one application or instance is active, the others are free. Thus, a cloud provider can scale the instances required on-demand. Sales Engine needs to upgrade their servers to ensure more capacity for the new users. To scale to meet the new demands, the company has several choices. First, they could purchase two powerful server instances at around $50,000 with the capacity of up to 50,000 users and utilize these until they reach capacity, at which time they would add another two servers with similar size (vertical scaling). Alternatively, they could purchase less powerful server instances with smaller capacity and at lower prices and buy more servers as their user base increases (horizontal scaling). Or as a final consideration, they could outsource their requirements to a cloud vendor that automatically scales according to their needs. The latter approach is certainly more economical since it implies less wastage of resources as compared to the previous two, based on unrequited user capacity.
For any cloud-based service, there are a number of service models available that a client can take advantage of. The most fundamental of these is Infrastructure as a Service (IaaS) model. IaaS provides physical infrastructure components to customers, and these may include storage, networks, virtual machines, firewalls, and load balancers (Erl, Puttini, & Mahmood, 2013). IaaS forms the lowest level on which other models are built (Greer, 2009). The Platform as a Service (PaaS) model delivers a pre-built application platform to the client, minimizing the time required to build the essential infrastructure for their applications. Typically, PaaS solutions make use of a programmatic API to make a set of function calls that get the servers up and running. The final cloud service model and the one that Sales Engine is most likely to use is Software as a Service (SaaS) which provides immediate online software solutions to clients.
Sales Engine could have complete control over their application software and run it through an API or Web Service, but without being bothered by the underlying architecture. If however, they desire more customization, they can settle for either PaaS or even IaaS and customize it according to their requirements (Turner, Budgen, & Brereton, 2003). Since Sales Engine was already sold on the idea of hosting their software on the cloud and serving it as a service, most of the decisions regarding how to implement the cloud-based SaaS architecture were constrained within the decision. The primary considerations involved covered security, the programming language used, the database, and how to scale the application.
Security
Hosting applications and data on the cloud require the clients give up some level of control over their data and relinquish it to the SaaS provider. For this to be a seamless process, the clients need to trust the vendor to handle their data securely and keep it safe. Thus, security is usually the centerpiece of any cloud-centric design (Frey & Hall, 2007). Thus, the highest priorities for prospective SaaS architecture should be creating a system that is robust and secure to satisfy clients data security needs, efficient and cost-effective to administer and maintain, and highly manageable. For these considerations to be accounted for, Sales Engine Inc. needs to implement a multi-tenancy metadata driven architecture as a central design approach.
Multitenancy
Multitenancy has several advantages over other prospective models, with the most important of these being the fact that it will benefit both application providers and users. Since only one operational instance of the application will be used at any time across different enterprises, significant cost savings can be realized (Erl, Puttini, & Mahmood, 2013). At the same time, enterprises have the ability to customize their applications through the use of metadata. More than that, since there is only one instance running on a single platform, there is much less development and maintenance costs (Greer, 2009). Even more importantly, administrative work is significantly reduced, and the number of personnel required to oversee the system is much lower.
Programming Language
Products built on top of the cloud need a modern programming language. One of the primary considerations in the choice of a programming language includes personal abilities and skills of the staff with the company (Frey & Hall, 2007). The selection of your programming language will be influenced by the possibilities of each language. Since Sales Engine is built primarily in Java with Scala used as the glue for high-level integrations, Scala was settled upon as the preferred way to implement the web-based access layer. Scala has some advantages that made it well suited for the task at hand including interoperability with Java, a functional aspect that makes the language a seamless way for creating domain specific languages (DSLs), and
Database
Given the domain specific requirements of Sales Engine, along with the need to support multi-tenancy, the recommend database for the enterprise system was a document-oriented database. Document databases are quite different from traditional databases in several key areas. For one, since they acquire type information from the data itself, every instance of the data can be different from the others, allowing for flexibility when dealing with changes. As a result, it is easier to manage multiple instances. Sales Engine can benefit from this adaptability, and for this reason, MongoDB was settled on as the main database. MongoDB gives high levels of performance, availability, and scalability out of the box (Erl, Puttini, & Mahmood, 2013). The advantages translate to performant databases that scale to accommodate a global audience. Even more important, MongoDB also allows for sharding, or storing data across different machines, a fact that would translate to better support for the deployment of large data sets and increased redundancy.
Scaling and Redundancy
One of the primary considerations for a cloud-based solution is how to assure availability and reduce downtime. For Sales Engine, such concerns are even more important since their clients need their services to engage with their customers in turn, and whenever the servers are down, cost implications will be dire. For this reason, the architecture had to factor in several ways through which operations would be normalized so that they work seamlessly (Erl, Puttini, & Mahmood, 2013). Since Sales Engine handles a large volume of communication between them and their clients, as well as between your customers and their customers, it was necessary to create a queueing mechanism to ensure asynchronous communication is possible. The Sales Engine system will apply a Message Queuing (MSMQ) technology will be employed to enable different instances of the web applications to run at the same time, communication with other third party integrations and APIs.
For this enterprise application, RabbitMQ, an open source queuing system will be used. Owing to the prohibitive costs of setting up and maintaining server instances, Amazon Web Services (AWS) will be used to run the web applications as well as provide the infrastructure for the large high-performance batch jobs (Murty, 2008). Elastic Compute Cloud (EC2), a part of AWS, will be used to provide scalable virtual servers the different businesses (Murty, 2008). At the same time, another web storage service, Web Storage S3, will be applied for highly scalable object storage. More importantly, the Amazon EC2 platform comes with a Content Delivery Network (CDN), a system of distributed servers that makes it possible to serve content to users with high performance and high availability.
Resources and Timelines
Resources Required
Managing the resources of a project is critical to any enterprise. A solid understanding of the system, ongoing costs, as well as the total cost of ownership should be identified. At the same time, financial costs for software, hardware, network, and personnel expenses have to be identified.
Hardware.
Much of the existing hardware can be repurposed for the new requirements. If anything, the number of machines being used internally can be reduced (Frey & Hall, 2007). The only requirement is that the hardware systems are reconfigured and repurposed according to requirements. Still, there will be some possible costs involved in the design of the system. Much of the expenses associated with the design will arise from the design of the enterprise application, along with any expenditures incurred from the reconfiguration process, and consultancy costs. For the scalability and availability arrangements, Amazon was the preferred means. Sales Engine will adopt the dual approach of reserving some server instances and adding more on demand. On demand instances require no upfront payments and can be used increase or decrease your compute capacity, depending on the client demands on their application (Murty, 2008).
Software.
Much of the software development costs involved will be incurred as a result of developing the thin client through which the customers will use to access their accounts.
Personnel for developing the thin-client that will serve as an access system are already engaged at Sales Engine. Rather than develop the custom applications from scratch, Sales Engine can make use of less custom software development, and instead focus on customizing appropriate tools (Erl, Puttini, & Mahmood, 2013). Sales Engine can task its developers to adapt the relevant tools to the requirement process.
Personnel.
Human Resource considerations for required for the changes to the infrastructure will be minimal since most of the personnel requirements can already be covered by existing staff at Sales Engine. The only possible additions to the staff team would be the persons involved in building the interface between the existing system and the Amazon Web Services framework.
Timelines
The proposed changes to the system in place are expected to take the space of just over four months (120 days). The first forty days will be used to modify the existing system so that it can be accessed as a service over the internet. During this time, the existing infrastructure will be repurposed incrementally to ensure it is capable of supporting the required task. After this is done, an additional 40 days will be used to create the thin-client and interface the new system. Finally, testing will be undertaken to ensure that there are no bugs that can affect the performance of the system.
References
Erl, T., Puttini, R., & Mahmood, Z. (2013). Cloud computing. Upper Saddle River, NJ: Prentice Hall.
Frey, K. & Hall, T. (2007). Application service provider and software as a service agreements line by line. [Boston?]: Aspatore Books.
Greer, M. (2009). Software as a Service inflection point. New York: iUniverse, Inc.
Murty, J. (2008). Programming Amazon Web Services – S3, EC2, SQS, FPS, and SimpleDB. Farnham: O’Reilly.
Turner, M., Budgen, D., & Brereton, P. (2003). Turning software into a service. Computer., 36(10), 38-44.