Ignatica Framework - Part 3 - Delivery

Agile, Stories, FRS, TRS, BRS DRS, Waterfall, Six Hats, Incremental Releases, PRINCE, Princesses, CMMI (1 ~ n), Stand Ups, Sit Downs, Pair Programming etc. etc. (some of the abbreviations I have made up). I have been part of pretty much all of the above methodologies, standards and disciplines, all (deliver frameworks, methodologies, tools etc.) are great and they work however there is a big "provided":

1. The software that is been worked on must have architecture designed in the way that the team can apply there methodologies for delivery.
2. The team (business - PMO - Technology - Operations the whole nine yards) must be on the same page and understanding.

This (point 2 above) is where things become a wee bit ?? complicated to a point where PMs and Delivery Managers run for the exit, often because the business sponsor will ask for a "total cost / budget / time-to-deliver for the project", and good luck with that trying to apply one methodology to one team and another to another team.

Now, I have heard ?? in technology team "ya!! the business does not know what they want, they keep on changing there minds, lets give them something that we can deliver."

I transitioned from the front lines of the deliver, coding and managing deliver teams into actually owning and running a business, so I bear plenty of scars, emotional & physical from been just out right abused, ridiculed to physically asked to leave the room. I now can say with authority that I understand the frustration of the business sponsor ?? "WHY CAN YOU NOT TELL ME HOW MUCH AND WHEN I CAN GET ....".

Try telling the business sponsor, "in order to provide you with this feature F1 we have to change A, B, and Z, and now because B is changing we have to update C, but then C is used by business unit 1 and hence we have to create a new C-1, then patch A to A-1 & B to B-1 and we can optimize Z, and by the way A & B was done by vendor so we don't fully know what and how much it will cost, as the vendor needs money to do the analysis first.", by this time I am sure a physical chair ?? is flying at you and all developers / BA's including me are hoping that the ground just opens up and some how swallows all of us so we can go back to doing what we do the best, code. And, lord have mercy if you survive all this do not mention "TCO", because after all this patch-work the number on TCO is going up for the business to do business on your system.

The Ignatica Framework!!! If you have read my previous article, the key words are "distributed" ??, "isolation", "predictable", "repeatable", "measurable"

Putting my "developer" & "QA" ?? hat:

• I want a framework that takes away "boiler plate fatigue", I hate setters, getters, common logic to validate values again and again.
• I want a framework that I only have to write business logic, not 20 other classes before I can write the actual business logic.
• I am a developer, give me fresh class that I can write from scratch, touching and coding in others code is not my cup of chai ?.
• I don't want to wait or rely of others for me to write code, I am a geek, put me in a dark room and feed me chicken-pineapple fried-rice? & ice-lemon-tea with lots of sugar, I want to work in a box.
• I am awesome developer, I will NOT ASK for help from my team mates, who does that ??, it is so lame, I will rather go to internet and just copy the answer that I fell is the best (or with a green ?)
• I am only going to write my business logic, why I should be worried about other's business logic.
• I want to be able to test individual developers deliverables and test all the functions as and when they are ready.
• I do not want to test previously released code that is already tested and certified, unless there is a bug fix.

? If you lived in Hong Kong, you will understand the amazing unique taste of "Set A", "Set B" etc.

Putting my "Architecture" ?? hat:

• I want a framework where developers do not have a chance to ruin my grand vision.
• I want a framework that is controlled by the core team of 2 ~ 3 rock start developers that control the final outcome.
• I want a framework that is simple yet complex, i.e. simple to use for a average intern or junior developer to use yet complex that can be put into tough production systems.
• I want a framework that can be extended without needing to recode, rebuild, recompiles i.e. free of any "re".

Putting my "DevOps" & "Delivery" ?? hat:

• I want to be able to measure exact cost / time and delivery of each requirement.
• I want to be able to hire junior developers that can be made productive in 1 week
• I want individual developers to be able to track his/her times in my XLS or JIRA so I understand exactly what they are up to.
• I want to be able to deliver code into production using the same pipeline for every release, i.e. not make changes to the environments every time there is a new release.

So, taking into account the above and a room full of white-board points we have brought to life "The Module" ˉ\_(ツ)_/ˉ, ya right!!! that is kind of underwhelming, all systems in the market are modular isn't it? So is this a YAML (Yet Another Module Lingo), and to that the answer is NO. And here is why - I put my money where my mouth is:

Business as Lego Blocks

My two rock starts Gulshan Tomar & Benjamin Leung came up with this simple statement, we should be building "a framework as a set of [blocks of code] that reflects the current state of the coverage (policy) for a point in time, and individual [blocks of code] should have zero dependencies on each other."

And, this is exactly what we built in the framework, individual blocks or modules move the current state of the coverage (policy) from "current" to "target" state, and everything is contained within that module without depending on any other module.

Key here is to break down requirement into one business operation only, e.g. Claim for ILAS "write the requirement looking into the box of claim for ILAS only, i.e. move funds, move money, move date if need be etc." similarly Claim for Medical "write the requirement looking into the box of claim for medical benefits only, i.e. run rule of benefit limits, move claim account etc." As there are no limits of number of modules that you can configure to a plan, it is just a matter of building these Lego blocks into the plan.

Business Module

1. Configurable - Enough metadata that can be used to configure (plugin / pullout) business functionality without needing to recode or involve developers.
2. Discoverable - Objects / Classes at run time should be able to discover by calling systems.
3. Controllable - Event management hooks / end-points / frameworks that are fixed and can be used to control the behavior of the module at runtime.

Implementation view:

A typical Java Module is based around the platform-sdk & insurance-sdk Abstract Classes.

1. Rules - Logic that defines externalization of Rules & Parameters that can be configured from the User Interface.
2. Business Event - One module deals with only one business event, that is controlled through the JAVA Enum function.
3. Accounting Logic - Accounts activity as per defined in the User Story / Requirements
4. Business Objects - as defined in the insurance-sdk under the io.ignatica.insurance.models

? The java developer will only write the code for the module. He/she does not need to care about declaring the end-points, external JSON conversion, state management etc. all this is taken care off by the framework. Module java abstract will give three methods, preCondition(), businessLogic() & postCondition(), so code for all modules will be organized in the same way for consistency / repeatability, predictability etc.

? As each module is a physically separate java class with unique ID given by the BA from the story (FRS) to the code there is 100% traceability between what was asked and what is coded, besides there are no limits on number of modules that can be written, each of the modules gets compiled and executed as per the plan definition. See my Part 2 to understand how plan defines what modules to load at runtime.

So, the key here was to remove all the boiler plate code and reduce the coding to purely coding for business logic with very well defined boundaries:

1. preCondition() - do all your validation checks before you run your business logic.
2. businessLogic() - do all your business logic as defined in the story / FRS.
3. postContion() - do all your post business logic validation as defined in the story / FRS.

Now you understand Ignatica Framework is not just a YAML (Yet Another Module Lingo), there is a lot more foundation, runtime framework that makes this a truly modular design, that can be 100% extended by 3rd party or SI partners.

? This also makes project planning, testing and delivery predictable, as you are not making changes, you are adding new modules as per the new requirements without needing to understand what other modules do.

Changing a plan behavior is easy, you are swapping out old modules by disabling them from the plan or launching new plan configuration with new modules, without causing any issues to the previously launched plans.

• Ignatica Framework Part 1
• Ignatica Framework Part 2

Ignatica | Adhvent Ltd | #insurance #insurtech #java #javadeveloper #insuranceinnovation #insurancesoftware