Continuing on with my 2014 Lab Refresh, and going through the Design Process i’ve done much whiteboarding and am now ready to put things down on paper. I’ve started the Design and thought it may be useful to share my process with you.
More recently, I have been involved in more implementation of solutions, than design. This exercise is to sharpen my design skillset that I had in my previous role(s) and to get me back into the groove of how a design should flow.
The first step in any design is to not only understand what the customer wants to accomplish, but understand how they operate. This includes many facets of the customer’s business. An understanding of what they do, who their customers are, how they are organized helps tremendously in the “Trusted Advisor” space. This term is used a lot in the Partner space but I still think that there is a gap between it’s true meaning and reality.
In reality, from my experience, there is much time talking about technology, not broadly, but more so product discussions and that’s because we are talking to Technologists, the IT Managers and Engineers. Most don’t get the “trusted advisor” relationship as they care about what technology we can offer to help them achieve a goal or goals. Conversations are typically product focused with very little impact on the overall goal which could be something like the ability to serve our customers better by being able to provision resources rapidly to keep up with demand.
These conversations need to take place with the leadership teams, usually CIO/CTO, that understand the Vision and Direction of their business, AND are willing to provide insight into those things.
Back to the LAB. For this exercise i’m going to treat myself as the Customer. I have specific requirements and goals that need to be met and like all customers, I have a budget and timeline that I need to meet. Since I am playing two roles here, I have started the Design Document with an Executive Summary and the list of Requirements, Use Cases, Assumptions, Constraints and Risks.
Here we outline the goal of this project and identify the KEY(s) to each portion. Now, let’s move on and list out our Considerations in Requirements, Use Cases, Assumptions, Risks and Constraints.
Now that all the Considerations have been identified and listed, we can put a solution together that will meet all the goals.
Stay tuned for the next update where I list out my Solution Decisions along with explanations as to why I chose this route. I’ll give you hint: XXXXXXXXX is a set of software tools for building and managing cloud computing platforms for public and private clouds.
If you missed Part 1 of this series, please see the Index below.