Solution Architecture: A Practical Example
Introduction
This is the second in a two part series that examines an example of how the principles of enterprise architecture relate to a fictional business. Part one focused on the reference architecture with heavy emphasis on discussing the motivation and strategy layers. This article extends that previous work and focuses on the solution architecture. It will delve more into the practical implementation in technology of the strategies covered as a part of the reference architecture in the prior article. Notably, the reference architecture identified four (4) business processes that are contributory to the strategy — machine learning and data analytics, infrastructure management, information security, and software development. However, for the sake of brevity this article will walk through the solution architecture for only one (1) of the four (4), namely machine learning and data analytics.
As with the previous article, we will use a fictional staffing company, Demo Staffing Company Inc., to illustrate the design. To briefly recap, Demo Staffing Company Inc.’s business model is based on providing talented candidates to large corporate clients. Clients would approach the company with their needs and the company would leverage its network to match those needs with candidates. For its business to grow, the company must deliver utmost satisfaction to its clients to solidify its brand in a highly competitive industry. Machine learning and data analytics is one (1) of four (4) business processes that the company has identified as being key to achieving its goal.
Solution Architecture
Solution architecture is a discipline of enterprise architecture that seeks to define and describe specific systems. It may be a system composed of systems, or it may describe a single system in detail. For example, it may show an element in a design that’s identified as a “ computing cluster “, which is by definition a system of systems. The cluster may be a part of a wider solution architecture. Alternatively, the design could expand on the components of a single server, a single system, that’s a member unit of the cluster to show details of its hardware, network, physical location, its operating system, software, and so on.
Solution architecture is distinct from reference architecture which would seek to describe a wider viewpoint and commonly more closely coupled to higher level business motivations, goals, and strategies. Consider a reference architecture to be a sweeping description connecting the business goals to technology, and the solution architecture to be narrowly and specifically describing how to implement technologies to achieve said business goals.
You should care about solution architecture because its value proposition is showing, in detail, how systems interact to deliver practical and measurable value to your business. It will provide a sufficient level of implementation detail to serve as a playbook for technical roles (such as scientists, developers, and engineers) responsible for instrumenting and delivering a system. It will facilitate regular course correction during the implementation to mitigate scope creep. It will serve as a record of reference for partners and stakeholders. Developing a vetted, solid solution architecture before starting a project will ensure that your business does not spend valuable, and likely expensive, cycles going in less than optimal directions with your deployment.
Having defined solution architecture, let’s now look at our example by walking through the strategy, business, data and application, and technology layers of the design. The designs shown below are done using the ArchiMate modeling language.
Strategy Layer
Fig 1 — Strategy layer showing IT organization resource
While discussing the solution architecture for the machine learning and data analytics business process, we will very briefly cover the strategy layer. The motivation layer that usually precedes the strategy layer will not be included but instead is discussed in detail in the reference architecture. The strategy layer here is highly abridged showing only the one (1) resource element. This is solely to show which resource the business process to be discussed in this solution architecture is assigned. Other elements (also included in the reference architecture) such as courses of action and capabilities, which have assignment and realizing relationships respectively, are again removed for brevity.
Business Layer
Fig 2 — Business layer showing role and associated process
Much like the strategy layer our treatment of the business layer will be brief. It shows only the business process which we will be focusing on, and the business role of data scientist that is assigned to it. The business layer further has an assignment relationship with the strategy layer above. That is, the business role of data scientist is assigned to the business process of machine learning and data analytics. That business process is in turn assigned to the IT organization resource.
Data and Application Layers
Fig 3 — Data and application layer showing elements specific to machine learning and analytics
The data and application layer is where we can begin a more detailed discussion of the solution architecture. This layer, and the technology layer that follows, are the crux of solution architecture. The example above shows an application event, a process, a service, collaboration, components, and data objects. These are connected by realization, aggregation, serving, and accessing relationships. We note that it shows an event driven flow that starts with a resume being submitted via a website to culminate in a data and application service that is offered upwards into the business layer. In effect, the above shows the data and application flow that serves the company’s business process of machine learning and data analytics.
Let’s walk through the details of how the application service is delivered to the business process.
The flow starts off with an application event in the form of a submission of a resume on Demo Staffing Company Inc.’s website. This is a triggering event which indicates that a candidate is interested in finding a suitable job role with one of the company’s clients.
The event triggers an application process that is served by an application service called “Candidate and role selection”.
Candidate role selection is realized by a collaboration comprising two components — “Analyze job role data” and “Predict optimal job role match”. These components perform two distinct activities. First to analyze available data then to leverage that analysis to perform an optimal job role match.
Both components above depend on the availability of data for available candidates, of which the newly submitted resume would be a part of, and available job roles provided by clients that need to be filled.
These steps would be transparent to the business layer which would simply understand the above flow as a service interface that it consumes. This, however, is still a conceptual flow. How is it actually instrumented in terms of hardware and software? This is where the discussion would turn to the technology layer.
Technology Layer
Fig 4 — Technology layer showing instrumentation in the cloud
The final layer in this example of a solution architecture is the technology layer. Most notably this was not included in the reference architecture at all since it explicitly focuses on implementation. It’s common to have product and technology names in the data and application layer as well as in the technology layer. However, for the purposes of this demo we will use mostly generic names.
We can immediately see that, like the data and application layer offering services to the business layer, the technology layer in turn offers services to the data and application layer. The service, “Data science service”, is actually composed of two sub-services, “ Infrastructure-as-a-Service (IaaS)” and “ Database-as-a-Service (DbaaS) “. These are realized by two (2) technology collaborations, “Managed computing in the cloud” and “Managed containers in the cloud”. The messaging here is that both of these elements are many systems collaborating to deliver one technology element.
The managed computing collaboration is simplified to show the cross-section of a single node, “Data science compute server”. This is what actually does the work to deliver the data science service. We expand the elements that comprise this node. Starting from the top of the stack and working downwards we see the R programming language running on Apache Hadoop, which in turn sits on Linux. Managed computing also provides some technology functions that would be helpful to the company. These include high availability, auto scaling, and on-demand distributed computing. The messaging from this collaboration is that the company can deliver a computing capability that’s managed by a vendor which provides useful built-in functions that it need not deploy and manage itself.
Finally, the managed database containers collaboration shows a cloud-based relational database with several technology functions delivered by a vendor. These include high availability, replication, a management system, distributed storage, serverless capability, and automated backup. Like the managed computing collaboration, the company benefits by not needing to itself instrument, deploy, and manage these services.
The top-level takeaway from the technology layer as shown here is that the company leverages the public cloud to reduce the operating costs of on-premises infrastructure.
Putting It All Together
As we did with the reference architecture, let’s now represent the full design having discussed the constituent parts. Again, this is only one (1) of the four (4) business processes that would have become solution architectures from the reference architecture. Like the reference architecture this shows the relationships that exist between the layers themselves.
Fig 5 — Complete machine learning solution architecture