How Do Enterprise-Level Software Projects Start?

Enterprise-level application development process overview

  1. How do enterprise-level software projects start?
  2. How do enterprise-level applications development processes work?
  3. Code collaboration, testing, releases and support on enterprise projects

Intro

Multiple times I had questions about the software development process, how it looks, how it starts, which roles are involved, how do they sync and divide responsibilities, how the code goes to production, and more. Such questions were coming from different people outside tech, junior developers, and development team members including managers in small companies who never worked in an enterprise-level corporate environment. That is why I decided to cover this topic based on my experience here.

How do enterprise-level software projects start?

If to talk about the development of enterprise-level application this always means an existing mature business that in most of the cases has already some small or big, new or obsolete system that needs to be upgraded or completely thrown away and replaced by the modern one.

In the case of a mature business, there should be already existing business processes that somehow work with or without software automation.

So, in the beginning, to start such development there should be a business need that should be defined on the management level. They should estimate the gain size which will be after implementation of such software and prioritize needs they want.

When management defines goals, in most of the cases business analysts join the process to analyze business needs in the detail and create business requirements.

After high-level business requirements are defined the company may start looking for a software architect to work on high-level software architecture and estimates to be able to count how many engineering working hours are needed as well as testing effort.

So then, depending on the urgency of business needs, management may decide to have one or many squads in the team and which team composition will feel the best to implement required changes in time.

In this phase, companies starting looking to hire new people or vendors to cover gaps for resources, knowledge, or expertise that will be needed to cover the estimated work. Both may be found in the home country or in popular outsourcing locations with lots of talented engineers which in most cases may cost less than locals.

The company may try to make new hires with their own recruitment team or ask for help from recruitment companies which in most of the cases already have a database with people who may fit the position or at least have a network.

Recruitment companies may be really suitable to speed up hires especially when the market is very competitive. Recruitment companies usually work for interest from the salary of people who are hired, for example, 50% of monthly salary when hired and 50% of salary after 3 months, this depends on country and requirements.

Vendors may be chosen for outsourcing or outstaffing, basically, outstaffing provides people, outsourcing provides solutions. With outstaffing, the business can quickly get the required team members and omit to focus on hires. With outsourcing, the business can delegate the responsibility of team creation, composition, management, and implementation on the vendor and just control results. With an outstaffing model, the business will know each team member in person, while the outsourcing model teams will be hidden under the vendor's manager or team leads. Outsourcing may work on a time and material basis or fixed costs by the project or milestones.

After the company has confidence in requirements, architecture, and development team capacity, the business starts planing the frequency of releases for subsystems, features, and upgrades that should be implemented and deployed to production servers.

To get to this point above actions may take from months up to years depending on how big the business is and how many bureaucratic processes are involved in decision making.

At this point, at least part of the requirements should be defined in detail for the development team to start working on.