Skip to content

Don’t be penny wise and pound foolish!

The Real Cost of a Software Project

What is the most expensive part of producing a Software System or even releasing a single feature into Production?  Is it in the infrastructure costs? In reality those tend to be a very small fraction of the overall cost of a software project.

The obvious answer is no doubt what you would expect, it’s in the Development Team. 
To be explicit, the primary cost of software is in the developers.

Why Not the Operational Expenses?

Infrastructure for on-prem or cloud-hosted projects is usually between 5-10% of development costs for a single system. For a million-dollar project that takes 9 months to build, the infrastructure costs and physical resources would be between $50,000 and $100,000. 

Of course, there are on-going costs after initial development is complete. Software is never done. Feature enhancements, bug fixes, upgrades, etc. still require developers, QA, and Project Managers to facilitate those changes. Therefore, the cost of developers exceeds the operational costs of the technologies.

Why Should We Care?

Why do the vast majority of Architecture diagrams always seem to depict the system by the technologies?  These diagrams often show cloud hosted Web Services, Storage Services, Message Brokers, Databases, Web Clients, Web APIs, micro-services. This happens so much it has become known as Technology Masquerading as Architecture.

So why should we care?  

If 90-95% of the cost of a software project is in the development, why don’t we have a mandate to always document the application Architecture? 

If this is where the cost is, we shouldn’t fund or start a project without a roadmap for the development team to follow.  We need blueprints for the code and a plan for how it will be assembled.

We Must Have an Application Architecture

The application architecture should include a static diagram showing the decomposition into components or services. 

It should include: 

  • A set of interaction diagrams depicting how the components must interact to satisfy the business use cases. 
  • A diagram showing the process boundaries or sub-systems, the authorization boundaries and authentication boundaries. 
  • The technologies as components that the code will interact with.

A Fighting Chance

The right System Design documented by the Architecture is what gives us a fighting chance against the overwhelming complexities that come with hundreds of business use cases. A key benefit the application architecture provides is a dependency graph of the components. These dependencies help us to define the order the components need to be built to assemble them into deployable features most efficiently.

Don’t be penny wise and pound foolish. Have a skilled Architect design your systems. Doing so will save you both time and money on every software project.

For tools that will help you with your projects today, download my e-book.

Have a question or need a Skilled Architect, email: [email protected]