One View on IT Solutions

[This week’s blog post is from fellow solutions writer Tom Shinder. Tom is a member of Datacenter, Devices and Enterprise Computer (DDEC) Solutions Team. The Solutions Team is responsible for creating standards and defining guidelines and delivering training and mentoring that enables the writing organization in DDEC to create solutions to complex IT problems. Tom is probably best known for the work he’s done related to ISA Server and Threat Management Gateway (TMG). His current focus on the Solutions Team is on hybrid cloud architecture.]

One View on IT Solutions

By Tom Shinder

Solutions, solutions everywhere, and not a drop to drink! There is a lot of talk in the IT world today about solutions. Just go to any vendor’s web site and at the top of the page you’ll see a prominent menu item for “solutions”. IT vendors understand that companies are moving away from the product and feature-based world that was so attractive to IT organizations in the past. Instead, they are moving toward IT solutions. There’s a big difference between focusing on applications/application features versus focusing on solutions. First, let’s see if we can get an agreement on what a “solution” is.

What is a “Solution”?

There’s a lot of talk about solutions but not as much talk about what defines a solution. I suppose the first place to start is to look in the dictionary:

1. The act of solving a problem, question, etc.: The situation is approaching solution.
2. The state of being solved: a problem capable of solution.
3. A particular instance or method of solving; an explanation or answer: The solution is as good as any other.
4. Mathematics- A. the process of determining the answer to a problem. B. the answer itself.
5. Chemistry- A. the process by which a gas, liquid, or solid is dispersed homogeneously in a gas, liquid, or solid without chemical change. B. such a substance, as dissolved sugar or salt in solution. C. a homogeneous, molecular mixture of two or more substances.
6. Pharmacology- Also called liquor. a liquid, usually water, in which a medication is dissolved.
7. Medicine/Medical- the termination of a disease. a breach or break in anything, especially one in parts of the body normally continuous, as from fracture or laceration: solution of continuity.

As you can see, there are a many definitions for the word “solution”. Ask a chemist and he might say that it’s a homogenous molecular mixture of two or more substances. Ask a mathematician, and it’s the answer to a mathematical problem. Ask a physician, and it’s the termination of a disease process. Ask someone who writes content for IT organizations and suddenly it’s not quite as easy to define.

I suspect that most of you will think of an IT solution as something like definition #2 – the state of being solved. If that’s the case, then one can imagine that all of the following would qualify as solutions:

• My Active Directory database is corrupt, I need a solution for that.
• My DirectAccess clients can’t connect over IP-HTTPS, I need a solution for that.
• My current Exchange Server 2010 infrastructure needs to be upgraded to Exchange Server 2013, I need a solution for that.
• My users want to bring their own devices into work and connect to corporate resources using those devices, I need a solution that enables them to access these resources securely and protect my business.
• My company has issued new directives that we use public cloud based services so that we can reduce capital expenditures, but we need the public cloud based resources to communicate with on-premises resources, I need a solution for that.

Essentially, IT solutions are answers to IT problems. But not all problems are the same. Some problems are very narrowly scoped, some are a little bigger, some are broadly scoped, and some are, for want of a better term, “ginormous.” The answer to any of these problems is going to be a solution to the problem. So, is this how we define “solution?” Is an IT solution merely an answer to any IT problem?

For my team at Microsoft, the answer to this is “yes and no”. Of course, a solution provides an answer to a problem – otherwise it wouldn’t be a solution and could very well just represent another problem. We’ve decided that a “Solution” (capitalized) is a bit more than an answer to a problem.

A Closer Look

Let’s look a little closer at this. Microsoft documentation has been very good at describing how you can use a specific feature – for example, how to configure the forward proxy configuration on ISA Server 2004. The documentation provides information on all the option buttons, all the checkboxes, all the slider bars, all the wizards, and any other configuration apparatus that’s included with the software that allows you to configure the web proxy. That’s great information and you couldn’t use the product without it. This information provides a solution to the question “what are the available configuration web proxy configuration options in ISA Server?”

That type of documentation was very attractive to the guys in the trenches. I know, I was one of them! And the only thing better than detailed information on how to configure a feature was information on the technical details of how the product or feature worked! I’d stay up until 2:00 AM to read an 80-page white paper on the TMG firewall engine internals – I couldn’t get enough of that stuff.

But that was the age of the IT Pro. If they built it, we’d come. I think the world has changed quite a bit since those heady days of the IT Pro telling the business what to do based on whatever new thing we were playing with at the time. Now, if they build it, the business needs to understand if it’s something they need in order to realize business value. If not, they won’t come.

Therefore, a solution needs to be more than just how to “make things go” (or “we need computer things” – start this video at the 48 second mark). It has to be about an IT based solution that solves a business problem.

The “Solutions Team” Approach to Solution Documentation

Our approach to “solutions” is to begin by defining a problem domain. For example, how to build a cloud infrastructure can be considered to be a problem domain. And we call it a problem “domain” because there are lots of sub-problems included in the primary problem of “how to build a cloud infrastructure”. Another example of a problem domain would be “how to build a hybrid cloud infrastructure”. These two problem domains include many sub-problems that have relationships to each other and in order to solve the primary problem (the problem domain), all the sub-problems need to be addressed in order to arrive at the solution.

But defining a problem domain is only the first step. The second step is to define an audience. One solution does not fit all. We could build a cloud infrastructure, but would the same guidance be relevant to all audiences? For example, consider the following titles:

• Cloud infrastructure for mid-sized businesses
• Cloud infrastructure for enterprise IT
• Cloud infrastructure for hosting providers
• Cloud infrastructure global cloud service providers

While there will be some similarities and some crossover between each of these “solutions” – there are going to be some significant differences too. A cloud solution for a global cloud service provider and one for enterprise IT is going to be quite different – each audience has its own resource capacity, constraints, customer base, and reasons for being. That’s why when we define a solution, we include both the problem domain and the audience.

Notice that in these titles we focus on the IT problem. There is no mention of any specific technology in the titles. As much as we at Microsoft would like to believe that customers are saying “my problem is that I need some new Microsoft stuff in my datacenter” we realize that’s pretty unlikely. What we do know is that we make software that will provide IT-based solutions for business problems. But we don’t mention technology names in the titles of our solutions, because when someone is searching for a solution, they search based on their problem, not based on the name of Microsoft software that might solve their problem.

Now I should qualify that last statement. In reality, people are looking for product based solutions all the time. For example, if I need to upgrade my Exchange 2010 infrastructure to Exchange 2012, you can bet that I’m going to search based on product name. If I have a problem with the anti-malware service in TMG, you know that I’m going to use a product and a feature name to search for an answer. This calls out a key difference between the solutions my team does and other types of documentation that provides answers to IT problems.

The difference is that our Solutions documentation includes multiple products and technologies. Because there are be literally dozens or hundreds of different technologies used to create one of our Solutions, it doesn’t make sense to include any specific product or technology in the title. The products and technologies all work together to solve the business problem called out in the title.

The Solution Document Set

Now let’s get to the meat of our “Solutions”. We take a lifecycle approach to IT-based business solutions. While we all like to begin with installing the software and seeing what it does in the lab and then turning the lab into a production environment, I think we can all agree that such an approach really doesn’t work too well anymore (and it probably didn’t work too well in the past). Instead, we need to be thoughtful about how we plan, design, implement and operate any IT-based solution we bring into our corporate environment.

Our solutions consist of a number of “guides” or “articles” or “documents” (you can pick your favorite term):

• Scenario Definition Guide
• Design Guide
• Implementation Guide
• Design Considerations Guide
• Operations Guide (we haven’t created any yet, but we will)

Let’s take a closer look at each of these and see how each of these guides work together to support an IT-based business solution.

Note:
If you’re in a hurry and like to watch videos, here’s a great 8 minute video done by Jim Dial (a member of our Solutions Team) that provides an entertaining and enlightening overview to our approach to Solutions, as applied to the Hybrid Cloud Infrastructure Solution for Enterprise IT document set, which I will use as the example document set when discussing the guides that comprise the set.

Scenario Definition Guide

The Scenario Definition Guide sets the stage for the Solution document set. The goal of the Scenario Definition Guide is to provide you with some context for the solution and define what the problem is that the solution intends to solve. To accomplish this task, we thought it would be a good idea to give you an example company that wants to solve the problem that is called out in the title of the solution document set.

For example, if the problem domain is hybrid cloud infrastructure, and the audience is enterprise IT, then the Scenario Definition Guide will provide a scenario that is pertinent to a company that intends to build a hybrid cloud infrastructure. In addition, it has an enterprise IT department that will be responsible for defining solution requirements, and designing, building and operating a hybrid cloud infrastructure for the organization.

What the Scenario Definition Guide provides you is an example organization that might be like your organization. The guide defines the current state of the company and its IT organization and infrastructure. It then describes what the goals are for that company as it applies to the problem domain defined for the solution document set. In the hybrid cloud infrastructure example, it would describe what goals the company has for its hybrid cloud infrastructure.

Also included in the Scenario Definition Guide is a discussion of the planning process that the organization went through. This planning process includes a number of questions and answers, with the answers defining the requirements for the ultimate solution that the IT organization will build out.

So, in the hybrid cloud infrastructure example, the Scenario Definition Guide includes a collection of questions and answers that the fictional company Contoso went through to define their requirements for a hybrid cloud infrastructure. The Scenario Definition Guide then finishes with a discussion about what strategy Contoso will use to design and implement the solution.

By the time you finish reading the Scenario Definition Guide, you should have a good understanding of where the company is today, where it wants to be in the future, what the requirements are for the solution they will implement that will take them to their desired future state, and the basic strategy that they will use to get them there.

Design Guide

The goal of the Design Guide is to help you understand the design process for the problem domain covered in the Solution document set. In the Design Guide, you see the design exercise that the example organization went though as it defined the design of the solution. The Design Guide is integrated with the Scenario Guide due to the fact that the design discussed in the design exercise is based on the requirements defined in the Scenario Definition Guide.

The key value of the Design Guide is that it provides you more than just a design. Anyone can come up with a design and say “hey, that’s a good design because I think it is”. While it’s great for someone to think he has a great design, that doesn’t help you that much. Sure, the guy who put that design together might think he’s the smartest guy in the room, but we all know that you are the smartest guy in the room, so you’re not necessarily going to take his word for it that his design is best.

What would be a lot more useful is if you had access to the reasoning behind the design decisions that are made during the design exercise. When you have access to the reasoning behind why a design decision was or was not made, it lets you know a lot about how to approach the design process for your own organization (which is likely to have requirements that deviate from the design requirements defined in the Scenario Guide). With access to the rationale behind the design decisions, you can make an informed decision on whether the design decisions were good ones, bad ones, or maybe even mediocre ones. The key is that you have visibility into the thought process behind the design. Without that visibility, you have to take that design on faith – which you may or may not be inclined to do.

Now you might be asking yourself “sure, the reasons for why the company made the decisions for their design are discussed, but where did they get the rationale to back up those decisions? Did they make it up? Did they have to scour the Internet to find the information they needed to evaluate the options available and try to reconcile all that information themselves before even entering into the design process?”

If you’ve been thinking that, you’re already one step ahead of me. How do you find the available options? Sure, you can search for the information yourself, but that would take a long time. What if someone could do that heavy lifting for you? That’s where the Design Considerations Guide comes in, and I’ll talk about that guide at the end of the article.

By the time you finish the Design Guide, you should have a good idea of what one approach is to carrying out a design exercise for the problem domain covered in the Solution document set. You can use the same approach, or craft a modified approach that maps more closely to how your own IT organization does things.

Implementation Guide

The Implementation Guide gives you the information you need to build out the solution that the fictional organization designed. The proof of the pudding is in the eating. If you can’t build out the design and see it work, then the design isn’t much use. This keys into the fact that when we created the Solution document set, we not only defined the requirements and went through the design exercise, we also built it out to confirm that the solution actually worked.

The process of actually building out the solution described in the Design Guide was very important to us. When we built out the solution, we learned a lot of things about how the various technologies worked together. We learned that it was more efficient to build out the solution one way versus another, and learned about a lot of “gotcha’s” and undocumented issues that required some work to find a solution. The result was that we were able to feed this information back into both the Design Guide and the Design Considerations Guide. The experience of building out the design provided insights that we could pass on to you. In essence, we experienced the pain so you won’t have to.

It’s important to note that the Implementation Guide does not provide a step by step process for building out the solution. What it does do it provide you a “stepwise” approach to building it out. We provide you the steps in an order that we’ve found most efficient to create the working solution. In each step we describe what you need to do, and for specific details we point you to highly relevant links that will help you carry out the step.

For example, if we want you to configure NIC teaming, we will point you to a link that shows you the steps for configuring NIC teaming. If there is something specific that we want to you to do, we’ll describe that if it’s not included in the information in the link, or if it’s supplemental information that needs to be added to what’s described in the link (such as whether to use failover or aggregation).

An example of what we won’t do is send you to the SQL Server home page if we need to you configure SQL Server to support the solution.

By the time you’re done with the Implementation Guide, you’ll understand how to implement the design created in the Design Guide. If that design is something you think will work for your organization, you can use it as is, as we’ve tested it and confirmed that it will work. If your design ends up being a little different than what we described in the Design Guide, you may still find the information in the Implementation Guide useful as many of the steps might be similar, and the order of operations that we describe might still apply to what you end up building out for your design.

Design Considerations Guide

I’ve left the best for last. The Scenario, Design and Implementation Guides comprise what we call a “reference implementation”. If you’re not familiar with the term, a reference implementation is essentially an example that you can use when implementing the same or similar solution within the problem domain discussed. The reference implementation takes you through a single company’s planning, design and implementation process – so it’s very specific for the scenario described for that particular reference implementation.

But let’s say that your company wants to implement a hybrid cloud infrastructure. Your company has some similarities to Contoso, but your current state and your requirements are a bit different. This might lead you to want to make design decisions that are different from Contoso. The problem is that the Design Guide only contains the decisions that Contoso made, and the rationale for those decisions. You need to know what other options might be available to you so that you can satisfy the requirements you defined during your own planning exercise.

What you need is a Design Considerations Guide! The Design Considerations Guide isn’t tied to a specific scenario. Instead, it’s intended for anyone who is interested in the problem domain described in the title of the Design Considerations Guide. This guide exposes you to all the relevant options that you should consider when you get to the design phase. Not only are all the options included, but a discussion of why you would or would not want to select a particular option, given a particular requirement. Armed with this knowledge, you can take your own set of requirements and see which options are available that might be used to meet those requirements.

This is how we approach the design process for the reference implementations we describe in our Solutions document sets. First, we write the Design Considerations Guide – this guide contains the entire universe of applicable options for the problem domain, scoped for the intended audience (both of which are included in the title of the Solution document set). Now that we have that knowledge, we write the Scenario Guide, that describes a fictional company and their requirements for a solution within that problem domain.

Next comes the design process, which is discussed in the Design Guide. What we do is think of the Scenario Guide as a filter through which we pour the Design Considerations Guide. Design options that do not meet the requirements defined in the Scenario Guide are filtered out. Design options that will enable the solution to fulfill the requirements defined in the Scenario Guide make it through the filter. Those design options are then surfaced and discussed in the Design Guide. See, it all makes sense!

Summary

Tackling big IT problems is getting increasingly complex and the amount of time you have to solve them seems to be decreasing at an alarming rate. You just don’t have the time to run the “paper chase” anymore. You need definitive answers to complex IT problems. We hope we are able to help you using the approach to solving IT problems described in this post.

Please feel free to write to me at tomsh@microsoft.com if you have any questions or comments regarding this content. Thanks! –Tom.

Questions for SAB members:

• What do you think about this approach to solutions content?
• Take a look at the Hybrid Cloud Infrastructure Solution for Enterprise IT document set. Can you follow the flow and learn how to use the reference implementation guides and Design Considerations Guide to understand how to deploy a hybrid cloud infrastructure for an enterprise?
• What are some additional IT problem domains that would benefit from this approach?

Please add your comments on this blog post, send email to sab@microsoft.com, or post your question for Tom in the Server and Cloud Solutions group of the Microsoft Solutions Advisory Board Yammer network.