Architecture.Dev: Strategic Engineering

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.

The Selection of Technologies for a Solution Based on the first three software dimensions we do understand what the logic is to be performed, how that is structured in smaller components, and where the different parts of the solution will be executed. Enough to actually to build a solution. The only problem is that still many possible solutions can be created, according to the software plan, and not all of them are good solutions because of the wrong technologies chosen for implementation. Technology is the application of scientific knowledge for practical purposes. Thus software technology is software developed that performs operations based on some prior theory. The theory of what the different software parts need to do, or how to function, is defined during our plan for the code structure. Thus only after we understand what we need from the software we look into technologies to implement the software solution. Technology Selection Strategies There are many variances and combi

The Need for Different Execution Localities The software dimension execution locality describes on what processing unit, what type of instructions are running. Rather than defining absolute localities, it defines relative localities. The Wish for A Single Locality When leveraging only a single processing unit for your solution - e.g. a single logical core on a CPU - the installation and managing of the software is easy. A single binary would suffice. Also no extra effort to write code for communications and coordination between different processing units are needed. Latency is likely on an all time low for a single request (okay... if we ignore the potential parallel processing of a single request, something that likely makes the code so much more complex that it almost never benefits the solution.) . Running your software on a single processing unit is least complex. Systems with more localities are extremely more complex. The destination service can be unavailable. There is no

The Granularity Scale for Code Structures To structure the code of your software, it helps to understand the different granularity scales and their discriminating factors. Code is structured from a top-down approach. First based on business aspects, then based on logical drivers, and last on technical properties. Granularity Scale 1: Enterprise Discriminating factor: owner First, the code is divided based on business owners; what enterprise does own/maintain/write the software? If you don't own the code, you can't structure it anyway. For small/medium companies their might be only a single unit representing all the code. For large enterprises, likely multiple departments or subsidiaries would have their own enterprise unit. Granularity Scale 2: Suite Discriminating factor: goal Next we look at the specific business goal of the software. Some software is for enabling a product or product group. Other software might be there to help for systems integration or infrastruct

The Levels of Abstraction for a Software Solution To make decisions for the software dimensions, almost never the requirements alone provide enough information. The context around a decision needs to be understood. To capture the context we introduce abstraction levels. Solution Abstraction Levels An abstraction is used to focus on a specific aspect of the solution. A solution needs to be considered end-to-end. Therefore we introduce six abstraction levels. Abstraction 1: Business Product The value of the product to the business and the consumer are defined in this abstraction. What is the purpose of the company? What does the company try to achieve by creating this product? How does the product fit in the existing and future product portfolio? How does the product differentiate from other competitive products? What problem does it address of the consumers of the product? This is often expressed through Vision, Mission, Objectives and Goals, competitor analysis, and mor

The Dimensions of a Software Solution Now that we know that we need a software solution plan , let’s investigate what it should cover. So given the same software requirements, can we describe how solutions differ? There are so many different decisions to make but each of those decisions can be classified into one of the four dimensions a software plan should cover. Software Dimensions For software we need to describe four unique aspects: what logic is executed; how is the code structured; where is the code executed; and what technology is used in the implementation. Dimension 1: Logic The execution logic refers to the selection of logic, concrete and abstract forms, to be executed. In abstract form, software is a sequence of steps to perform a specific functionality. In most concrete form, software is a binary containing instructions to be executed by a processing unit. This dimension answers first on a high-level abstraction what the steps are to be performed. After that the d

The Plan of a Software Solution Why Software Planning? In this article we are going to explore the need for software planning. Software planning is a term that is introduced to describe the software architecture, design and other related activities that happen before implementing the software. The details of software planning are not discussed here, as first the need for it will be discussed. Multiple software solutions exists Software is delivered in response to a request for some functionality or requirements that need to be fulfilled. When we would give the same functionality request to multiple developers then all developers will come up with a solution. As experience teaches us, not all developers, actually none of them, will deliver the exact same solution. What is being pointed out here, is that a single request has multiple software solutions. Not all solutions are equal Since the existence of the multiple solutions, as software scientist, your brain should start ask