Chapter 1. Case Study
I only solve the toughest of cases. Bring it on!
Life without context is like a boat without sails. Context helps us focus on the work at hand; it gives us a sense of direction and a reason to achieve something worthwhile! Architecture, as it applies to the fields of information technology (IT) and computer engineering, also needs a reason for existence. It cries out loud to be instantiated, to be fulfilled, to see itself being realized—contributing to solve real-world problems.
In this chapter, I describe a fictitious case study to illustrate a problem statement. And although I will make no such claim, don’t be surprised if you happen to bump into a similar challenge in the real world! A case study that describes a real-world problem will help provide some context against the backdrop of which the elements of IT or software architecture can see itself being brought to life—an objective raison d’être for software architecture!
The Business Problem
Best West Manufacturers (BWM), Inc., a heavy equipment manufacturing company, has primarily been in the legacy business of manufacturing machinery and heavy equipment with an established customer base.
The industry outlook and independent analyst research reports have predicted that BWM’s opportunities to grow its market share, through the addition of new customer contracts for buying its equipment, may be quite limited in the coming years.
A concerned board of directors met behind closed doors for a significant portion of two consecutive weeks. After much deliberation and several brainstorming sessions, the outcome was summarized and communicated to the company’s senior leadership as a business directive: focus on gaining significantly larger mind- and wallet-share of the aftermarket expenses of the current customer base.
The company’s C-level executives analyzed the directive and deemed it critical to channel the focus on offering more services to the customers. This meant that BWM would be offering more value-added services along with the sales of the equipment itself. The value-added services would be targeted at helping the customers maximize their production through efficient use of the machines, reducing unplanned maintenance downtimes, and predicting failures well ahead of their actual occurrences.
The Technical Challenge
To support a set of high-valued services along with the fleet of machines, BWM needed a state-of-the-art IT System as a foundational backbone. There was a distinct lack of in-house IT expertise to conceptualize, formulate, architect, design, and build such a robust enterprise-scale system.
Some of the challenges that were immediately apparent were
• Lack of in-house software development skills and expertise
• Lack of exposure to the current state-of-the-art technologies
• Lack of exposure, experience, and expertise in software development methodologies
• Lack of an IT infrastructure to host an enterprise class system
The technical team, with sponsorship and support from the business, decided to hire a consulting firm to assist them in their transformation journey. And they did!
Focusing on the solution, the consulting firm started by picking up a set of usage scenarios, subsequently formalized into use cases, that would collectively provide appropriate understanding and appreciation of the complexity, criticality, and capabilities supported by the solution to be built.
Some of the key use cases are described in this chapter. However, the use cases presented here
• Are primarily business use cases
• Represent only a small subset of the actual number of use cases
• Are described in simple language, at a very high level, and do not include any technical manifestations or details
Use Cases
The following sections describe a few system features that characterize and define the core capability set that the system ought to support. The capabilities represent a fully functional IT System that in turn participates in an ecosystem that integrates the end-to-end supply chain—from equipment sell to aftermarket value-added services (the focus of this IT System) to an optimized inventory of parts supply.
I illustrate four use cases that will form the central theme of our case study.
Note: In this book, any reference to the “IT System” denotes the system or application that is being built. Any reference to “system” should be assumed to also mean the IT System. Also, in the context of our case study, machine and equipment mean the same thing and hence may be used interchangeably.
Real-Time Processing and Monitoring of Machine Operations
The system should be able to process the incoming stream of data from the instrumented machines in such a way that key performance and monitoring metrics are computed in real time—that is, as and when the data is emitted from the machine instrumentation, such as from digital machine sensors. Multiple metrics may constitute a critical mass of information and insight that collectively will determine the real-time processing and monitoring signature of any given machine type.
It is expected that the real-time processing happens before the data is persisted into any storage. The frequencies at which data may arrive from any given machine could be in milliseconds while data from multiple machines can also arrive simultaneously.
The computed metrics would be persisted into a persistent store and will also be made available on visual monitoring dashboards that can update information at the speed at which they are computed and generated.
The main actors intended to interact with the IT System in support of and to leverage this capability are Field Personnel and the Monitoring Supervisor.
Seamless Activation of Services for New Machines
The system should be able to on-board—that is, add—new machines to the system. Such an addition should not only be seamless and transparent to the end user but also quick in its execution.
When a new machine is sold to a customer, the buyer expects the offered services to be available and activated. Hence, the machine should be automatically registered with the IT System such that the services are active from the first time the customer starts using the machine and data is generated by the instrumentations on the machine.
Seamlessness, in this case, is characterized by the minimal need of user intervention to enable all aspects of the IT System to be aware of the introduction of the new machine(s). This includes gathering machine data from the fields to visualizing real-time monitoring metrics, proactive diagnostics, and automating the subsequent generation of work orders (to fix any upcoming equipment conditions).
The main actor intended to interact with the IT System in support of this system feature is the Power User.
Generation of Work Orders
The system should support proactive determination and generation of maintenance work orders. It should be able to identify faults in machine operations and should also be able to predict the imminent failure or breakdown of the machine or its component parts.
It should be able to intelligently assess the severity of the machine condition and determine whether there is a possibility for the required maintenance to wait until the next scheduled maintenance cycle. Upon determination, it should make a decision on whether to generate and initiate a work order or to wait for the next maintenance cycle, issuing a warning to the appropriate personnel in the latter case.
The entire workflow should be automated with a final validation step (by maintenance personnel) before the work order is initiated from the system.
The main actor intended to interact with the IT System in support of this capability is the Maintenance Supervisor.
Minimal Latency Glitches for Customers Worldwide
The system should not give its users an impression that it performs slowly. The user interactions and the corresponding system responses should be better than typical tolerable limits of any enterprise class system.
The system should not give an impression that its globally distributed nature of coverage is a reason for higher latency and lower throughput.
The system should categorize features based on time sensitivity and criticality and accordingly put a premium on minimizing latency and maximizing throughput for the more sensitive and critical features. For example, the “Real-Time Processing and Monitoring of Machine Operations” is a time-critical feature; therefore, it should not give an impression to the user that system response (that is, the display of performance and monitoring metrics) is slow and the information refresh does not occur in real time.
This system feature should be supported regardless of any specific human actor(s) interacting with the system.
The four use cases described here are best considered as some significant capabilities that the IT System must exhibit. Such capabilities are usually captured as business use cases.
Also, be aware that a business use case is different from a system use case. Without getting into “use case analysis paralysis,” it is worthwhile to state that the essential difference between a business use case and a system use case is that the former illustrates “what” a system should provide in the form of capabilities, whereas the latter illustrates “how” the features ought to be implemented by the system. Use case definition is a discipline in its own right and constitutes the first phase of any software development life cycle—that is, Requirements Gathering.
Summary
The architecture of an IT System is arguably one of the most critical elements that shapes and holds all the software development pieces together.
There exists a common syndrome, even among the experts in software architecture and system developers, to theorize and generalize more than what is required to address the problem at hand. Having such a problem at hand often helps the software architect take a step back and reassess: Am I making this too complex? Am I generalizing this more than what is required to solve the problem? Am I overengineering the IT System’s architecture?
A case study provides the context of the problem to solve and defines a set of boundaries that assist in focusing and addressing the problem at hand.
Such a focus marks the inception of a cult I aspire to start: The Practical Software Architect. (And if you are aspiring to be a practical software architect, you picked up the right book!)