Improving time to market with software modernization. Legacy Garage 3

00:00 → 00:02

Business and change are tightly linked.

00:02 → 00:06

Every company that wants to stay competitive needs to adapt

00:06 → 00:07

to changing market needs.

00:07 → 00:10

But implementing new features always runs the risk of slowing

00:10 → 00:13

time to market, especially when it comes to complex products.

00:13 → 00:16

These delays aren't always caused by the technical side

00:16 → 00:18

of product development.

00:18 → 00:22

Watch the video and see how you can improve your time to market.

00:34 → 00:37

I'm Slawek, Senior Project Manager at Merixstudio.

00:37 → 00:40

And I'm Andrzej, Software Architect at Merixstudio.

00:40 → 00:43

In this series, we present different ways of dealing with the most common

00:43 → 00:45

challenges of software modernization.

00:45 → 00:49

We draw on our experience and present solutions based

00:49 → 00:51

on the example of one product.

00:51 → 00:55

In this episode, we're going to focus on the example of Sweden

00:55 → 00:58

based company that created software for booking fitness

00:58 → 01:01

classes and personal training sessions.

01:01 → 01:03

At least that was the core service in the beginning.

01:03 → 01:07

However, this business model quickly evolved as the company

01:07 → 01:09

branched out into other sports.

01:09 → 01:13

As a result, user gained the possibility to book football

01:13 → 01:16

grounds or even swimming pool lines.

01:16 → 01:20

They were also able to scroll through training schedules and

01:20 → 01:22

pay fitness club memberships.

01:22 → 01:26

But the company is still growing and expanding its audience.

01:26 → 01:29

Now, there are a few different target groups and they are

01:29 → 01:32

not limited only to sports.

01:32 → 01:35

The client also focuses on education,

01:35 → 01:40

so users are able to book math or violin classes through the app.

01:40 → 01:41

As you can imagine,

01:41 → 01:45

extending the target audience and adding new functionalities

01:45 → 01:48

slowed down time to market.

01:48 → 01:49

How to improve it?

01:49 → 01:52

Let's take a look under the hood and find out.

01:52 → 01:56

First of all, there are some major issues on the technical side that need to be fixed.

01:56 → 01:58

The company's team is working with outdated libraries.

01:58 → 02:01

The overall code quality is low because every development team

02:01 → 02:03

that worked on it followed different standards.

02:03 → 02:05

Or sometimes, no standards at all.

02:05 → 02:07

The application is based on various modules.

02:07 → 02:10

For example, we have a module responsible for room reservation and

02:10 → 02:12

another one that allows scheduling a lesson with an

02:12 → 02:14

instruction in a room.

02:14 → 02:17

In reality, these two functionalities overlap and create a lot of

02:17 → 02:18

complexity on the backend side.

02:18 → 02:21

It also takes a lot of time to develop such components,

02:21 → 02:23

because the technical requirements set by the company

02:23 → 02:25

are not in line with the latest technological solutions

02:25 → 02:26

available on the market.

02:26 → 02:30

The company tried to migrate to the cloud to compensate for growing traffic.

02:30 → 02:32

The team on the client side did their best,

02:32 → 02:34

but the created AWS infrastructure was simplistic,

02:34 → 02:36

manual, and fragile.

02:36 → 02:40

The technical issues aren't the only ones to increase time to market.

02:40 → 02:44

The development process is another reason.

02:44 → 02:47

Firstly, there is no quality assurance involved in the product

02:47 → 02:49

development process.

02:49 → 02:51

There are no continuous integration or deployment

02:51 → 02:54

pipelines created for the project.

02:54 → 02:58

All the bugs need to be spotted by the development team

02:58 → 03:01

or unfortunately by the client.

03:01 → 03:05

As you can imagine, this significantly extends the

03:05 → 03:08

implementation time for new functionalities and poses a

03:08 → 03:10

high risk of progression.

03:10 → 03:13

The company started working on this project with a few

03:13 → 03:14

different contractors.

03:14 → 03:17

The cooperation was based on a team augmentation model,

03:17 → 03:21

which is a flexible outsourcing strategy that helps companies

03:21 → 03:23

add skilled professionals to their teams.

03:23 → 03:26

In the beginning, it functioned pretty well.

03:26 → 03:29

But as the months and years passed by,

03:29 → 03:33

the company was scaling up and adding new functionalities.

03:33 → 03:37

It opened itself to new branches of business just

03:37 → 03:39

like we've mentioned before.

03:39 → 03:43

Right now, the specialists on the company side are

03:43 → 03:46

responsible for organizing workflow, setting

03:46 → 03:49

requirements, and keeping the documentation up to date.

03:49 → 03:52

This workflow has become ineffective.

03:52 → 03:56

Moreover, it extends the development process as well as

03:56 → 03:59

the approval of changes and corrections.

03:59 → 04:02

Another problem is the cooperation model adopted by

04:02 → 04:05

the company and the various contractors.

04:05 → 04:08

They work independently, often without communication

04:08 → 04:10

between each other.

04:10 → 04:13

Sometimes, they even develop functionalities that had

04:13 → 04:14

different requirements,

04:14 → 04:17

but in the end turned out to be the same feature.

04:17 → 04:19

As you can imagine,

04:19 → 04:21

it significantly extended the time to market.

04:21 → 04:25

Lastly, there is no CI in the process.

04:25 → 04:30

The CI is crucial as it reduces human errors.

04:30 → 04:33

With proper setup, it ensures both our partner and the

04:33 → 04:37

team that the new version is stable and ready

04:37 → 04:39

to be served to customers.

04:39 → 04:41

So what can we do in this case?

04:41 → 04:43

Let's start with technological solutions.

04:43 → 04:46

At the very beginning, we need to go through, as we call it,

04:46 → 04:47

an adjustment phase.

04:47 → 04:50

The goal is to adjust the code quality and development tools

04:50 → 04:53

to our daily standards before starting any development.

04:53 → 04:55

A high quality base is fundamental for efficient work

04:55 → 04:57

and predictable delivery.

04:57 → 05:00

We distinguish three main areas for adjustment: development,

05:00 → 05:01

deployment and infrastructure.

05:01 → 05:04

Development improvements focus on reducing technical depth.

05:04 → 05:08

We update frameworks and libraries and remove obsolete elements.

05:08 → 05:12

Then, we ensure high code quality by using code verification tools,

05:12 → 05:14

automated APIs, and end to end tests.

05:14 → 05:17

It's an investment upfront that will ease the development,

05:17 → 05:19

making it more fluent in the future.

05:19 → 05:22

Next, we use a containerization approach for development and deployment.

05:22 → 05:23

Why do we do that?

05:23 → 05:26

To have a consistent environment on the developer's

05:26 → 05:28

machine and during the verifications.

05:28 → 05:31

We want to ensure that the same application version finally

05:31 → 05:32

lands on the production server.

05:32 → 05:34

The continuous integration pipeline is responsible for

05:34 → 05:37

packaging the code source into a container after each change

05:37 → 05:38

in the application.

05:38 → 05:41

Then, it runs a complete set of automated tests and

05:41 → 05:42

verifications on it.

05:42 → 05:45

Finally, the CI pipeline completes the checklist marking the package

05:45 → 05:47

as healthy and deliverable.

05:47 → 05:50

The next step we take to improve time to market is the

05:50 → 05:52

introduction of automated release management.

05:52 → 05:53

At the end of every sprint,

05:53 → 05:56

have an increment to be released as a new version.

05:56 → 05:58

The only thing that we need to do manually is to define the

05:58 → 05:59

application version.

05:59 → 06:03

The rest is done by an automated continuous deployment pipeline.

06:03 → 06:06

You click the button, mark the version and it runs.

06:06 → 06:08

What's more, we don't need to have a microservices architecture for

06:08 → 06:10

implementing this workflow.

06:10 → 06:13

The key is a well organized team that will handle this when

06:13 → 06:14

working with a monolith.

06:14 → 06:15

As I mentioned before,

06:15 → 06:18

the company has already tried to implement AWS infrastructure,

06:18 → 06:21

but it was done manually without any automation whatsoever.

06:21 → 06:24

It means we need to prepare the new architecture from scratch.

06:24 → 06:27

So now we define environments in the Terraform.

06:27 → 06:29

It allows us to keep track of every change using

06:29 → 06:31

infrastructure as a code approach,

06:31 → 06:34

as well as control multiple environments and versions.

06:34 → 06:37

The services powering the environments enable us to scale

06:37 → 06:38

based on future needs.

06:38 → 06:41

Integration with the cloud provides plenty of services

06:41 → 06:44

that can cover new requirements and speed up time to market.

06:44 → 06:48

Okay. Let's move on to the project management solutions.

06:48 → 06:51

We can streamline the product development process by

06:51 → 06:56

adjusting the cooperation model to changing product needs.

06:56 → 06:59

We conduct a workshop sessions to present the new approach

06:59 → 07:02

that will be more beneficial for the project and

07:02 → 07:05

significantly improve the time to market.

07:05 → 07:09

The company sees an opportunity in treating treating us

07:09 → 07:10

as technological partner.

07:10 → 07:12

What does it mean?

07:12 → 07:16

Firstly, by including our project manager in the process,

07:16 → 07:20

the client doesn't need to care for the entire workflow.

07:20 → 07:23

Instead, they can spend more time focusing on possible

07:23 → 07:24

app improvements.

07:24 → 07:29

Secondly, with our expertise in technology field,

07:29 → 07:33

we know how to choose processes and solutions to bring these

07:33 → 07:34

ideas to life.

07:34 → 07:38

Now, we can utilize our capabilities and focus group

07:38 → 07:42

development efforts on smaller end customers deliverables.

07:43 → 07:46

It's all about presenting a constant and predictable

07:46 → 07:51

pace, moving towards more significant milestones.

07:51 → 07:56

Previously, the team worked on a module like on a different version of the application.

07:56 → 08:00

It resulted in many conflicts with other similar modules,

08:00 → 08:04

extending delivery time and jeopardizing the quality of the platform.

08:04 → 08:06

In this model of cooperation,

08:06 → 08:11

a technological partner is not focused only on the execution of the plan.

08:11 → 08:14

The external team is also involved in the refining

08:14 → 08:18

requirements and ideas or even just visions

08:18 → 08:20

of the new functionalities.

08:20 → 08:21

Therefore, at this step,

08:21 → 08:24

we start verifying the product's direction with end

08:24 → 08:27

users before any development starts.

08:27 → 08:31

This approach emphasizes well suited solutions and eliminates

08:31 → 08:34

significant amendments after releasing the increment.

08:34 → 08:39

Of course, it translates into shortening the actual delivery time.

08:39 → 08:41

Besides the project management,

08:41 → 08:44

another important change is the introduction of quality

08:44 → 08:46

assurance specialists role.

08:46 → 08:47

Thanks for watching.

08:47 → 08:49

If you like this video and want to know more about software

08:49 → 08:51

modernization, visit our insights.