Business Software Solutioning and Implementation

March 25, 2018

Introduction

Software as a tool brings values to business. Business and its portfolio analysis brings up scope and requirements. It is software’s goal to implement those scope and requirements in a profitable and sustainable way.

This article explain at high level some basic concepts and approaches in this process.

Solutioning

To build a software solution for a business requirements. The first step is solutioning it. Solutioning is more than analysis and design, is also about finding software tools, infrastructure, hosting environment which the design and implementation approaches are based on.

Referring the diagram to see the steps in solutioning.

Requirements and scope presidents UI tools and so lead to underneath business logic analysis

Business Domain Logic facilitates the UI where the business requirements are presented. It is one level of abstraction of business needs. It is very important the domain logic fits into existing system.

Domain Data Model is a data level abstraction of domain logic. In most of business practices, we don’t invent domain data models every day. Instead we rather to reuse and expand current domain model to leverage the the existing system, Unless a company need to have an all new business or portfolio model.

Data Model is the highest data abstraction. It normally matches a data persistent system. Domain model is a view from business angle while data model should be a view reflecting the nature of data itself.

Implementation

Nowadays everyone rush to embrace Agile/Scrum practices without a hesitation. This trend is largely pushed from a business end, because it does promote shorter turnaround time, fast customer value delivery.

If we can give a second thought, Agile/Scrum is not a perfect fit for a solutioning process, not even for high level design. There is no end user value delivered during these phases. Though the core idea can be adopted like iterative approach and continuous improvement.

Implementation is a reversed steps of solutioning. Starting from requirements and scope, ending with data model we can have overall solution plan and high level design. Implementation should start from data model. In some case it can start with business domain logic if the domain model/data model is already available from other projects. We need to be very careful to think though all the domain and data models

Agile/Scrum practices best fits for UI and its business supporting logics. They are largely in requirements and scope and business domain layer. There are cases which domain model or even data model need to be involved in a Scrum Sprint, but if it happens rather more frequent that occasion, then we really need to revisit the domain and data model design.