Home‎ > ‎

Solution Design Struggles


Linda Storm
Solution Design
Enterprise Architecture

Solution Design Struggles


Getting closure to a Solution Design Document can be hard. As a solution designer you have the challenge to create something from ideation. Yes, from thoughts to paper. This is not easy to do. There will be those that were incapable of coming up with a design that will make it impossible for you to close yours. I find most of the issues evolve around their lack of understanding of the technology.
Their lack of understanding of the technology makes them too nervous to render a decision. They want to use the solution design document as a learning tool and next thing you know you have created a university text book instead of a solution design. How to avoid this?
 
If they are really wanting to still explore alternatives, then I strongly recommend that you wind backwards to a business case before moving forward to solution design. I recommend that nothing move forward to solution design without a decision and commitment. A simple business case can be used to acquire a decision. 
 
Solution design documents can be split into two general phases: high level and detailed. Both the words solution and detailed are also miss understood. Solution here means that there is enough information for your technology managers to implement. The term detailed means just detailed enough for them to run with it. Detailed does not mean you are obliged to document every last detail for implementation. Rest assured the implementation team is going to get really red in the face and tell you to where to go take a hike.
 
As a solution designer you will have to interview as well as assess what that level of expertise is available before wording your solution design. Once the expertise is assessed you have to find just enough words to describe what they need to do without getting into hard core implementation details. Implementation is what you are paying them for. Design is what they are paying you for.
 
Elegantly carry their concerns forward to implementation on their behalf. After a while they will catch on and learn where the boundaries are.
 
I have seen many clever ways to identify information that is being pressed for inside the solution design document needs to be carried forward to the implementation stage. Given that it this information needs to be identified at this time by curious and nervous minds in causing needless $concern$ running up costs rehashing and hazing the solution. Outside and sometimes inside the solution design document mention that this data or information will be determined during the implementation phase and dispose of it without loosing the thought? It reminds me of putting away the laundry where socks go in the socks drawer, sweaters in the dresser with the other sweaters and jeans with the other pants. Trust me you are not providing a good service by scattering their data all over the place. By not playing your roll as solution design and destroying what is to be their source of truth for implementation will eventually be identified as a major concern.
 
The solution design documnt is a handshake that does not attempt to describe the project in ALL AWSOME detail, but to identify major technology areas that are involved so that the technology areas can prepare themselves for the incoming technology and costs for resources, thus eliminating surprise. Details such as IIS server ports, firewall acls, backup tooling, restore tools, scripts are mentioned as required inside the solution design, but are not flushed out in 'how to'. When you start working out how to you are sitting on the fence for implementation. The only time a 'how to' would be detailed inside a solution design is when the 'how to' is being redefined.
 
A creative way to capture all the small details of a design is to perform a strawman or proof of concept first. During the process the details can be documented for implementation. Again, this is proably only required if it is new or different technology that the implementation teams have never seen before. Now I am back to part of the solution design is to determine how much expertise is on board to determine all the factors required for the solution like training and reworking business processes.
 
Good luck.
Linda J Storm
Comments