Opinion: better process to extract a service from big-ball-of-mud

November 24th, 2020

For the context about what actually happened, see Case study: extract a service from big-ball-of-mud

 

Per client application (3 of them)

  1. Refactor to module

  2. Refactor to library

  3. Change to use our service (with fallback and throttle)

We would collaborate here for step 3, maybe even be involved in the earlier steps so we get to know the code base.

 

Our service

  1. .

  2. .

  3. Simplest service possible + client library

  4. Continue developing our service

  5. ...

  6. ...

  7. System is 'done enough to use' in Case study: extract a service from big-ball-of-mud

 

Benefit - deliver value sooner

Starting in step 4 we can start providing value, instead of waaay later (step 6)

 

Benefit - faster feedback

We get usage feedback of the 3 services faster.

We get feedback from users in step 4

 

Benefit - less guessing / over-engineering

When there is no feedback, we need to guess.

 

Benefit - faster iteration of endpoint / breaking changes

This would create 3 interface points.

client-service <-> client-service-extracted-library <-> api-library <-> api

Our team would take full ownership of

  • api

  • api-library

Client team would keep full ownership of:

  • client-service

We would collaborate on:

  • client-service-extracted-library

 

This would allow us to iterate faster on the api endpoints, allowing us to introduce backwards-incompatible changes.

As long as the api-library interface remains stable (or backwards compatible), nothing needs to change.

If we need to make changes in the client-service-extracted-library, we could easily collaborate on that.

As it was (in Case study: extract a service from big-ball-of-mud), we could not really collaborate well on the integration part. We needed to 'dive in' a service we knew nothing about, with a very big scope. That's complex and hard to do, so we were less likely to actively collaborate.

 

Benefit - start sooner

We could start sooner because we would need less analysis.

In Case study: extract a service from big-ball-of-mud we needed analysis to understand what was going on.

Then needed analysis to see the big picture of where we wanted to go.

In the new way of working, all this could be postponed, more like lean's just-in-time.

 

 

Inspiration

 

 

This post was referenced in: