Software Planning 101: Part 7/7

Tangibles in Software Development

So far we have described what software decisions and trade-offs need to be made as part of creating a software solution. To make things more tangible, we will now focus on the tangibles involved in realizing a product.

Putting the Theory Together

We will also link the different topics we have discussed earlier together in this article: solution abstraction levels, code structure, execution localities and implementation technologies.

Product

The product is defined by business. A product defines the need for software and describes what functionality the software should provide. The product is defined in Business Product and Functional Product abstractions.

Software

Software represents what technology - read software solution - needs to be developed to provide the functionality of the product. This is described in Conceptual Architecture abstraction.

System

At next step the software is broken down into systems and systems into components. Each system has its own code repository and release cycle. How the breakdown happens is defined at Logical Architecture abstraction.

Module

A module is a unit used for implementing software. Modules are designed and implemented independently while remaining aligned with the logical architecture. How to implement a module is described at Technical Design abstraction.

Within a the design of a module the decisions are made about the finer code granularity scales: packages, files, classes and methods.

Code Archive

Modules are not directly exposed but assembled into useable code archives. If not done, we would hardwire our module structure of a system to external systems. Not only want we to remove the complexity of the module structuring, as they have no use of knowing, also it would prevent us to restructure a system.

A code archive makes the functionality of a system available for others to use. Therefore a code archive can include code archives of other systems to make the consumption easier. A module can be many times assembled in different code archives.

Distribution Package

A distribution package is used to leverage an existing technology to manage dependencies and track the versions of code archives present on a host. Examples are pip, apt and yum. Thus a distribution package adds extra metadata for deployment around code archives.

A distribution package contains a service definition that needs to be deployed into a service provider.

Service Provider

A service provider can host logic to perform a specific service. Examples are Apache Tomcat for which logic of a service is defined in war format, or Apache HTTPD with a PHP engine that gets the logic in php files to perform a specific service.

The operating system itself is also a service provider, you can provide your code as binary and it will provide a separate process to host a service that is described in the binary. Service provider is a broader concept and not only applicable on the application tier.

The service provider must be hosted according to the execution locality as defined by the software plan to achieve the desired performance, reliability and security. What service providers to use are part of the implementation technology dimension and needs careful weighing of multiple factors: maturity, resources, license, knowledge, control and runway.

Service

A service is created by hosting logic, code written in modules and assembled in a code archive, in a service provider. How the service is actually operating is the area of the Physical Operation abstraction. This area is where bug fixes are first explored (verified) and where the performance, reliability and security of a service are monitored.

Conclusion

Before starting implementation you would like to know if the solution will be of any quality. To do this, we need to make the right trade-offs, which are done and documented in a software plan. The software plan needs to explicitly define the systems, modules, code archives, distribution packages, service providers and services that will be created to realize a product.