The development life cycles of applications in an enterprise environment often follow a common theme. An application begins life with a clear purpose in mind and over time has requirements brought in that cause incremental additions to the scope of the original concept. These additions could either be completely in sync with the original concept or perhaps the requirement just had no better home to belong in. As the application matures to an end-of-life state it has now grown far past its original intended purpose and is in dire need of a refactor — breaking down the monolithic beast into smaller and more succinct components.
That story is the lifeblood of the microservice architecture transformation that’s sweeping the enterprise landscape. The idea of being able to modularize your components and increase the rate of ideas to market with targeted scaling at the cost of increased complexity of your systems. One question I’ve been interested in is the “how?”. How does this transformation take place? How do you visualize and explain your concepts to others? I’d like to offer a perspective that I think mimics this enterprise development transformation quite intuitively.
I’m really just copying a pattern from the natural world and using it within a different context, in this case the life cycle of a typical star. A star lives a long life burning through its fuel and eventually grows larger as that fuel is spent. When no fuel remains, the star is now a massive red giant which explodes and obliterates everything remaining in the solar system to celestial dust. Many years pass and the dust coalesces into larger bodies, eventually giving us asteroids, moons, planets, and another infant star. To elaborate on how this relates to the application life cycle — an application, much like a star, gets larger over time until it gets too big and separates into its base pieces to be rebuilt again.
Credit: User Cea from FlickrThink of each dust particulate in the aftermath of the star’s supernova as an individual unit of logic. It could be business logic, a database query or connection, a model, etc. Pretty much everything. These are distributed evenly across the system randomly with no dust particle having any bias to another (yet).
For dust particles to start adhering to each other we should think of our user flows and which dust particulates they require. Each flow that your user traverses in the sea of particles leaves behind a trail connecting them and drawing them closer together. Each flow builds on each other eventually leaving a heat map of the hot spots that see the most use. I propose these hot spots are your new contextual boundaries! Think of these new boundaries as orbital bodies of each other. You could have a central star with planets and those planets could have moons. Maybe a rogue component acts as an adapter between two major systems; I recommend thinking of it as a comet that traverses multiple solar systems.
I haven’t seen this concept or the term used before and therefore I’d like to coin it if available, Solar Architecture/Design.
Credit: User Unserkanal from FlickrThis perspective gives you a lot of flexibility with implementation after identifying these boundaries. There are no restrictions with choosing to use modular monoliths or choosing microservices in the cloud, though the real strength of this lies in the system’s structural diagram. I shun the idea of describing complex systems as simplistic layers or letting architecture sprawl into a mess of connecting lines in a web chart that takes more time to remember what’s involved so you don’t break anything rather than delivering value.
When you start to think of complex systems as orbiting bodies it becomes easier (at least to me) to understand where new requirements should fall within the system. It’s easier to understand how new requirements can be assimilated into this model. They could fall effortlessly into the Sun or perhaps are huge dinosaur extinction level events for a planet that should cause a reevaluation of that particular context’s design. I also like the organization of data with it as I like to follow the recommendation of up to a single degree of separation from the source of truth to an edge.
It’s inevitable that whatever method you choose to refactor a system you can’t avoid another revamp in the future as languages and technologies change. One arguable drawback I see to Solar Architecture, though I think it also rather fittingly makes sense, is if this technique were applied to the entire organization at the same time. Too much material will collapse this type of model (of course I was going to fit a black hole metaphor into this concept somewhere!) and instead should be considered with the company as the core of a galaxy with multiple solar systems orbiting it.
In conclusion, I think the laws that hold the physical world together also apply to the intangible organization of our technological systems and I look forward to exploring this notion more.