Home‎ > ‎

Solution Design Being Creative


Linda Storm
Solution Design
Enterprise Architecture

Solution Design Being Creative


If you are like me you are or have spent time trying to figure out what a high level solutions design document is within the context of a particular organization? Yes? If you have then this is my experiences written down for you. In hopes of saving you countless hours of trying to decipher TOGAF, Agile, Six Sigma and a myriad of other frameworks to find out that you are a mere consultant with a job to do.  
 
For me a solution design is a document that the instrument that is used to put the new target technology in place. It is a combination of technical how to with all the necessary people inertia required to implement it. I have never created two solutions the same way. The reason they are different is because people and business processes are different and for a solution design to be spectacular it has to suite the business and be effective.
 
I am not discounting the many words and organization that has gone into formulating the above mentioned frameworks to standardize the solution design process. They have merit. I am certified. They are useful. But to me as a consultant they are too abstract to use directly for that perfect fit everytime. I find that I use their examples to communicate basic categories but that is where it ends. But as far as having to use these frameworks to generate the necessary documentation that is going to get the final sign-off I find them not so useful.  
 
What I do find useful are: creative minds, well established design patterns with best practices that are well understood.
 
I use simple tools like, Snag It (don’t laugh), Smart Draw, Visio and Word. These tools with of a lot of technical experience in communication and a strong technical background is what yields solid results. After an organization has evolved enough to desire roadmaps, transition diagrams supported by mature Service Level Agreements and Operational Level Agreements I would recommend a larger framework tool to manage the collection of paper knowledge acculated by the brains behind the scene. Know what to speak to and how to say it is where the true solution lies. I have sold millions of dollars of solutions with teaching documents, some with elaborate bill of materials and some lecture style. I tell you there is no sweet single template for any of this. Having said this, I would like you all to consider the value of a well organized library of architectural documents organized in a way that your organization can easily use.
 
Examples are also of limited value if they are not directly related to the technical environment at hand. For example, what does creating baby cribs have to do with designing a solid voice recording environment for a call center or building a metering sub station? Pretty much nothing and nor should it.
 
Regardless I find that the definition and practice in IT architecture solution has more to do with politics than modeling. Knowing how to create the ‘right’ documents with the right content is the main task at hand.
 
There are three types of solution design people. Trust me when I say you are wanting to target the third type.
1. You don’t see the politics.
2. You see the politics and do not know how to play.
3. You are well aware of the politics and know how to play.
 
Great! You are number 3. A quick test would be to try and find a solution in your head any scenrio before you strike a document. Can you visualize it happening at all after the first few meetings? If not you are probably in education mode or carry it forward for socialization or put it in a technology roadmap. Whatever your final vehicle for recommendation is, give it visualization and understanding. But use the right words in the right document.
 
Sometimes you have to wind back the project a bit. Did you get a decent set of business requirements? If you did, enjoy, because it is very rare. Most business requirements and the documentation associated with them are very deficient and fail to convey the entire scope of the work to be done and its associated impact. Indicators of poor business requirements gathering and work is reflected in the umpteenth project being shot down by management or coming in over cost. Sound familiar. As a solution designer, I have worked with business to reverse engineer a set of meaningful requirements. I find it very therapudic.
 
In this environment the solutions designer can attempt two things. Working with the business analyst to create a proper set of requirements and reproduce the document. From experience this rarely flies for two reasons. First the business analyst gets all upset and management does not like to pay to have work redone and pay for it again. Although they are not doing it again, they are extending it to include more scoped work. Did you get the meaning behind that last verbal statement? I have used that argument successfully in the past to get a properly set of business requirements worked up, but does not always work. When this does not work I now have to craftily make the introduction of those business requirements inside the solution design document. And it has to be done in such a way as to not address it as a deficiency. But to not include it at all in the solution would create uneasiness or cost overrun. Neither is advisable. So I add them to the solution design as a requirement.
 
Good luck, later I will speak to the milestones of implementation.
 
Linda J Storm
Comments