Posts

3 Essentials for Software Design

Image
1. Your Toolbox: Design PatternsIn software design, design patterns are an essential toolbox to ensure your code is broken down into small independent units. This toolbox gets filled one-by-one, a single design pattern at a time. Since the tools can be used in different combinations, quickly the toolbox owner becomes more effective in creating a design that is focused on minimum effort and risk. This is especially true if you write or support software in a team. First you must ensure the tasks - and thus the code - are broken down into independent units. Common symptoms that arise when this is not properly done: engineers waiting on each other code to complete, functionality duplication, merge conflicts, the work of member "a" breaks the work of member "b" (regression bugs), incoherent interfaces - e.g. getX, doWriteX, deleteById; while much more coherent interface would be: readX-writeX-deleteX, or getX-updateX-deleteX.The second issue is in supporting (reading) th…

Technical and Strategic Architects: Expert vs Analyst

Earlier we discussed Analyzing Software: Technical, Tactical and Strategic Qualities. As a comment pointed out, finding the right candidates is very challenging. This article explores the differences in skills needed, something that might benefit you in selecting the right candidate for the right role.DefinitionsWhen comparing people who are an analyst or an expert, many similarities can be found. Both have proper education, and both are for sure not rookies in the field. Thus to help separating the different skills needed for different roles, a more narrow definition of the terms will be used.The Expert: a person who has gained Experience through extensive practiceThe Analyst: a person who has Analyzed the work of many different ExpertsThe ExpertDuring an interview with a candidate, people start talking about their experience: what have they done. It tends to be that people often repeat their approach, especially if it yielded prior success. Thus almost naturally they tend to special…

Analyzing Software: Technical, Tactical and Strategic Qualities

Building software always comes with significant investments, but should be only a fraction of the possible long term gains. To ensure the software yields the expected outcomes, not only for the first releases, the first two years, but long term, the software must be developed with different qualities.Long term? How many systems does your organization have, that are 3+ years old and are not limiting the potential capabilities of the company [without reinvesting/rewriting them]?.In this article a small framework to assess the quality of your software is presented. To ensure software is profitable for the company during its full potential, we analyze the software on 3 different levels: Technical, Tactical and Strategic. This can be the first step to improve the earn backs of your technology/software investments.Technical QualityWhen people learn how to program, the syntax of the language is explained. Next in detail is explained, how to do recursion, with the termination condition; how t…

Data Perspectives & Representations

Image
Failure of Software DesignSoftware systems process data. Either this is computation input/output or persistent data read from storage for processing. To minimize the effort and risk to realize a software solution - - many architects model the data based on the inputs and outputs. They just add some annotations on those models, and voila, it can be written and read from a database!Software design is the process of minimizing the effort and risk of developing your software.Unfortunately, they are not knowing that using the same data perspective for input/output and storage - or in other words, not using different data representations - is one of the biggest reason that the system will be a legacy system, and that needs to be replaced as soon as it is ready. :(Software architecture is the process of making sure that future changes to the needs can be easily accommodated in your software.To explain a bit more, the business needs are constantly changing, therefore the inputs and outputs o…

External Services Integration Strategies

In today's world, the systems you are developing are not isolated, they need many different integrations with other external services. From Authentication Systems (using SAML, LDAP, OIDC) to Data and Processing Systems (Malware Analysis, CRMs, Ticketing Systems).Although the number of actual systems to integrate with is vast, luckily the Use Cases and types of integrations are manageable. Here we will discuss popular Use Cases and list integration strategies to accomplish them.Use Case 1: Transfer the User from your System to the External ServiceIn this scenario, the User is working in your system and is now required to access specific functionality in an External Service. The following steps must happen: the service must be located, the user must be authenticated, and the right interface/data must be presented.1.1 Service Locator IntegrationYour system understands how to find the specific service, the user does not need to remember the location of the external service he wish to …

Where Programming Ends and Engineering Starts

Ask a developer if he is developing the same software as in his previous engagements, and most of the time the answer is "no". On first sight it looks reasonable, if you consider that he has been working on a different project, in a different company, or even within a different industry vertical.But when we analyze the code that is actually developed, this is most peculiar. Code is made up of business logic and "plumbing". Business logic is around 5% of the total code and project specific. The rest is plumbing that is not specific to the requirements of the project. If 95% of the code is not specific to the project, how can it be that we are not writing mostly the same code?The reason is often simple, the business logic is not isolated from the plumbing. This causes the plumbing code to become project contextual; the plumbing code is full of traces of business logic and thus specific to the project. Thus the potential 95% that should be project agnostic can't b…

Software Planning 101: Part 7/7

Image
Tangibles in Software DevelopmentSo 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…