What is the Level of your Tech Start-up? Part 2/3. Software Business Architecture

Published in

AI for Software Engineering

6 min readOct 22, 2019

This article is a part of a Series “What is the Level of your Tech Start-up?”. It consists of three Articles, aimed to define and describe two main Viewpoints when creating new Tech Company: Technical and Business, and how they combine together.

Intro

Although the name suggests applying this Approach to Start-ups, it can be used by existing companies, which have been operating in the field for a long time. It’s great to use this Vision when searching for new development opportunities.

The Series itself contains the following Articles, which are recommended to read in the provided order (as it usually goes with tech teams — from technology to business):

Initially, it was decided to share the Insights related specifically to how the Software Technical Architecture Layers intersect with the Marketing/ Sales Opportunities, which developed applications should have. But later on, it became clear that the entire topic shall be split into smaller chunks, making it easier to perceive, going step by step.

The Software Technical Architecture Layers presented in the first Article are inspired by Domain-driven Development (DDD), Clean Architecture and Hexagonal Architecture.

The Software Business Architecture Layers were identified in an analogous way following the same common principles (“coupling and cohesion”) — this is described in detail in this article.

But for sure the most interesting results come in the combined 3rd Part — What is the Level of your Tech Start-up? Part 3/3. Software Business vs Technical Architecture.

This Article has two Sections:

Software Business Architecture Diagram, AIFORSE Edition — the resulting diagram itself
Notes to the Diagram — if you feel you’re good at reading diagrams, or you want to use it as is w/o any extra justifications behind it, you can undoubtedly skip this section

The Article doesn’t really have any links to external sources or references as the vision provided here is a completely new thing concluded from the Software Technical Architecture when looking at the Software from the Business Point of View. (Though I admit I might be not the first in the world who invented this, so if you saw something similar to this, please share.)

Software Business Architecture Diagram, AIFORSE Edition

Notes to the Diagram

General Information

One can think of a dozen benefits looking at things through such kind of a prism, but let me stress out the main points which motivated me to work out such an approach.

Whether you want this or not, eventually your Software Solution will fall into at least one of the identified levels. So it’s nice to understand the peculiarities of a specific level — to not mix things and to not end up with a messy business model which nobody knows how to use (neither your investors nor your customers).
(We are not talking here about software development as the outsource/ outstaff business models — that might be considered in more details decomposing AIFORSE Framework Process Map)
One of the most common mistakes for technology startups — brilliant engineers provide Technical Solutions not knowing the specific Business Problems they’re trying to solve. This is just another angle of view — the same important as the technological one — before starting developing something to understand who, why and how will use your solution. If you’d like, you can call this the “top-down approach” in defining Technical Solutions.
(And I would add that such approach is the only possible and viable when creating Business Solutions; we’re not talking here about fundamental researches and inventions)
Prove of Concept — your Start-Up’s superpower. Test hypothesizes as fast as possible with as little efforts as you can. Start from the basics. Evolve gradually. Look for upstream/ downstream/ side partners.
(Yeah, a bit generic, but look at the diagram one more time a bit more precisely)

Main Principle laying in the core of this Approach

Higher Level acquires Lower Level, adding extra ‘component’, and overriding the monetization options.

Keep in mind that each and every Level has its own implications on the Business side of your Software Solution:

Sales/ Marketing Strategies
Customer Types (B2B/ B2C etc.)
Partnership Capabilities
Sales Units (licenses, subscriptions, system integration services, etc.)
and many more.

Software Business Architecture Levels

Level -1 - Infrastructure. This level a bit falls out of the general approach, but it’s kept within the model on the specific purpose. It covers a separate business model, which actually goes beyond the creation of Software Solutions. It’s “Data Storage as a Service” Solutions. As standing out, it’s not considered in detail in the provided Business Architecture Model.
Example: Any known DBaaS Solutions.

Level 0 - Domain Model. This is the core of your Software Business as it defines how well exactly from the business point of view you know about the domain you solve a problem in or for. It’s highly recommended to separate domains and related to them problems into chunks as small and independent as possible, where each can be identified as an Atomic Business Function. And at this Level, all you have is just a Model of such a Business Function. Unless you sell (or provide access) to empty Domain Models and Definitions of Business Rules (with no actual data or implementations), chances are low to monetize this.
Example: Any known Industry Standardization Domain Models and Processes, e.g. in Telecommunications.

Level 1 - Implementation. This is the best Level to start your proof of concept with. This Level provides the specific implementation of a previously defined specific Domain Model, bringing one specific Business Function Item already capable of solving real-world tasks. Basically, it’s a source code, which can be used under either of the licenses, not yet providing anything else on top of this. If your code is really good as is — charge the license fee for it.
Example: Any known libraries under MIT/ GPL/ etc. License.

Level 2 - Application. If you know how to turn your source code into a solution to cover one specific Business Function, providing at the same time access to corresponding Domain-specific Data (even if this is customer’s data) — it’s your bet. Write your SDK and charge for a number of requests (other options are available as well).
Example: Any known Maps/ Directories Services APIs.

Level 3 - Solution. If besides ‘what’ you know ‘why’ the Business uses the Software you provide, if you know the specific Business Cases which stand behind this — it’s time to grow one level more. This usually requires to efficiently combine several Business Functions into a single Solution. Having this, sell subscriptions, or even build a Marketplace or a Platform.
Examples: Any known SaaS Solution.

Level 4 - Professional Services. If you’re experienced enough so you can provide really custom solutions to your customers, enhancing your software with your valuable expertise and specific integrations and adaptations — then you’re lucky to work at the top-end of the software evolution ladder. Though it worth saying it’s not always the best ever option to sell your software.
Example: Any known Enterprise Solutions Delivery Projects, e.g. in Finance.

Bonus

There’re a lot of criteria, which define your Software Business, and very often it’s hard to find our place in the market (not saying how hard it’s to find the market itself). To navigate in this a bit better, consider looking at the diagram side notes, expressed in a kind of ascending (on the left) and descending (on the right) axes. The ‘higher level’ you Software is at, you will face both more pros (higher revenue, the value of reputation, etc.) and cons (lower time to market and higher customer acquisition costs), and vice versa (higher agility and competition). Check the Diagram above for more criteria.

Summary

The provided Software Business Architecture Diagram, AIFORSE Edition, concludes a holistic, concise and at the same time easy-to-use methodology to identify what your software business is about.

Create better software better!