About Me

My photo
Rohit leads the Pivotal Labs App Modernization Practice in engineering, delivery training & cross-functional enablement, tooling, scoping, selling, recruiting, marketing, blog posts, webinars and conference sessions. Rohit has led multiple enterprise engagements including ones featured in the Wall Street Journal. Rohit focuses on designing, implementing and consulting with enterprise software solutions for Fortune 500 companies on application migration and modernization.

Thursday, October 24, 2019

Migrate away from IBM Integration Bus

Monolith  ---------------------> DB

Step 1.
Monolith  ----------> DB |  ACL |  Microservice1     ------> new DB (Read only)
 - all data is migrated in read-through from old DB to new DB via ACL
 - Migrate 90% of the data like this
 - newDB <-- sync --> oldDB [needs Synchronization]

---

Migrate off of IIB
 - Rapid migration off of IIB
 - Take the custom code > wrap it in s-boot and don't change the data model
 - No local database .. all IIB converted apps talking to data model
 - [x] Conformist pattern ... then no ACL
 - [y] Evolve the API and add new consumers then add ACL and use your domain model. no database.

 (1) - Proxy off of IIB <READ>
 (2) - Selective re-examine data strategy based on the app <READ|WRITE>

---

DDD is BROKEN!

The theory of domain driven design created by Eric Evans in his seminal book  Domain Driven Design (DDD) was published in August 30, 2003. Now DDD is such a dense tome that it requires an average senior software engineer two tries to read after which you wonder how exactly you apply this to running software. Thereafter you start reading the Vaughn Vernon's red book - Implementing DDD to figure out the implementation of these patterns in code. At this point most software engineers are still struggling to apply the tactical and strategic patterns of domain driven design. This was the state of DDD around 2010.

Enter Adrian Cockcroft of Netflix fame who along with Martin Fowler sparked the microservices revolution and a renewed interest in DDD as the theoretical underpinning for microservices. This jazzed up everyone, since no one had a clue about how to structure the boundaries and domain for individual microservices. What is the correct way to design the boundaries of your services ? Bounded Contexts and sub-domains and context maps from DDD came to the rescue. and provided a basis to structure your system of microservices.

So we have the theory to now split and structure microservices. This again is NOT Enough. A lot of architects floundered in trying to figure out how to transform from a massive monolith to an event driven choreographed system of microservices. They struggled defining the subdomains and the bounded contexts.

Enter Alberto Brandolini who figured out that Event Storming is the only way that merges the people and technical aspects, the tactical and strategic aspects to visualize domains. Event Storming is a cross functional facilitation technique for revealing the bounded contexts, microservices, vertical Slices, trouble spots and starting points for a system or business process. Event Storming and other techniques that I mention later allowed architects and product owners to practice strategic DDD. There was no systematic way to practice strategic DDD to software before event storming. Alberto's influence on DDD in seminal as one who democratized it and made it available to masses. There is also an analogy to legos here. In the 1950's legos were introduced in Scandinavia, however their sales were struggling. Lego was far rom the powerhouse it was today.  It is only when the Lego company started shipping instructions to build the lego sets, that sales took off. This is key  - the packaging, the instructions that allowed a seven year old to build the set on their own and get a sense of accomplishment without nagging his/her parents.

Now having practiced event storming for a couple of years , we realized that incremental notation is key. If you get stuck on creating a color coordinated combination of aggregates, commands and events , read models, UI, data and policies it can pigeon hole and restrict the domain model and lead to a tunnel effect. Domain Events are front and center for event storming, everything else is secondary and needs to be added incrementally.  The gap from event storming a system to an actual backlog of stories is HUGE. If you follow the textbook definitions of event storming you end up an event sourced CQRS system which most developers struggle to implement and maintain. A mistake i have lived with. There are multiple forms of event driven architecture and choreography what-is-event-driven. We want to start with the easier incantations and then graduate to the top level of a full blown event sourced system.

This led to the  SWIFT method that leverages a technique called Boris that uses graph theory to model the relationships between the capabilities in a system. This process generates information about how the system "wants to be designed" and attempts to avoid pitfalls such as premature solutioning. At the end of a Boris Exercise, Services, APIs, Data and Event Choreography and a backlog of work starts becoming obvious.

After Boris it is critical to run multiple modeling exercises and then determine MVPs for the vertical flows. In order to determine the right MVPs for your system you have to consider thin vertical end to end slices where these domains interact with one another. You have to prioritize the thin slices based on technical effort, risk and business value. The slices encompass a sub  section of events . The MVPs map a path from strangling the monolith and leveraging tactical patterns to interact with the new domains and services. There are multiple techniques that can be applied here including domain story telling and user story impact mapping.

Vertical slices are identified by choosing short, domain event flows in the core domain and defining the architectural components required to produce those events. Slice by slice, translate the domain model into microservices that use APIs, message queues, etc., that will run on the platform. Finally, a set of user stories is defined and mapped to releases or MVP.

After performing the mapping of user stories that realize the tactical patterns to MVPs, we now have a concrete backlog that developers can start with and iterate on.

Here is the full sequence of steps that help with decomposing a monolith:
1. Define Objectives and Key Results (OKR) for the app modernization effort.
2. Event storm the application and identify bounded contexts.
3. Pick several short domain event flows in the core domain that constitute a vertical slice.
4. Create Boris diagrams that define the relationships between the domains for an end to end slice
5. Perform SNAP analysis to score the effort and define data, API and messaging interfaces
6. Create a backlog of prioritize user stories tied back to OKR.
7. Impact Map user stories to MVP or releases.

At this point the benefits and promises of DDD become real and the theory of DDD laid out by Eric Evans becomes a pragmatic living software system.

Happy Modeling.
Rohit Kelapure