Solution Design - Phases

While working on various projects with different sets of tools, technologies and frameworks, I came across many people and projects who try to go by the book in order to follow particular methodology of software development process or implement particular solution in order to design/solve a software issue. I came across few projects for which there was a need to develop the solution from scratch; for some projects there were constraints in terms of technology being used while for few projects existing solution was working fine, but just had to be enhanced. For few projects agile methodology was used as process of delivering value while for some projects waterfall or classic SDM was used.

While designing/developing solutions for all these different types of projects, one thing I found in common. And that was steps to follow in order to take project to next level of solution. Here is the list of the steps:-

1. Understand the highest level of requirement - I have stressed here on word "highest", just because I have seen architects and project managers emphasizing too much on detailed list of requirements. From project management perspective, managers are always looking to see if given solution will fit into budget and timeline. And from architects perspective, sometimes it is too much emphasis on technology and framework being used. I have seen business users taking a step back at the beginning of the project itself, due to complexity of architectural terms and numbers thrown in air about the budget, because they were pushed to specify to give requirements from day 1. I suggest, at the beginning of the project business users should be asked "What is your goal at the end of the project? What is it that you should be able to do at the end of this project without too much/no manual intervention from your side?". Because in the end, the process of software development should be for elimination of manual work for business users while meeting their business processes and standards. The answers to this type of questions in a paragraph or 2, gives the "highest" level of requirement of what I call a "Goal" for the project team. In agile world, this is also known as "Epic".
2. Divide the Epic into SubEpics - Once the "Epic" of the project is understood, next step should be dividing it into "SubEpics".  This division should be done by considering the various upstream and downstream applications involved in whole slew of the portfolio in case the architecture is being done for the existing application. In this case, each subEpic would identify individual system/application involved. If this is a brand new project altogether, then modules in a single application should be determined. Each module could suffice requirements for a single "SubEpic".
3. Determine the "Goal/Output" for each subEpic - This is going into the next level of requirements. Once the application/module is identified for delivering functionality of certain subEpic, then high level inputs and outputs for the system/module should be determined in order to meet the output requirements.
4. Design high level diagram - High level diagram would then consider how the data would flow from one system to another or one module to another. Determination of technology/framework that should be used can be done during this step. Constrains such as 'Scalability of technology, Volume of users using the application, Network Bandwith, Data volume' etc should be discussed at this stage.
5. Determine integration points - Integration points between systems/points should be determined and communicated to individual application teams so application teams could further determine the scope of the work.
6. Low level design - After expected input/output for a subEpic is determined, high level process flows are understood and integration points are identified, it is easier for a project team to develop a low level design solution for the project. At this point in time, mock objects for the interfacing between the systems/modules, data table designs, screen look and feel from usability perspective etc could be considered. Also, application teams can then take 'Epic' requirements further and break them down into 'Features/User Stories/Tasks'. And during project delivery business analysts from application team can work with business users/product owners in to understand detailed requirement.

By breaking down the solution design into 6 steps above, helps stakeholders identify the gaps at business process and architecture level in correct order so they can be met on time.

What could be the possible gaps and constrains identified in each step?

Step 1 - By trying to understand the highest level of requirement from business, project team can ensure, the output of individual systems/modules involved when put together, is meeting the goal of the business users. For e.g. The project I was working on, the goal of business user was to pass the data from one application to another without manual intervention.

While understanding the requirement at this level, business user was not bombarded with questions such as, what should be input output for which module, what is expectation from individual system etc. At the same time, it have an IT team a goal to work towards.

Step 2 - Identification of "SubEpic" would help project managers identify the scope of overall work. SubEpic identifies the different applications/modules that would be touched. It would also give an idea about whether a certain system/module can handle "SubEpic" level scope within certain amount of time. That helps determining the budgets. Identification of "SubEpic" could also determine the feasibility of the project. Because certain applications identified for delivering a subEpic may not be scalable enough to handle load of data or not big enough application team in order to deliver the output. The list of problems could go on.

Step 3 - While identifying input and output for subEpic, application teams could identify where to gather data from. It could be business users/other systems. Some data may exist and can be reused while some data need to created and stored. It solves problems because re-usability  can be implemented and not just talked about.

Step 4 -  High level diagram does help in order to identify bottlenecks within a system. Such as certain systems may not have good enough infrastructure. Memory issues, bad database design, concurrent user base, screen usability issues...the list goes on. Most of these issues are identified when visuals are created about flow of knowledge between the systems.

Step 5 - After putting high level diagram together, technology used as means of communication between the modules/system can help determine integration points between systems. If it is webservice call, how should the consumer soap request look like? Would an xml payload coming help being compliant with existing schema? etc...could be answered.

Step 6 - Low level design actually helps developers identify unit of work for themselves and determine scope and timelines for it.

More to come soon about these 6 steps, in my next post. With Example :) !!