A case study of a small business system

A small business, for example, an independent stationary shop that consists of a few employees with a shop (bricks and mortar) and an online shop (website) requires a small system, which can allow customers to order stationary online, track orders, manage stock for both shops, and produce monthly reports.

System requirements

If we break down the business requirements, we can understand more about the type of system:

• Customer website
• Administration system
• Manually order stock from suppliers
• Manually arrange delivery
• Low order volume (less than 100 units per day)
• No need for legacy system integration requirement
• No interest in owning IT infrastructure
• Very limited budget for IT

Although it is listed last, the budget requirement will probably be the main factor in designing a system. If service providers have an initial budget of $5,000 to get a system built, and they only want to spend a maximum of $100 a month on running the system, then we're not looking at a multi-tier system with 10 web nodes running on the highest spec server image; we're going to want a small system, which can adequately cope with the volume of orders and cost as little as possible.

Identifying subsystems

From the business requirements, we can see that we need the following IT subsystems:

• Customer website: This is needed for allowing customers to order stationary
• Administration system: This is needed for managing orders and stock

We can look at each subsystem individually, see how they relate to each other, and start making some choices about which technologies to use.

Customer website design

The website needs to allow customers to provide the following facilities:

• Register and log in
• View products
• Make orders
• View order progress
• View order history

We know we need a website so that it narrows things down a bit; I'm not going to try and be fancy and call it something like a customer portal, and it's obviously not a sensible idea to think about desktop applications, where customers would have to download an application and install it on their PC.

We need a website with pages to view the stock, make orders, and view the order history and a relational database to store stock, customer details, and order data. An illustration of the desired system is shown in the next diagram:

In terms of security, customers should be able to authenticate themselves using existing credentials from a well-known identity provider such as Facebook or Twitter, making it more likely for them to make orders from the website and lowering the user admin overhead in the system.

Administration system design

The stock and order management system will allow staff to do the following:

• Manage customer orders
• Check stock levels
• Manage product catalogs
• Enter stock into the system when it arrives from suppliers
• Create address labels for orders
• Run financial reports

We have some more choices of the type of platform we use here; we need something that offers us a UI and can easily integrate with the Azure backend services. We could choose the following platforms:

• Website: This will provide us with a consistent technology for the customer website, so this would reduce development time and increase code, styling, and markup reusability. It provides us with a simple deployment path that deploys to a single web server rather than distributing executable applications, which will make deploying updates more straightforward.
• Windows desktop application: We can use something such as WPF to create a modern UI/UX with good support for Azure integration to interact with the backend services. This will be a different technology to the customer website, so this will require a different developer skill set, which will increase development time and also reduce the amount of reusability on the UI side of the application. Deployment and maintenance will also be more complex as the staff will need to install executable applications on their PCs.
• Mobile application: A mobile application may be a good option especially if we build something such as a universal application, where we can target Windows Phone devices, Windows tablets, and PCs, and have an excellent support for Azure integration (we could even use Xamarin, which would give us this in addition to Android and iOS support!). As with the desktop application, we will need another technology skill set, which again will increase development time and reduce code reuse. Mobile applications also either need to be deployed to a store, which is not really appropriate for line of business (LOB) systems, or need to implement an enterprise solution, which is probably not viable for small businesses.

From this analysis, the main thing that is apparent is having an application that is consistent with the website, to reduce development and maintenance overheads, so we will choose to create a website, as shown in the following diagram:

For security, we want users to be centrally managed with the option of having granular control of access to certain areas and functionality within the website.

System integration

From the designs for the two systems, we can see there is a lot of overlap in terms of data storage, and both systems are cloud-hosted websites in the same business domain. This means that it is a sensible choice to share the same storage.

There is no real overlap between the two websites, so there is no strong driver for sharing a website, and for security reasons, it is better to have them separated, as illustrated in the following diagram:

Identifying critical systems

The customer website and storage are probably the most critical subsystems because they support the online customer revenue stream. The admin website is important as it allows the staff to process customer orders; however, if this system fails, customers can still order products while it is fixed.

Selecting services

Now that we have designed the subsystems, worked out how they are integrated, and decided which ones are the most critical, we can start selecting the services we require:

• Applications: Both websites are fairly simple and have no special requirements for them to need a web role, so we will use two normal websites. Because we're on a tight budget and we're expecting low traffic through the system, we will go for the lowest service tiers. For the customer's website, we'll choose a pair of shared websites, which will support a custom domain name and high availability with the two instances costing $19.35 per month. For the admin website, we will go for a free website. We can always change the service tiers in future if necessary.
• Storage: We have a requirement for a relational data model, so the natural choice is to use an SQL Server over other storage options such as tables, blobs, or disk storage. The database will be shared between both websites. Once we have a more detailed application design, we can try and estimate storage requirements in more detail, but for now, we'll opt for a 1 GB database costing $9.99 per month. For this size of business, it's highly unlikely we'll need a federated database; however, we should still be mindful of this when designing our schema, just in case the database needs scaling out in the future.
• Messaging: Because the whole system is small with a low throughput and a shared database, and we don't have any dedicated batch processing applications, there is no need for a messaging system such as storage queues or Service Bus queues.
• Security: The customer website will implement OAuth2 security, and the admin website will implement Azure Active Directory authentication.

Conclusion of the small business case study

We've been through a methodical approach for designing this system to be built on Microsoft Azure and have come out with the exact services we require and how much it will cost us monthly. The next step would be to go into the application's design phase. We will not take this particular case study any further in this book as all its subsystems are covered in the following enterprise case study.