Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

What Is Your Model of Software Company?

DZone's Guide to

What Is Your Model of Software Company?

You've probably heard the phrase, every company wants to be a software company. But, what types of software companies are there?

· Agile Zone ·
Free Resource

The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.

Hi everyone!

In this post, I just wanted to share with you a simple but important thought. What exactly is the model for your software company or the software company you are working for?

I think there are many models and sub-models defined by business super-executives from Business Schools. That's the dark side. From the geek perspective, the models probably look slightly different.

We'll consider five main categories, as shown in the graphic below:

Image titleTypes of

The categories are very basic and easy to describe.

Technology Creators are the companies that actually are making new programming languages, platforms, OSs, etc. There are only a few cases of this, though.

Technology Assemblers use existing technologies to develop something new, even a new type of technology (e.g. by using an extending programming language to create utilities, tools, etc.) This case is more commonly found.

The Creator of products and services are companies that deliver software elements based on existing assemblies, focusing on performance, resilience, extensibility, scalability, and maintenance.

Software Factories are basically an attempt to industrialize the production of software. The level of innovation is very low or null while the average skills level here is usually quite low.

At last, the "Last Mile" Actor is the company that is a good buyer. That means that they prefer to buy a pre-assembled product or service to develop something new.

To illustrate these categories I've chosen a very basic analogy to go through how each of them can solve a problem. It will be fun (because of obvious reasons we'll ignore the Software Factory Model)!

Firstly, we have some requirements from an undefined customer. Here we go!

This is the list of requirements:

  1. We need to cover humans from rain, sun, wind, and other atmospheric events.

  2. The object to be built should be strong enough to not fall down because of the wind or the terrain conditions.

  3. Some light in the interior of the object is required. The object should have some open holes in the walls, for example. However, these holes should be covered with some kind of transparent material. They can be opened and closed.

  4. Humans in the structure should be able to get some heat by using a device to warm the structure.

Right, let's do it! We have four main options to meet these requirements.

Model 1 (Creator). We'll make our bricks, doors, and windows. Well, we'll basically need a very skilled and experienced architect as well as people with the skills to build these elements from basic materials. We investigate the types of sands, types of concrete, and materials in general.

Model 2 (Assembler). We'll buy bricks, tiles, doors, and windows. We'll still need a pretty skilled architect, however. We'll need people with strong skills when it comes to building walls, mounting doors, windows, etc., as well. It is not that difficult but can be hard without the proper people. Moreover, there are many types of bricks! We need to predict what are the best ones to be successful.

Model 3 (Product/Service Creator). We'll buy ready-made elements. Whole walls, panels, etc. with pre-embedded doors and windows. Naturally, bricks can be set in many different ways. So, we need to carefully choose what walls, roof panels, doors, and windows we'll buy. We won't need a very skilled architect as we have a simple plan.

Model 4 (Last Mile Actor). We'll buy a house to re-sell to our customer. All we need here is a guy seeing catalogs of products with simple tests.

Some important questions can be derived from these categories.

  1. What are the benefits of each model?

  2. What is the minimal investment for each model?

  3. How are we conditioned by the job market?

  4. What is the cost?

From my very personal point of view as a geek, I always prefer to work for a software company that is creating technology. Though, this is often not the case. The second model is amazing as well. By investigating new products, languages, and trends we can also create new ways of developing software.

The flexibility, quality, production costs, time to market, the long-term viability of the company and other factors vary from one model to another. Moreover, we could say that the same company uses two or more models at the same time.

Anyway, the funny thing happens when a new requirement is received:

  • We now need to make the object capable of holding 10 to 20 humans.

  • Heating devices should be scaled to warm the structure as it grows.

I am afraid the buyer model has a serious problem now. They probably need to convince their customer to buy a different house.

The assembler model depends entirely on their staff. If they hired poorly skilled people they are in troubles.

In the meantime, new requirements have been received:

  • We need an object, close to the previous one, to host cows.

  • It should have at least 20 feed stalls.

  • It should have an open sewer system.

I am afraid model 3 is now running into some difficulties. But it is actually model 4 which is out of the game.

My question is, which is the model with a better adaptation to these changing requirements? 

Unfortunately, most software companies are mere Last Mile Actors and many times even simple buyers. This is frequent in the case of IT departments, for instance.

Staff in Last Mile companies usually do not think in a proactive way. I swear I've heard them at least a couple of times from guys with some kind of responsibility in a software company:

We do not want to re-invent the wheel.

What?! If we had not re-invented the wheel millions of times in history, we would still have stone wheels! We need to ask questions about any pre-conceived paradigm or idea, investigate and innovate about what is supposed to be unimprovable. This is the very basis of scientific thinking.

Look at what I can do with this expensive tool.

Well, I like your expensive all-is-in-a-box set of dashboards or whatever. Impressive. This is the typical buyer that actually hates innovation. He is the man in the middle who earns a small amount of money because, well, he is in the middle! Business people will notice sooner or later that they do not need him to use software products with a decent support in the market - they can just use it on their own.

This is not in the requirements.

By being strictly glued to the requirements we'll never evolve or create anything new. Besides, business wants you to provide some help to improve their tools and scope by using technology! Given that most business people are not techies, we need to talk to the business side of things about the technological options and how they can evolve, improve, and create new businesses and opportunities from technical innovations. This is important because the guys constraining their work to requirements are actually glued to the low-level employee perspective, more worried about their daily small task than general strategies or improving workflow and products. The real business high-level thinkers/managers usually are open to innovation and new ideas from geeks.

We only use well-tested technology.

This is very related to the buyer model. Actually, he is saying he hates innovation and prefers working in the comfort threshold (e.g. the Spring stack). It is bad, it is slow, poorly adaptable to scalable systems, but, well, it is the most used. What else? Do not be surprised when business people say to you that your systems are slow and weak and they are looking for new options in other companies. Thanks and goodbye!

Our innovation is functional, not technological.

Honestly, I do not understand this. If the innovation is not technological, what the hell are we doing with it? We deliver software for goodness sake! Basically, functional innovation is not our field. It is just another example of Post-Truth. If you say a lie enough times, it will become true. This paradigm usually holds true as well in buyer and assembler models.

Wrapping Up

Well, this is more or less my analogy. My point is that software development is intellectual work and production processes should be strictly coupled to this principle. The model you choose for your software company or your work as an employee in a software company will open your business opportunities beyond your plans or it will drive you to bankruptcy and boredom in a few years.

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap, brought to you in partnership with Techtown Training

Topics:
agile ,devlife ,software development process ,development culture

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}