Tjen Wellens

Tjen Wellens

"All models are wrong, but some are useful"

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

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


Published by Tjen Wellens on

comments powered by Disqus