Forem: Dima Nikulin

What Content to Create and How to Publish It, Part 2

Dima Nikulin — Tue, 06 May 2025 06:31:31 +0000

Overview

In today's digital landscape, creating compelling and polished content is essential for capturing and retaining audience attention.
This comprehensive guide offers invaluable insights and strategies for optimizing your content across various platforms.
From refining your writing and formatting techniques to maximizing audience engagement and platform-specific publishing, this guide covers everything you need to know to elevate your content creation game.
Whether you're a seasoned writer or just starting out, follow these tips and best practices to ensure your publications stand out in a crowded online space.

Size

The publication should not be overly dense or difficult to read.
When considering a typical piece intended for public consumption, I propose aiming for an ideal publication size of under 2500 words.

On the other hand, the size should not be too small, where it can be consumed in just one minute.
I would suggest 800 words as the smallest size for a publication.

No formatting symbols

An important point to note is the absence of any formatting symbols in the publication, such as or .
These symbols may appear if you copy your content from another document format.

Citations

There is a recommendation for citations to be formatted as in-line links, with any recommended reading listed separately.

Tables

If you use tables in your publications, please make sure that columns with less content are placed towards the end of the table, and vice versa.

Additionally, I suggest placing more important columns at the beginning of the table so that readers will first encounter the most important information.

Last but not least, I would suggest using tables as images, as many publication platforms do not fully support tables.
Still, keeping the source of tables will provide you with the ability to update table images in case of a change.

Pictures

Please notice a really important point: fewer pictures mean fewer views.
Certainly, all pictures should be related to the text content and enhance its meaning.

I suggest having a featured image as a title image. It might be interactive, like a gif.

I would prefer album orientation to be album rather than book orientation. It will use the user's screen more efficiently.

Plagiarism

Please note that readers prefer content to be 100% original.
They expect 0% plagiarism or duplicate content, and all sources must be properly cited.

When using a quote or definition from another source, it must be cited using an in-line link to provide attribution and enable readers to verify the information.

You can use this website to check for plagiarism.

Make Proofreading

And yes, your content should not have any punctuation or syntax mistakes.
Also, there should not be any formatting issues.
To make it possible, you will need to proofread the content.

How do I do that?
The best way to do it is to have it proofread by a human.
It might be costly, and there is software to help you, such as ChatGPT, MS Word, or Google Docs.

Also, Hashnode has an online proofreading option, so you can post there first.

Publishing on Multiple Platforms

I publish my content on different platforms � seven for now.
When I join a platform, the first thing I do is read the requirements on how to publish there.
The content you publish should be relevant and applicable to the platform.
For example, I don't use Facebook to post programming stuff.

All platforms suggest filling out the user profile before publication so people who read your publication can contact you if they are interested.
Profiles on different platforms should be consistent with each other.
Here, I use a link to one public profile on GitHub.

Usually, I first publish my content on Hackernoon as they check my content thoroughly, and then I publish it on other platforms so it is well-checked.

Time and Frequency of Publication

It is quite important to select the proper day and time for publication.
I usually publish on Mondays and Thursdays, typically between 10 AM and 3 PM my local time, Ukrainian time.
It should definitely not be early in the morning or late at night.

Also, please note that publishing on holidays may result in fewer views.
This is applicable to summer as well; you will likely see fewer reactions.
Additionally, if there is another important event on the platform at the time of your publication, you may lose views, although they may accumulate later.

Regarding frequency, I publish one to two times per week to avoid overloading my readers and to ensure they don't forget about me.

Language

I would recommend using English where possible because it is the most widely known language.

Checklist

As you can see, there are a lot of items not to forget about.
That's why I use a checklist to help me remember important points.
Here it is:

Is there a Headline?
Is the Headline less than 150 characters?
Is there an Overview to start from?
Are there Tags?
Is there a Table of contents?
Are there no formatting symbols?
Are there no empty chapters?
Are Definitions, Acronyms, Abbreviations sorted?
Is there no Personally Identifiable Information (PII)?
Is there no TBD and TODO?
Does it ask for an opinion?
Has it been proofread?
Is bold text used for keywords?
Is italics used for conversation?
Are all references current?
Is the length under 2500 words?
Are there any pictures?

What Content to Create and How to Publish It, Part 1

Dima Nikulin — Fri, 10 Jan 2025 08:59:32 +0000

Overview

Mastering the Art of Publication:
A comprehensive guide outlining key criteria for evaluating publications, common recommendations for successful content creation, essential publication structure guidelines, and must-have chapters.
Learn how to optimize your publications for engagement and readability while ensuring effective organization and categorization through tags.

Criteria for Evaluating Publications

Understanding the effectiveness of published works is paramount in today's digital landscape.
Having posted numerous publications across seven different sites, I've identified several key criteria for determining the success and interest level of each publication:

Number of Views: The total number of times the publication has been viewed is a primary indicator of its reach and impact.
Comments: Engaging comments indicate that the publication has sparked discussion and resonated with the audience.
Likes and Reposts: The number of likes and reposts reflects the level of appreciation and the desire to share the publication with others.
Savings into Bookmarks: When readers save the publication into their bookmarks, it suggests that they find the content valuable and wish to revisit it in the future.

By assessing these metrics, I can gauge the effectiveness of each publication and tailor future content to better meet the interests and preferences of the audience.

Common Recommendations

Crafting compelling and impactful content requires adherence to certain guiding principles.
When publishing, it's crucial to ensure that the content reads like a story rather than a mere collection of facts.
It's immensely valuable to draw from personal experiences rather than relying solely on information gathered from books and online sources, avoiding mere reposts.
Our content should reflect our own opinions, which might sometimes be provocative to stimulate discussion and even elicit strong reactions. For example, you can describe any pain points for yourself and for society.
Additionally, the content should encourage readers to form their own opinions and engage in meaningful dialogue.

Furthermore, it's important to be responsive to comments by addressing any questions or concerns raised.
This interaction helps foster a sense of community and encourages further engagement with the content.

Publication Structure

A well-structured publication enhances readability and comprehension.
So when creating content, it is crucial to prioritize structure, especially for larger texts.
The following guidelines should be adhered to:

Paragraphs and Indentation: Ensure that paragraphs are used to maintain clear segmentation of ideas. Implement proper indentation to enhance readability.
Headings and Subheadings: Utilize headings and subheadings to organize content hierarchically. Limit heading levels to three for simplicity and clarity.
Lists: Integrate bulleted or numbered lists to present information concisely.
Chapter Order: Recognize the significance of the order of chapters, following the conventions of scientific documents.

By adhering to these guidelines, your content will not only be well-structured but also enhance the overall readability and comprehension of the larger text.

Must-Have Chapters

Certain chapters serve as linchpins in the architecture of comprehensive documents.
In any comprehensive document, the following chapters are essential:

Headline: This chapter serves as the introduction, providing a concise and compelling overview of the document's main theme or purpose.
Overview: The overview chapter expands on the headline, offering a more detailed insight into the document's content, objectives, and key points.
Tags: In this chapter, relevant tags are included to categorize and label the document, aiding in searchability and organization.
Table of Contents: The table of contents chapter provides a structured outline of the document, listing its sections and subsections, guiding readers through the content.

Ensuring the inclusion of these must-have chapters will contribute to the clarity, accessibility, and overall effectiveness of the document.

Optional Chapters

While some chapters are essential, others offer additional value and flexibility in content creation.
I would like to note that the Alternative Headline, Definitions, Acronyms, Abbreviations, Introduction and References chapters are optional.

Generally, there is no need for a glossary.

If there are terms that the reader may not know, please explain them where and when they are mentioned.

"Headline" chapter

The headline serves as the gateway to the publication, encapsulating its essence in a concise and compelling manner.
I use ChatGPT to assist me in generating headlines.
Therefore, I copy the entire content into ChatGPT and ask it to generate a headline.
Please note that sometimes it may require a few corrections because it might extract a headline based only on a part of the content and not the entire text.

"Table of contents" chapter

The table of contents provides readers with a structured overview of the publication's contents, facilitating navigation and comprehension.

"Overview" Chapter

The overview chapter typically offers a brief summary or introduction to the main topics covered in the document.
It serves as a way to orient the reader and provide context before delving into more detailed information.

Alternatively, this chapter is often referred to as TL;DR - too long; didn't read.

Similar to the previous chapter, I use ChatGPT to assist me in generating the Overview.
Therefore, I copy the entire content into ChatGPT and ask it to generate an Overview.

"Tags" Chapter

Tags for text documents are keywords or labels assigned to the document to categorize or describe its content.
Tags play a crucial role in categorizing and organizing content, enhancing searchability and discoverability.
These tags aid in organizing and classifying documents, making them easier to search, filter, and retrieve later.

I use these tags to include on the platform where I am publishing.

Once more, I utilize ChatGPT to assist me in generating the tags.

"Definitions, Acronyms, Abbreviations" Chapter

Clarifying terminology is essential for enhancing reader comprehension and clarity.
This chapter lists Definitions, Acronyms, and Abbreviations in the form of a table.

It consists of 3 columns:

Number: Indicates the row number.
Abbreviation or Acronym: The name of the Abbreviation or Acronym.
Definition: Explains the Abbreviation or Acronym.

"References" Chapter

Citing sources and references adds credibility and authority to the publication.
It is recommended to include links at the point of mention.
Additionally, a separate chapter for references in the form of a table is desired.

The table consists of 6 columns:

Number: Indicates the row number.
Name: The name of the reference.
Source: The name of the resource where it is published.
Release Date: The date of release.
Author: The content creator.
Description: An additional field for details.

Detecting Architectural Gaps with Automation - Proposed Solution

Dima Nikulin — Fri, 31 May 2024 11:37:56 +0000

Introduction

In the ever-evolving realm of software development, the quest for a robust and seamlessly integrated solution stands as a paramount pursuit.
This article embarks on a comprehensive journey into the depths of a proposed software solution, meticulously scrutinizing its architecture, integration strategies, and deployment modalities.
Through this exploration, we illuminate the symbiotic dance between users and technology, offering a roadmap for architects, developers, and IT aficionados alike to navigate the labyrinth of a forward-thinking software solution.

The Context View for Standalone Application

A context diagram (view) defines the solution's boundaries and connections with third parties, such as external systems, users, and data.

As shown in the context diagram above, there is an interaction between Users and the Proposed Solution.
These interactions will be implemented using a UI web interface.

For obtaining input, the solution interacts with Online and Offline UML tools using their API to retrieve the initial Software Architecture and to save the extracted Software Architecture.

To access code, configuration, and the database, interactions with Version Control Systems and the database are utilized.

Finally, Report Storage is employed to save the outputs extracted from the Architecture under analysis.

The Context View for a Separate Step in CI/CD

The sole distinction between the previous view and the Context View for a Separate Step in CI/CD is the integration of the proposed solution with the existing CI/CD pipeline.

Functional View

The functional diagram below illustrates the high-level functional decomposition of the proposed solution.
An agenda is provided below to explain the color coding used in the functional decomposition diagram.

Integration Layer

The function of the integration layer is to abstract and segregate the system from external components, enhancing system extensibility and modifiability.

The following components are involved:

Online UML Tools Integration Point: This component integrates Online UML tools with the Processor.
Offline UML Tools Integration Point: This component integrates Offline UML tools with the Processor.
Version Control Systems (VSC) Integration Point: This component integrates Version Control Systems with the Processor.
Databases Integration Point: This component integrates database configurations with the Processor.
CI/CD Integration Point: This component integrates CI/CD tools (such as Jenkins, Bamboo) with the Processor.
Reports Plugins: An engine designed to generate reports in a flexible manner and store them in an external report storage.

User Interface

The user interface function interacts with users in two modes: architects and administrator mode.
It utilizes a web interface that is compatible with desktop browsers.

Data Layer

The data layer function maintains the following types of data:

Architecture Baselines: This feature records the history of architecture changes, allowing users to track and view past changes. It is accessible for viewing from the architects' panel.
System Configuration: This aspect encompasses a set of check configurations for processing. It also keeps track of configurations for report plugins. Changes to these configurations can be made from the architects' panel.
User Configuration: This includes user profiles and access rights, which can be modified from the administrator panel.

Processing Layer

The processing layer serves as a fundamental function within systems, tasked with processing input data to identify architecture problems.
Configuration of this layer takes place through the architect panel, where checks against the input are initiated.
Additionally, it collaborates with the reports plugins engine for report storage.
Furthermore, the extracted architecture is preserved in Architecture baselines, enabling architects to review it at a later time.
It is worth noting that Machine Learning (ML) might be employed during processing to enhance the quality of reports.

Deployment View

The deployment view illustrates how a solution is intended to be deployed, encompassing its flows and the supporting components.

Deployment View - On-Premises

On-premise deployment assumes the use of a single computing node for installation.
The Database component should be deployed first, as other components depend on it.
Subsequently, the Processor and ML components are deployed once the Database component is in place.
The User Interface component, report plugins, and integration points are deployed in the final stage.

The Database component is deployed as a single DB instance with multiple schemas inside.
The User Interface component is presented as a web service, while the Processor and ML components are native processes built for the target platform.
Reports plugins and integration points are designed as dynamic libraries that can be easily added, removed, and configured at runtime.

Deployment View - Cloud

Cloud deployment involves the utilization of two computing nodes for installation.
Due to the potentially high CPU usage of the Machine Learning process, it is recommended to allocate a dedicated machine for this purpose within the cloud pipeline.

Integration with UML Design Tools:

As previously mentioned, the proposed solution should seamlessly integrate with offline UML design tools, including:

Microsoft Visio
OmniGraffle

Furthermore, the proposed solution should also integrate effectively with online UML design tools, which encompass:

Enterprise Architecture
LucidChart
Draw.IO
PlantUML
Gliffy.com

Integration with Offline UML Design Tools

Due to the absence of APIs in offline tools, collaboration with them is established through import mechanisms.
Consequently, architectural documents saved in Microsoft Visio format will be exported by a plugin (integration point) and subsequently analyzed by the Processor.
The path for scanning input documents will be stored in the System Configuration DB.
To support this form of integration, the ability to parse various input formats must be implemented.

Integration with Online UML Design Tools

Online UML design tools typically offer APIs for integration purposes.
The collaboration with such tools will make use of their respective APIs.
However, it's important to note that some UML design tools might lack APIs for integration.
In such scenarios, the import of architecture documents to a designated folder will be undertaken.
The subsequent parsing of these documents will be implemented to import data into the Processor, following a similar approach as outlined earlier for offline tools.

For online UML design tools, HTTP or REST APIs are commonly available.
Accordingly, the integration point will access data within the UML design tool using the provided HTTP or REST API.
Each integration with a specific tool will require a distinct integration point.
For instance, integration with LucidChart will be realized using the HTTP protocol with GET and POST verbs.
On the other hand, integration with Enterprise Architect will involve the use of a REST API with JSON as the data format.

Integration with AWS, Azure, or GCP

This section outlines how the proposed solution can seamlessly integrate with AWS, Azure, or GCP.
Given the potential enhancements Machine Learning can offer in terms of result quality, it is advisable to allocate a dedicated compute node for ML tasks.
However, in scenarios where the on-premise environment lacks the capability to support ML calculations, a viable solution is to leverage a Cloud Environment for both ML computation and the overall computing needs.

Drawing from the deployment flows previously described, each component should be matched with the appropriate cloud provider service.
For instance, in the context of AWS:

Processor - Leveraging AWS Lambda functions
Database - Utilizing RDS and MySQL services
Machine Learning - Employing AWS Machine Learning services
And so forth for other components

Similar mapping strategies can be applied for Azure and GCP, ensuring that each component seamlessly integrates with the suitable services provided by the respective cloud platforms.

Dependency Analysis Tool

Dependency identification plays a crucial role in architecture analysis.
It dissects the entire codebase into components and elucidates their interactions.
Given that similar functions are already available in tools like JDeps, leveraging their output would logically bolster the implementation of the proposed solution.
JDeps, for instance, is a command-line tool utilized for launching the Java class dependency analyzer.
For systems built on the .NET framework, Net Dependency Walker serves as a suitable choice to ascertain dependencies.

Integration with Jenkins or Bamboo

As mentioned previously, one facet of the application involves integration within a CI/CD pipeline.
CI/CD represents a multifaceted and composite process, encompassing numerous stages.
Within a single CI/CD pipeline, a plethora of functionalities converge to facilitate a comprehensive workflow.

The diagram provided illustrates a standard CI/CD pipeline, depicted as the first pipeline.
This pipeline encompasses multiple sequential stages, which include:

Plan
Code
Build
Test
Release
Deploy
Operate

At present, two prominent products, Jenkins and Bamboo, serve as implementations of the CI/CD pipeline concept.
In real-world project scenarios, both Jenkins and Bamboo are utilized to create pipelines tailored to specific project requirements.
Typically, upon each code commit, at least one pipeline is triggered, orchestrating various processes.

In the context of integrating the proposed solution, the existing pipeline structure can be extended.
This extension entails invoking the proposed solution for architecture analysis.
Consequently, the augmented pipeline would resemble the second pipeline depicted in the provided diagram.

Detecting Architectural Gaps with Automation - Existing Solutions

Dima Nikulin — Fri, 05 Apr 2024 06:59:48 +0000

Introduction

In the rapidly evolving landscape of software development, maintaining the integrity and coherence of application architectures is paramount.
With the proliferation of complex systems and frequent updates, ensuring that software architectures remain resilient against drifts, erosions, and compliance lapses has become a daunting challenge.
However, innovative solutions like Bionic.ai, Castsoftware, NDepend, and Axivion Suite are revolutionizing the way organizations approach architecture governance and code quality management.
As organizations navigate the complexities of modern software development, these innovative solutions provide indispensable tools for ensuring architectural coherence, compliance adherence, and code quality excellence.
Through their diverse feature sets and integrative approaches, they herald a new era of architecture governance and software development efficiency.

Bionic.ai

Bionic is a platform designed to analyze the architecture of applications and their dependencies in real-time.
Initially, it creates a baseline of the architecture during the initial scan.
Subsequently, whenever a change occurs, the next scan is triggered to detect any drift or erosion.
The platform supports regular scans by seamlessly integrating Bionic.ai into the CI/CD pipeline.
Upon detecting a change, Bionic.ai suggests the context and thoroughly analyzes the potential impact of the changes.
As a result, it generates comprehensive software architecture diagrams, encompassing deployment, logical, and flow views.

Main features

Facilitates checking if architecture rules and standards are applied
Aids in identifying any structural or behavioral changes
Conducts code and document scans during the initial or scheduled stages
Determines new APIs in the application
Capable of finding new data flows
Detects new connections
Provides a prioritized list of risks once changes occur

Castsoftware Highlight

Cast Highlight is an application designed to automatically analyze the source code.

Main features:

Analyzes the code to identify processes/applications suitable for refactoring, retirement, or rebuilding.
Provides a readiness percentage for migrating to the cloud based on the analysis.

Castsoftware Cast Imaging

Cast Imaging is an application that creates visualizations of architecture, offering several levels of detailed views ranging from services level up to code/classes level.
It defines data flows from the high-level application perspective down to the database level.
When changes occur, it provides the impact analysis, such as a list of components affected by the breaking of component communication.
Additionally, it creates inventories of databases, libraries/frameworks, and languages.

Main features

Performs reverse engineering of code, databases, and application dependencies.
Generates holistic architecture views and blueprints.
Interactive mode for exploring architecture views.
Tagging feature to group components based on criteria, enabling easy component search and filtering after tagging is completed.

NDepend

NDepend is an application designed to analyze C# code, checking it against best practices and rules created by developers and architects.
The tool enables users to manage dependencies through the creation of graphs and matrices.

Main features

Utilize built-in rules and customize them according to specific needs.
Investigate application structure and library linkages.
Seamless integration into the CI/CD process, enabling real-time identification of code and architecture issues.
Provides insights into the cost and priority of fixing identified issues.

Axivion Suite

Axivion Suite is a powerful static code analysis tool that empowers users to thoroughly examine software architecture, ensuring prevention of drifts and erosions.
The platform offers customizable reporting with a reporting API, providing flexibility in generating reports.
Axivion also includes an editor that allows users to create or customize rules for comprehensive code checking.

Supported Compliance Standards/Rules:

MISRA
AUTOSAR C++14 code
CERT
CWE
ISO/IEC TS 17961

Supported Metrics:

HIS (High Integrity Software)
McCabe
Tracking memory leaks

With Axivion Suite, users can proactively maintain the integrity and quality of their software architecture by adhering to industry-leading compliance standards and monitoring key metrics.

Main Features

Code checks for clones, identifying duplicated code segments to ensure code efficiency.
Detection of unreachable code and cycles, improving code reliability and performance.
Supported on three major operating systems - MacOS, Windows, and Linux, for seamless usage across platforms.
Identification of technical debt, allowing developers to address code areas that require improvement or refactoring.
Integration with CI (Continuous Integration) tools such as Jenkins and Bamboo, enabling smooth integration into development pipelines.
Support for popular build systems like make, CMake, Msbuild, and Gradle, facilitating easy setup and usage.
Analysis of delta changes against the baseline, enabling continuous tracking of code modifications and their impact on the architecture.
IDE (Integrated Development Environment) plugins support, allowing developers to seamlessly integrate Axivion Suite into their preferred development environment for streamlined code analysis and optimization

Comparison of existing solutions

Function	Bionic	Cast Imaging and Highlight	Axivion	NDepend
The initial scan to create a baseline of the holistic application architecture diagram involves capturing the comprehensive overview of all services, data flows, dependencies, APIs, technology stack, and application layers	+	+	+	+
Creating inventories of all the languages, frameworks, libraries, and databases used in the application	-	+	+	-
The scan after a change to detect drift or erosion (integration into CI/CD pipelines)	+	-	+	+
Tagging the components	-	+	-	-
Reporting the changes (behavioral or structural change)	+	+	+	+
Detection Security level issues	+	+	+	+
Detection Architecture level issues(new data flow, new API, new connection)	+	+	-	+
Detection Compliance level issues	+	-	+	-
Detection DevOps level issues	-	-	-	-
Detection Data level issues	-	-	-	-
Scanning code and configuration	+	+	+	+
Scanning documentation (UML) to get input	-	-	+	-
Scanning DB	-	+	-	+
Saving the results to UML documentation tools	-	-	-	-
Impact analysis	+	+	-	+
Simple to set up	+	+	+	+
Check for cloud Readiness	-	+	-	-

As we can see from the table above, the existing solutions do not provide coverage for levels important for architecture governance, such as DevOps, Data, and Compliance.
Additionally, not all inputs are supported by the overviewed solutions.
For example, scanning DB is not supported by Bionic.ai, and scanning UML documentation is not supported at all.

Detecting Architectural Gaps with Automation - Business Context

Dima Nikulin — Tue, 05 Mar 2024 06:50:53 +0000

Executive summary

In today's rapidly changing software world, the ability to adapt and evolve the software architecture is crucial for success.
The readiness for change is a key factor in ensuring a product can meet evolving business and product requirements in the high-tech industry.

However, uncontrolled architecture drifts and erosions pose significant risks to a product's success.
These drifts can result in the loss of expected extensibility and hinder the adoption of a product as the user base grows.
Identifying and addressing these drifts is often done through complex and time-consuming manual architecture reviews, relying on experienced architects to assess the software architecture.

Despite the importance of manual reviews, they have limitations in terms of efficiency and coverage.
Human factors can influence the identification of architectural issues, leading to inconsistencies and potentially missing critical problems.

To overcome these challenges, there is a need for automated solutions that can detect architecture drift and erosion more effectively.
By leveraging automated tools and processes, organizations can achieve better outcomes in terms of identifying and preventing architectural issues.

This white paper explores the concept of detecting architectural gaps with automation.
It covers the impact of architecture drift and erosion on the business, the limitations of manual reviews, and the benefits of automating architecture checks.
Additionally, it discusses specific considerations related to compliance, data security, DevOps, and more when evaluating architecture review solutions.
The paper also provides use case scenarios to illustrate what automated architecture checks can look like in practice.

By adopting automated architecture review solutions, organizations can improve their ability to identify and address architectural gaps, ensuring the stability, scalability, and maintainability of their software systems.

Detecting Architectural Gaps with Automation

Please read this paper before proceeding to the next chapters.

You will gain insights into the following:

Understanding architecture drift and erosion: Learn what architecture drift and erosion are and how they can impact the business. Gain an understanding of the risks and challenges associated with uncontrolled architectural changes.
Manual inspections and their limitations: Explore the role of dependency analysis, peer reviews, and other manual inspections in detecting architectural issues. Understand why manual reviews, while important, may not be the ideal solution due to their limitations.
The need for automated architecture review: Discover the benefits of automating architecture checks and how they can complement manual reviews. Learn how automation can provide more efficient and comprehensive detection of architectural gaps.
Considerations for evaluating architecture review solutions: Explore specific considerations to keep in mind when evaluating architecture review solutions. Topics covered include compliance, data security, DevOps integration, and more.
Use case scenarios: Gain insights into what automating architecture checks may look like through a series of example use case scenarios. Understand how automation can be applied in practical situations to enhance architecture review processes.

By reading this paper, you will develop a deeper understanding of architecture drift and erosion, the limitations of manual reviews, the benefits of automation, and important considerations when evaluating architecture review solutions.

Solution requirements

This section outlines the requirements for implementing the solution.
It is important to note that these requirements are not exhaustive and can be extended based on the specific needs of the project.
The requirements are categorized into solution modes and inputs, solution integration and user interaction, and solution output with quality attributes like modifiability, extendibility, and configurability.

Solution modes

The proposed solution should support the following modes:

Standalone application: The solution should be designed to run as a standalone application, allowing it to be executed on demand without any dependencies on the target environment. This mode provides flexibility for manual execution of the solution.
Integration with CI/CD pipeline: The solution should have the capability to integrate seamlessly into a CI/CD pipeline as a separate step. This mode enables regular assessment of the architecture within the automated pipeline.

In the context of the CI/CD mode, the following features should be supported:

Initial architecture reference: The solution should allow setting an initial architecture as a reference point. Any deviations from this reference architecture should be identified as architecture drifts.
Drift reporting and approval process: When a drift is detected, the solution should provide an option to approve or decline the changes with comments. The description of the change should include an impact analysis, allowing the user to understand the cost associated with the proposed change.
Documenting drifts and erosion: The solution should provide the ability to save the documentation that describes drifts or erosions. This documentation can be useful for future analysis and reference. It should be easily accessible for review and analysis purposes.
Integration with popular CI/CD tools: The solution should be easily integrated with widely used CI/CD tools such as Jenkins, Bamboo, etc. This ensures compatibility and seamless integration into existing CI/CD workflows.

Solution inputs

The proposed solution can accept various inputs, including:

Code from the solution under review: The solution should be able to analyze and process code files from the software being reviewed.
Configuration from the solution under review: Configuration files used by the software should be compatible with the solution to extract relevant information.
Software design from UML designing tools: The solution should support importing software designs created using UML (Unified Modeling Language) tools. This allows for a comprehensive analysis of the software's architectural design.
Database scripts and database configuration: The solution should be capable of working with database scripts and configurations, enabling analysis of the database layer in the software.

These inputs collectively provide the necessary information for the solution to perform its analysis and evaluation of the software architecture.

Solution integration

Integration of the proposed solution with various tools and systems allows for a comprehensive analysis of software architecture.
Here are the integration possibilities mentioned:

Offline UML designing tools: The solution can be integrated with offline UML designing tools like OmniGraffle and Microsoft Visio. This integration enables the import of UML diagrams created using these tools for analysis and evaluation.
Online UML designing tools: Integration with online UML designing tools such as Enterprise Architect, LucidChart, Draw.IO, PlantUML, and Gliffy.com provides the ability to import UML diagrams created in these platforms. This expands the range of tools that can be used for software design and analysis.
Source control management systems: Integration with source control management systems like SVN and Git allows the solution to access code and configuration files directly from the repository. This ensures that the latest version of the software is analyzed, and any changes made to the codebase are taken into account.

By integrating the solution with these tools and systems, users can leverage existing software design and version control workflows to enhance the effectiveness of the automatic review process.

As an example of the input code could be the code written in C# using microservices architecture.
The other example could be the code written in JavaScript for multi-tier applications.

The example of configuration might be the description of nodes used in deployment.
Another example could be the configuration of VPN networks and API gateways.

The example of input software design can be description of interfaces saved in Enterprise Architect.

User interaction

The proposed solution provides a web interface that allows users to interact with it from a desktop computer.
The interface is designed to accommodate the content and functionality required for software architecture analysis, making it unsuitable for mobile devices such as smartphones or tablets due to their smaller screen size.

There are two types of users supported by the solution: administrators and architects.
Administrators have the capability to configure the system according to the intended use.
They can set up various parameters and customize the solution to meet specific requirements.

Architects, on the other hand, have the ability to run the proposed solution for analysis and review the results.
They can initiate the analysis process and examine the generated analysis reports.
The solution provides dashboards that display relevant metrics and software architecture status, such as the count of components and dependencies.
These dashboards offer a comprehensive overview of the software architecture and assist architects in understanding its structure and characteristics.

By catering to both administrators and architects and offering dedicated functionalities for each role, the solution ensures that users can effectively configure and utilize the system for software architecture analysis and evaluation.

Solution output

The proposed solution offers two formats for presenting the output: text-based (plain text or table) and graphic.

The text-based format, particularly in a table structure, provides users with detailed information about identified issues.

The table typically includes the following columns:

Level of issue: Indicates the severity or significance of the issue.
Issue priority: Specifies the priority level assigned to address the issue.
Issue description: Provides a clear description of the identified issue.
Suggested way to fix the issue: Offers recommendations or guidelines on how to resolve the issue effectively.

Additionally, the table format includes separate sections that list various dependencies, such as frameworks, libraries, APIs, databases, technology stack (languages), and application layers.
Each section provides a comprehensive inventory of the associated components used in the application.
This allows users to gain insights into the technologies and resources utilized and understand their impact on the architecture.

Furthermore, the solution enables users to request inventories of specific elements, including languages, frameworks, libraries, and databases, at any time.
This feature provides a convenient way to access comprehensive information about the software application's underlying components and dependencies.

The graphic format is utilized to visually represent the software architecture, including

the holistic application architecture,
diagrams of all services,
and data flows.

Both offline and online UML diagramming tools are employed to save and document the extracted software architecture.
This graphic format allows users to annotate and tag components and inventory items using user-defined keywords.

Here's an example of a graphic output:

In the graphic representation above, four services and one database are identified within the software architecture.
The diagram clearly illustrates the relationships between these components and the direction of communication between them.

Modifiability and extendibility

Modifiability and extendibility are essential attributes for the proposed solution.
The solution should be designed in a way that allows for easy extension and the addition of new features, such as new checks or levels.
The scope of the solution should not restrict its ability to adapt to different project needs and requirements.

By default, the solution should include a set of checks to verify the target architecture.
However, for projects that already have an established architecture governance process, users should have the flexibility to extend and customize the set of checks according to their specific needs.

Given the existence of various Static Code tools like Coverity and SonarQube that handle low-level checks like indentation and formatting, it would be redundant to implement those checks in the proposed solution.
Instead, the solution should focus on providing value through higher-level architectural checks and analysis.

Configurability

Configurability is a crucial aspect of the proposed solution, allowing users to tailor the system to their specific needs and environment.
The following configuration items can be supported:

Solution Mode: The solution should offer different modes of operation, and users can configure the preferred mode during the deployment stage. For example, it can be run as a standalone application or integrated into the CI/CD pipeline.
Path for Architecture Documents: Users should be able to specify the path to read architecture documents from offline UML design tools like OmniGraffle or Microsoft Visio.
Online UML Design Tool API: The solution can integrate with online UML design tools like Enterprise Architect, LucidChart, Draw.IO, PlantUML, or Gliffy.com. Users need to provide the API address to access and update architecture documents online.
Source Control Management System Configuration: The proposed solution should be able to integrate with version control systems like SVN or Git. Users will configure the settings to access code and configuration from these repositories.
Database Addresses for Data Layer Observation: Users should provide the addresses of databases to observe the data layer and perform analysis on database scripts and configurations.
CI/CD Tool Integration: The solution should seamlessly integrate with popular CI/CD tools like Jenkins or Bamboo. Configuration options should enable easy integration into the CI/CD pipeline for regular architecture assessment.
Report Plugins Configuration: Users should be able to configure report plugins, including their format and storage settings. This allows customization of the generated reports based on individual preferences and requirements.

By providing these configurability options, the proposed solution becomes versatile and adaptable, meeting the specific needs and workflows of different projects and organizations.

What I learned as a Delivery Manager while creating my product

Dima Nikulin — Mon, 29 Jan 2024 08:03:22 +0000

First, I began contemplating how to increase engagement with my open-source project. Why? Because:

Developers play a pivotal role in adopting and integrating your product into their projects.
Engaged developers, who have a positive experience with your product, can become influential advocates.
They are more likely to explore the extensibility options and customization capabilities of your product.
Furthermore, engaged developers can offer valuable feedback, suggestions, and bug reports.
Ultimately, they might actively participate in your product's open-source community, contributing code, reporting issues, and collaborating on its development.

Their contributions can expedite the pace of innovation, foster a sense of ownership and community, and trigger a network effect that entices more developers to get involved.

As a result, I decided to create an appealing README.

Create a Good Readme

It is the first thing that a visitor to your repository sees.
A good README serves as a comprehensive and accessible starting point for users and developers to engage with your project.

It should be able to convey what your project is capable of doing, how to install and work with the project, how to contribute, and more.
It also maintains structured information about the product and its implementation details.

To avoid overloading the main README, there are several child files created to provide additional details:

CodeDocumentation.md - Describes how to document the code.
CodeStyle.md - Describes the code style.
Constraints.md - Describes the solution constraints.
Dependencies.md - Describes the tools and libraries used for product development.
DependenciesOld.md - Describes the old tools and libraries that were used for product development.
FunctionalView.md - Shows and describes the functional view.
QualityAttributes.md - Describes the product's Quality Attributes.

Furthermore, my **README starts with the product logo.

Badges

The README then proceeds to badge chapters that prove helpful for developers. These sections include:

Common(Repository stars, contributors, followers, sponsors, and Twitter URL)
Release(Latest release version, release date, and number of downloads)
Code Statistics(Build flow status, GitHub commit activity, GitHub's latest commit, and CodeFactor.io status)
Issues and Pull Requests(GitHub issues, closed issues, pull requests, and closed pull requests)
Repository Statistics(GitHub top language, count of languages, and repository size)
Documentation(Roadmap, Discussions, License, and Main README)

There are three different types of badges based on their implementation approach:

Implemented by GitHub, displayed as: GitHub Badge
Implemented by img.shields.io, displayed as: Badge
Implemented by www.codefactor.io, displayed as: Badge

Quick Links

Following this, the README transitions to the Quick Links chapter.
Quick links within a README file play a crucial role as they offer convenient access to key sections, resources, or external references relevant to a project.
They act as navigation aids, enabling readers to swiftly navigate to specific parts of the README without the need for extensive scrolling or searching.
To enhance accessibility, I've added Quick Links for each main chapter in the README.

Capabilities and Description

The description of capabilities and the product's overview within a README file holds utmost importance.
It plays a critical role in effectively conveying the value, purpose, and unique selling points of your product.
This description aids users in comprehending what your product brings to the table, why it holds value, and whether it aligns with their requirements.
By presenting information that is both clear and compelling, you can draw in the right audience and increase the likelihood of user adoption and satisfaction.

Architecture Documentation

Subsequently, the README delves into the description of Architecture Documentation, encompassing the following chapters:

Software Architecture Requirements
Software Architecture Views
Tools, Libraries and Programming Languages
Licenses

For more detailed information, please refer to the designated section.

Code Style and Documentation

The README then proceeds to expound upon Code Style and Documentation.
The act of documenting code style and practices serves as a linchpin for maintaining consistency, upholding code quality, fostering collaboration, and ensuring the project's long-term maintainability.
It acts as a valuable resource for the development team, guaranteeing that the project's codebase retains organization, comprehensibility, and scalability.

Should you require further information, feel free to explore the section dedicated to Code Style and Documentation.

Implementation Status

Subsequently, I contemplated an effective means to monitor the coverage of requirements.
It was essential to establish a method for tracing and discerning which requirements had been covered and which ones remained unaddressed.
To tackle this, I formulated a table equipped with the following columns:

Implemented: This column denotes whether the requirement has been implemented, denoted as either "yes" or "no."
Feature ID: This serves as an identifier originating from the project's features.
Component: This field specifies the name of the corresponding component.
File Names: Here, the file names are enumerated where the implementation pertaining to the requirement can be located.
Description: This column furnishes a descriptive account of the functional requirement.

Contributing and Stay in Touch

In this section, I outline the various channels that individuals can utilize to contribute to the project's development.
This includes information on how one can actively participate and offer their assistance.

Definitions, Acronyms, Abbreviations

Lastly, I provide an explanation of Definitions, Acronyms, and Abbreviations.
Presented in a tabular format, this section comprises the following columns:

Number
Abbreviation or Acronym
Definition

Project Status Tracking

In a broader perspective, monitoring the project's status holds immense significance for a Delivery Manager.
This practice ensures the triumph of the project by overseeing factors such as risk management, resource allocation, effective communication, and the ability to make well-informed decisions across the entirety of the project's lifecycle.

GitHub Projects

GitHub Projects emerges as a tool dedicated to tracking project status in an online environment, seamlessly integrated into your GitHub profile.
Its user-friendly interface facilitates ease of use, and while it doesn't offer an extensive array of functions, it adeptly serves its purpose.
Allow me to present it

ProjectLibre

Despite the aforementioned options, the demand for a more sophisticated solution persisted.
In light of this, my preference leaned towards ProjectLibre.
The ProjectLibre software, designed for desktop usage, presents itself as a comprehensive and open-source project management system.
Positioned as a stand-alone substitute for Microsoft Project, ProjectLibre effectively addresses the intricate requirements I sought.

Despite its stature as a compact and cost-free application, ProjectLibre remarkably delivered everything essential for my needs.

Releasing the Code and Documentation

The release of the product is strategically planned to coincide with the readiness of a substantial portion of its functionality.
Whenever a segment of the product's functionality is deemed ready for release, the creation or updating of the release branch ensues.
This practice ensures that any added or updated product functionality is seamlessly integrated into the release branch.

Irrespective of adopting an incremental approach to the addition or update of product functions, it's pivotal to underscore that the resulting artifacts shall encompass the entirety of the product installation packages.
This holds true even when releasing relatively minor components of functionality.

In adherence to this approach, the ensuing artifacts are generated:

Documentation for the code, structured around doxy comments.
Installation packages for the latest versions of Windows, Mac, and Linux.

What I learned as a Software Developer while creating my product

Dima Nikulin — Tue, 28 Nov 2023 07:39:58 +0000

Code quality

Before creating the code, it is crucial to prioritize its quality.
It should be the foremost consideration in the development process.
To ensure code quality, we can utilize automated tools that help with code analysis.
However, it's important to note that automated tools may not cover all the necessary rules.
As a result, manual code review becomes essential to enforce coding standards.
Personally, I have dedicated significant time to code reviewing and checking for adherence to code style.
Additionally, I have employed Python to create additional code checks.
It is worth mentioning that not all rules can be checked automatically, requiring manual effort in certain cases.

Code documentation

"Now, hold on!" you might ask,
"Are we jumping straight into coding?"
My answer is a resounding "Nope".

Before embarking on the coding phase, it is vital to consider code documentation.
Since the FVA Software employs two programming languages, it is imperative to establish clear documentation rules for both C++ and Python.

Consequently, I have familiarized myself with documenting C++ code using Doxygen markdown and have gained proficiency in generating documentation based on Doxygen markdown.
It's quite remarkable how confident I am now in configuring Doxygen.

Implementation

Finally, we can proceed to the coding phase!
For the development of FVA Software, I have chosen the versatile QT library, which supports multiple operating systems such as Windows, macOS, and Linux Ubuntu.
Since the software requires a user interface (UI), I initially utilized QWidgets, including components like QWizard and QWizardPage.

However, I soon realized that employing QML would offer a more streamlined approach for UI implementation.
Therefore, my plan is to transition from QWidgets to QML.

I was pleasantly surprised by the ease of utilizing QT for creating a multimedia content player.
The flexibility of QT allows me to work with multiple UI languages.
To facilitate this, QT suggests using the following components:

Additionally, I discovered that working with SQLite using QT is remarkably straightforward.

However, I later made the decision to switch from SQLite to CSV for data storage.

As my project involves working with two programming languages, I needed to establish a means of integrating Python code into the C++ application.

Last but not least, I acquired knowledge on how to create a riff parser, adding another valuable capability to the project.

History of internal metadata formats

The history of internal metadata formats in FVA Software reveals the evolution of how the software stored and managed metadata.
Initially, the metadata was kept at the file system level inside the Photo Album.
Each folder in the Photo Album had two files: folderDescription.json and description.csv.

The folderDescription.json file stored information that was common to all files within a folder, such as
device ID, tags, people, place, and event.

On the other hand, description.csv was used to store information about files under a folder that had different internal metadata.
It had columns for

Name
Place
People
Device
WhoTook
Description
Scaner

However, this approach of storing metadata at the file system level had limitations in terms of flexibility and maintainability.
Adding or modifying a column in folderDescription.json or description.csv would require updating the entire photo album file system structure.

To address these limitations, the decision was made to move the folderDescription.json and description.csv files to an SQLite database.
The database schema was designed to store the same information as before.
During the import of new files to the photo album, the FVA software created SQL updates to the database.
These SQL updates were saved to be able to recreate the SQL at any time.
Although this approach improved flexibility and maintainability compared to the file system approach, merging folders in the photo album still caused significant changes in the SQL updates.

Finally, it was decided to consolidate all the information into a single CSV file for internal metadata.
This CSV file does not keep track of which folder a file is stored in, allowing for easier merging of folders without issues.
However, it results in some duplication of information since common information for all files in a folder is simply copied.

"And what did you learn?" you might ask.
The lesson learned is that before implementation, it is crucial to consider how easily you will maintain product changes.

The history of internal metadata formats in FVA Software demonstrates the importance of designing a system architecture that is flexible and maintainable from the start.

What I learned as an Application Architect while creating my product

Dima Nikulin — Tue, 19 Sep 2023 05:26:07 +0000

"Are you kidding?" you might ask. "Do such small applications require an architect to be involved?"
"Yes, yes, and yes!" I would answer.

Generally, architects create a huge document known as a Solution Architecture Document that includes everything.
Initially, I followed the same approach, but it turned out to be quite difficult to track changes due to the high frequency of modifications.
So, I decided to keep every note and document in the form of text files in MD format, like this one.
I also learned how to create attractive README.md files with the use of badges from shields, providing document structure and required chapters.

Requirements

I began my journey as an architect with requirements selection.
By selecting the right requirements, an architect can ensure that the software is designed to meet specific business goals and objectives, as well as technical and operational requirements.
This helps ensure that the software is scalable, maintainable and meets the needs of both the end-users and the stakeholders.
It's worth noting that my approach to selecting requirements differed from that of a product manager because I needed more technical requirements.
I divided architect requirements into four parts:

Constraints;
Assumptions;
Quality Attributes;
and Hardware requirements.

Constraints

Constraints are factors that limit the architect's ability to design and implement a software solution.
These factors may include technical, business, or organizational constraints that impact the development process.

I have listed them on the following page in the form of a table with the following columns:

Constraint - to describe the constraint itself;
Description - to provide more details about the constraint;
Business value - to indicate the business value of the constraint (High, Medium, or Low);
Architecture viewpoint - to indicate the resources required to implement the constraint (High, Medium, or Low).

Assumptions

Assumptions are statements made by the architect about the environment, conditions, or factors that are expected to be true for the software solution to function as intended.
These statements are made based on available information, but they are not necessarily proven to be true.

Assumptions are important to consider during requirements selection because they can impact the design and implementation of the software solution.
By identifying assumptions early in the development process, the architect can take steps to verify the assumptions and adjust the design as needed to ensure that the solution will function as intended.

Quality Attributes

Quality Attributes, also known as non-functional requirements, are the characteristics of a software solution that describe how well it performs in terms of its operation, maintenance, and evolution.
Quality attributes are not directly related to the functionality of the software, but rather to how well it meets certain standards or requirements.

Quality attributes are important to consider during requirements selection because they can impact the user experience, the cost of ownership, and the long-term success of the software solution.

The quality attributes are provided in the form of a table with the following columns:

Name: to describe the quality attribute
Description: to provide additional details about the quality attribute
Motivation: to explain the rationale for selecting the quality attribute
Measurable Metrics: to indicate the metrics used to measure whether the quality attribute has been achieved or not
Business Priorities: to indicate the business priorities for the quality attribute
Architecture Priorities: to indicate the architecture priorities for the quality attribute

Hardware requirements

Last but not least were hardware requirements.

Hardware requirements refer to the physical components, such as servers, storage devices, and networking equipment, that are necessary to support the software solution.
These requirements are based on the needs of the software and the expected workload or usage patterns.

It is important to consider hardware requirements during the architecture design phase to ensure that the solution is designed to work within the limitations and capabilities of the hardware that will be used to support it.

Software Architecture Views

Software architecture views are representations of different aspects of the software system that are designed to communicate specific information to different stakeholders.
They provide a structured way to organize and present information about the architecture of the software system.
By using software architecture views, architects can ensure that all stakeholders have a clear understanding of the system and its architecture, which can help to avoid misunderstandings and ensure that the system is designed to meet the needs of all stakeholders.

I created three Software architecture views:

Context view,
Functional view,
and Deployment view.

I used Mermaid.js as it is supported now by GitHub.

Context view

A Context view is a type of software architecture view that provides a high-level overview of the software system and its external environment.

It shows the relationships between the software system and its users, other systems, and external entities.

The Context view is useful for stakeholders who need a high-level understanding of the software system and its contexts, such as business analysts, project managers, or system owners.

Functional view

A Functional view is a type of software architecture view that focuses on the functional or behavioral aspects of the software system.
It describes the functional elements or components of the system and how they interact with each other to perform the desired tasks or functions.

The Functional view is useful for software architects, developers, and testers who need to understand the functional requirements of the system and how they are implemented.

Deployment view

A Deployment view is a type of software architecture view that describes how the software system is deployed or installed in the computing environment.
It shows the physical elements of the system, such as servers, networks, and storage devices, and how they are connected and configured to support the software system.

The Deployment view is useful for system administrators, operations teams, and infrastructure specialists who need to understand how the software system is deployed and managed in the computing environment.

Since the FVA Tool Set can be deployed using only one node and a few processes, I provided a simple text description for the Deployment view.

Tools, libraries and languages

At some point, I realized that I needed a better way to manage the various IDEs, UI and command line tools, libraries, and languages that I use.

Tools and libraries

I compiled a list of all the tools and libraries that I used for development and presented them in a table on the project's GitHub page.
The table includes the following columns:

Name the name of the tool/library,
Purpose: its intended purpose,
Version: the version I used,
License: the license it is distributed under,
Environment: the platform on which it can be run,
and Comment: any additional information I wanted to provide.

Initially, the list was much longer, but as some of the tools/libraries became outdated, I moved them to a separate table using the same format.
You can find the old dependencies list here.

Languages

I just used plain text to describe the programming languages the FVA Software uses.

Licenses

Undeniably, we should remember about licenses.
As FVA Software uses third-party tools and libraries, their respective licenses should be included in the code.
In addition, I had to create the FVA License and gained an understanding of what a license is and how to create one.

What I learned as a Subject Matter Expert while creating my product

Dima Nikulin — Mon, 01 May 2023 15:28:03 +0000

Multimedia IR systems

My first step in the role of an SME was getting to know what Multimedia Data is.
I started learning it as I understood that my whole photo album is Multimedia Data itself.

Then I realised that I need to use a solution to search for Multimedia Data - Multimedia IR systems.

However, there are many Multimedia IR systems, and it was a long way to select one of them to start searching more efficiently.
Thus, several Multimedia IR systems, that are present on the market and available for end users, were analyzed.

I described the process of analysis and comparison for Multimedia IR systems here.
Consequently, I was able to choose the most suitable system for me.

Metadata

A short usage of these systems gave me an understanding that Multimedia IR systems significantly rely on the metadata as a main information source that is used for a search following different criteria, like device, time, location, etc.

Therefore, the presence and consistency of metadata are very important for Multimedia IR systems to operate, as well as for other purposes, please see Three Cheers for Embedded Metadata for more details.

Working experience with one of those systems shows that search results might be incomplete or even incorrect due to inconsistent or not-existing metadata.
Metadata is usually kept inside each file as a header with a predefined format.
There are plenty of metadata formats like Exif, IPTC or XMP.

The reasons for incorrect and absent metadata are quite different - from not setting proper data on the device that takes photos to privacy issues.

This resource describes metadata importance in more detail and there is information about other reasons for incorrect and absent metadata.

Examples of incorrect search results

Let's consider two examples of incorrect search results.
In the first case, we tried to search for photos with existing Geo positions and to see them on a map.
A search returned four photos taken near Ghana, marked by a red circle.

In fact, nobody took photos near Ghana.

In the second case, we searched for photos taken in 2011.
We got one video that was recognized as March 2020, underlined in red.

The system has provided such results due to incorrect metadata.

Multimedia Organizers

That being the case, I understood that Multimedia IR systems are not so effective without other tools, often called Multimedia Organizers.

Usually, Multimedia Organizers provide automation for importing a new photo set into existing photo albums and it is not an implemented feature in Multimedia IR systems.
In addition, they might identify and address some issues that shall be fixed before a user starts searching data using the Multimedia IR systems.

Integration

Then I started studying Multimedia IR systems the FVA Tool Set shall integrate with.
Integration with offline Multimedia IR systems is implemented through integration with digiKam, and integration with online Multimedia IR systems is implemented through integration with Google Photos.

As Multimedia IR systems perform a search by certain criteria, based on multimedia metadata, the FVA Software shall be able to work with the same multimedia metadata to be integrated with Multimedia IR systems.

Integration with digiKam

For digiKam, I found that the Collections setting shall be used to define how it is configured to search through multimedia data.
Monitor the albums for external changes (requires restart) setting shall be enabled.
Taking into account this setting, digiKam will pick up external changes in the collection as soon as FVA Tool Set puts it in.

However, from the FVA Tool Set side, it is required to provide a possibility to configure storage in a way to be able to put multimedia data processed and to be integrated with digiKam.
Therefore, a separate UI screen shall be created to ask a user what storage location, digiKam should be used for incoming multimedia data.

For example, a directory C:\FVA is selected for Local Collections as shown in the picture above.
Therefore, when a user wants to integrate multimedia data after processing by FVA Tool Set, he/she shall be able to select the C:\FVA directory as a directory in UI to put the processed multimedia data in.

As soon as it is done, FVA Tool Set will put multimedia data into a selected directory and the Multimedia IR system will be able to search through it.

Integration with Google Photos

Integration with Google Photos is implemented in the same way.
First of all, it's worth noting that Google Photos shall be configured to be integrated with FVA Tool Set.
Thus, appropriate file types and folders shall be set up as in the figure below:

For example, Pictures and fromDevices directories are selected for the folder settings as shown above.
It means that when a user wants to integrate multimedia data after processing by FVA Tool Set, he/she shall be able to select the fromDevices or Pictures directory on the UI screen, as a directory to put processed multimedia data in.

As soon as it is done, FVA Tool Set will put multimedia data into a selected directory and Google Photos will be able to search through it as soon as it synchronizes multimedia data.

What I learned as a Product Manager while creating my product

Dima Nikulin — Fri, 03 Mar 2023 11:16:37 +0000

Design Thinking

The first product I was thinking about was "FVA Tool Set".
Subsequently, another product came to my mind. As a result, a Product Line came about.

"Hold on, you started from thinking of products, right?", - you will ask me.
"Nope, I started from... It was ages ago and a whole history is quite big. Being a developer, I started from coding".
"Was it a good idea to start from coding?", - you will ask me.
"Again no. I would have started from Design Thinking, if I was familiar with it."

Design Thinking is a process of preparation, which consists of seven stages of creating a product:

Empathize-who, goal, do Here you need to create an artifact called "Empathy Map" with a formula - who, goal, do;
Empathize-see, say, do, hear Here you need to create an artifact called "Empathy Map" with a formula - see, say, do, hear;
Empathize-think and feel Here you need to create an artifact called "Empathy Map" with a formula - think and feel;
Define: Problem Statement Here you need to describe a problem basing on the "Empathy Map";
Ideate Here you need to nave a list of raw ideas to explore.
There are also other stages not mentioned here.

High-level product documentation

Once I came up with product ideas to implement, I realized that a set of documentation artifacts to keep high-level product knowledge had to be established.

Value Propositions

The first artifact to consider was Value Proposition.
which has the following components:

Mapper for Products and Services to Customer Jobs;
Mapper for Gain creators to Gains;
Mapper for Pain relievers to Pains;
One Pager with Value Proposition.

Business Model Canvas

The next artifact was Business Model Canvas.
I downloaded a template here and filled in the following fields:

Key Partners to answer the questions: Who are the key partners? Who are the key suppliers?
Key Activities to answer the questions: What are the main tasks that the company must do well to deliver its value?
Key Resources to answer the questions: What are the most important physical, financial, intellectual or human recourses the company has?
Value Propositions to answer the questions: What value do we deliver to the customer? Which customer needs do we want to satisfy?
Customer Relationships to answer the questions: What type of relationship does each of the customer segments expect us to establish and maintain with them?
Channels to answer the questions: Which channels do our customer segments want to be reached through? How do we reach them now?
Customer Segments to answer the questions: Whom are we creating value for? Who are our most important customers?
Revenue Streams to answer the questions: What value are our customers willing to pay for? What do they currently pay for? How do they pay? How would they prefer to pay?
Cost Structure to answer the questions: Where do the costs come from?

Product Vision Board

The third artifact was Product Vision Board.
I downloaded a template here and filled in the following fields:

VISION to answer the questions: What is your purpose for creating the product? Which positive change should it bring about?
TARGET GROUP to answer the questions: Which market or market segment does the product address? Who are target customers and users?
NEEDS to answer the questions: What problem does the product solve? Which benefit does it provide?
PRODUCT to answer the questions: What kind of product is it? What makes it stand out? Is it feasible to develop the product?
BUSINESS GOALS to answer the questions: How is the product going to benefit the company? What are business goals?

Competitive Analysis Matrix

The last artifact in High-level product documentation was Competitive Analysis Matrix
I filled in the following rows for several products:

Vision with Goal and Target segment;
Marketing with Pricing and Unique value proposition;
End user support with Trainings, User guide and Help desk;
Features.

Product from user prospective

As soon as high-level product documentation was ready, I decided to go deeper with more detail from the user's point of view.

Persona

The first artifact I created was Persona
I downloaded a template here and filled in the following fields:

PICTURE & NAME to answer the questions: What does the persona look like? What is his/her name? I chose a realistic and plausible picture and name.
DETAILS to answer the questions: What are persona’s relevant characteristics and behaviors? I wrote in demographics, such as age, gender, occupation, and income; psychographics, including lifestyle, social class, and personality; and behavioral attributes like usage patterns, attitudes and brand loyalty.
GOAL to answer the questions: What problem does persona want to solve or which benefit does the character seek? Why would persona want to use or buy the product?

User Journey and User Scenarios

Then I tried to restore user way to achieve the goals.
And I came up with User Journey.

To show the value of the product, I created three user scenarios and posted them on YouTube. Please see the reference to watch them.

Stakeholders

Honestly, a bit later I realized that end users are not the only target audience for this product.
And next artifact - Stakeholders - came into sight.
It looks like a table with the following columns: Group, Stakeholder Role, Concerns, View.
Table rows contain as follows: End users, Suppliers and Team members.

Product requirements

Having defined everything from the user's point of view, I started thinking what exactly the product will implement.

Questionnaire

Having no clue what is important for the user and what is not, I created a questionnaire to clarify user needs.
It is a form to gather information on what capabilities, functions and scenarios are important.

Capabilities

Having gained an understanding of user needs, I started describing Capabilities
Literally, Capabilities describe key requirements.

Features

Having capability list defined, I started preparing features.
They represent significant, central functionality of the final system.
I put them into the table with the following columns: Name, Clarification, Business Value.
The feature set helped me to create a project plan and a road map.

Functional Requirements

Last but not least step in defining product behavior was a list of Functional Requirements, that define system detail behavior.
I settled them into the table with the following columns: Name, Architecture complexity, Business Value, Component, Phase, Feature ID.

Product development documents

Product Road Map

I believe, Product Road Map is the most important document for a product at the development stage.
I downloaded a template here and filled in the following fields and rows:

DATE with Release date or timeframe;
NAME with Name of new release;
GOAL with The benefit a product should provide;
FEATURES with High-level features necessary to meet the goal;
METRICS with Metrics to determine if the goal has been met. Columns there are the product different version.

On the top of that, it is quite convenient to keep an online roadmap.

Why I decided to create my photo organizer

Dima Nikulin — Sun, 12 Feb 2023 12:31:37 +0000

As a child, I used to flip through family photo album to see my relatives whom I had not seen in real life.

At that time we had film cameras only, so the number of photos was not so large.

Time has passed and currently, let's say, almost everyone owns a camera or a smartphone with a camera, or even both.
Given that, the size of my photo album increased significantly. However, I think it's not just for me.

Once my friend and me decided to recall an event we both attended. We took my photo album and tried to search there.
That time my album kept more than 30 thousand items inside. That search process looked like

Of course, we didn't find anything. Therefore, I started looking for a solution to be able to search in Multimedia Data in an automatic way.
The solution I found were Multimedia IR systems.

I decided to use digiKam as Offline Multimedia IR systems
and Synology Moments as Online Multimedia IR systems.
Please note, that they were selected solely based on author's criteria, and there is no aim to advertise anyone.

Then I started using it...

What I discovered in a flash is that current Multimedia IR systems do not provide a flexible and automated functionality to import Multimedia Data into Multimedia IR systems.

But that wasn't the only problem.

I realized that I need Multimedia Organizer as well.
Unfortunately, I didn't find a Multimedia Organizer that could fully satisfy my needs (fixing problem metadata, working with digiKam and Synology etc.)
That's why I started creating my own product to cover my needs.

Honestly, I didn't expect that it would be so hard and in the meantime so interesting.

What are the Photo Organizers?

Dima Nikulin — Sun, 18 Sep 2022 14:16:59 +0000

Multimedia Organizers functions

They currently perform the search in photo set by organizing the photos based on their date, location, categories, etc.;
They suggest to create a folder structure and put the files on it;
They make automation for the import of the new photos into IR Multimedia Systems.

Also they make photo albums more searchable (that is driven by IR Multimedia Systems) by enriching the metadata (and improving its consistency) with minimal human involvement.

Therefore, they are chosen as a subject for the overview and comparison.
This provides the list of Photo Organizers for professional photographers and those organizers can be used by a usual user with a big photo album.
There are even relevant online courses available to guide the user how to organize the photos.
The more detailed comparison of photo organizers is provided by Wikipedia and available here.

Multimedia Organizer requirements

They shall be able to identify of inconsistent or not existing photo metadata;
They shall be able to suggest the ways to solve the inconsistency and absence;
The most automated approach possible should be used because a user is going to work with a large number of items;
A toolset available for a usual user and not for the enterprises shall be used as well.
They shall provide integration with such Multimedia IR Systems like digiKam and Synology Moments.

Multimedia Organizer approaches to create folder structure

The idea is to avoid photos having the same file name in the folder.
The folder name can be something like Date_Shoot-Type_Event Name;
It can also include a location or any other information the user wants;
In such a way the user can create subfolders based on the number of photographers or cameras;