Getting into a discussion with the domain experts, asking the right set of questions about business processes which at times lead to serious brainstorming sessions, kick starts the development of high level of abstraction about the domain. This abstraction is an absolute necessity and it needs to be represented in a set of structured instructions using a common language, understood by the domain experts, business analysts, software architects, and software developers. While documents written in high level language such as English or other similar languages, diagrams, pictures do play a role, they leave enough space for ambiguity to creep in. We translate this high level of abstraction into well-structured algorithms using Unified Modeling Language (UML) techniques as base. We call this process of translation, ‘business process modeling’. In this process we don’t limit ourselves to high level design of UML, but delve into finer details, the end result of which is a software blueprint which is a set of algorithms in pseudo code language where each algorithm mimics a business process using a network of instructions beautifully weaved together based on the truth or falsity of previous sub-processes or instructions. Developing a software to represent business processes A, B, and C in a relationship such as (A + B) → C is not too difficult to implement. Where it gets complicated is in understanding what are the exceptions or conflicts in (A + B) → C. Hoping this understanding will automatically come during the software development stage leaves enough space for leaks and gaps to creep into the software, eventually leading to software bugs. A well-structured software blueprint captures all possible logical paths the system can take which means that your test cases are getting ready along with the software blueprints. If the software can take n logical paths, then the software should have n test cases. And we have not written a single piece of code yet.

The initial software blueprint goes through few stages of technical transformations which includes database design, message queue, event logging, etc., and matures into a near complete representation of the abstraction we started with. Software architects and software developers can use software blueprints to create other layers of abstraction in object-oriented programming such as class and object relationships, suitable design pattern, suitable architecture pattern, and infrastructure architecture before venturing into software development or coding. Our approach of software engineering is a mix of design and test-driven development.