Assessing the Solution s Feasibility

Assessing the Solution's Feasibility

After you have proposed a solution, you need to test it against real-world constraints. Often, solutions are created as "blue sky" plans, based on what's ideal. Before you move forward, you need to be assured that the solution, even at the high level you are working at, can be implemented. There are several questions you need to answer to make that determination.

Is the Solution Feasible from a Business Perspective?

Does the proposed solution address the business objectives it set out to solve? Have the users' goals been considered?

The first test of the solution is to ensure that you provide value to the business stakeholders sponsoring your efforts. One way to do this is to verify that all the original problems and benefits are addressed, point by point. For the most part, the answer is binary: yes or no. Other times, you have to be content with partially meeting the goals. For example, if a proposed solution meets only 90% of the business goals, yet going the remaining 10% would triple the overall cost, most people would agree that the 90% solution is the correct choice.

The other dimension is the user. I'll get into this topic in more detail in Chapter 3, but it is a mistake to assume that the user community will embrace whatever you do as long as the solution is loaded with the right features, comes in under budget, and is delivered on time. Are the users all internal, all external, or do you have a mixture of both? Are they all computer savvy, all computer novices, or do you have some of each type?

Verify that each business goal has been met. If not, determine, along with the stakeholders, whether the degree of coverage is acceptable. Document agreement.

Is the Solution Feasible from a Technical Perspective?

Can you implement the solution as proposed? Has it been done before?

You need to validate your proposed solution against the technology constraints. This is usually not too hard, because often you are aware of the constraints in advance. However, if you proposed, for example, SQL Server in your solution, but found out later that all the data was in DB2 and would remain there, you would have to adjust your solution.

This step is where reference architectures come in handy. Reference architectures act as a "proof of concept," an assurance that something can be done using the technology described. As an architect, it is usually more comfortable to follow someone else than to boldly go where no architect has gone before (apologies to Star Trek fans everywhere).

In short, are you able to implement your solution given the available technologies and within the constraints the business sponsors place on you?

Is the Solution Feasible from a Resource Perspective?

The Microsoft Solutions Framework (MSF) has a lot to say in the area of resources. For your purposes (passing the exam, remember), I'll compress it into the essentials.

You need to know if you have, or will have, the correct resources to carry out your solution. Before you focus just on developer resources, take a look at the six roles Microsoft recommends for each team:

  • Product management Acts as a customer advocate and ensures that requirements are met

  • Program management Leads the team and makes decisions

  • Development Designs, builds, and unit tests

  • Testing Performs QA testing and testing against use cases

  • Logistics management Provides infrastructure support and deployment

  • User education Performs user training and acts as a user advocate

graphics/note_icon.gif

What is MSF? MSF stands for Microsoft Solutions Framework, and it's been around since before the days of Distributed interNet Applications (DNA). MSF is a set of best practices and concepts for designing, building, managing, and deploying applications. To more fully understand what MSF is all about, I suggest visiting http://www.microsoft.com/msf.


If you're seeing this list for the first time, you might be thinking, "But I have room for only four people on my team!" Well, the good news is that these are roles, not people. A single person can perform more than one role. Taking into account caveats from Microsoft about combining certain roles (such as developer and tester), you could get by with two or three people for a small project. The message is that all six roles need to be considered when analyzing available resources and skills.

So, what you come down to is the question, "Do I have enough people, with the proper skills, to perform all the necessary work for the defined roles and still meet the assigned deadline?" If the answer to that lengthy question is no, it might be time to renegotiate scope, deadline, or budget. If that is not an option, then the lack of appropriate resources becomes a "risk factor," which is discussed in detail in "Managing Risks" later in this chapter.



Analyzing Requirements and Defining. Net Solution Architectures (Exam 70-300)
MCSD Self-Paced Training Kit: Analyzing Requirements and Defining Microsoft .NET Solution Architectures, Exam 70-300: Analyzing Requirements and ... Exam 70-300 (Pro-Certification)
ISBN: 0735618941
EAN: 2147483647
Year: 2006
Pages: 175

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net