Date: February 5, 2004
Analyzing Requirements and Defining Microsoft.NET Solution Architectures, Part I...
This series of articles is going to provide an overview of issues surrounding the architecture of .NET solutions. It will also look at the requirements for the related and similarly entitled Microsoft certification exam (70-300).
Date: February 5, 2004
This series of articles is going to provide an overview of issues surrounding the architecture of .NET Solutions. In doing so it is going to loosely follow Microsoft's recommended approach and, in particular, look at the requirements for the related and similarly entitled Microsoft certification exam (70-300), which itself is one of the requirements for the MCSD .NET qualification. Thus I envision two roles for readers of this series:
Of course you may fall into both camps.
Despite the fact that this treatment is planned as a series of 11 articles I shan't be entering into a great deal of detail. This is largely due to the breadth of the subject matter. What I shall do is focus more on the abstract concepts and knowledge concerned with architecture rather than general .NET development issues. My thinking here is that if the reader, like myself, comes from a development background, the gaps in your knowledge will be on the architectural/ methodological areas rather than general development concepts and .NET implementational specifics. This will obviously affect certain areas of the project lifecycle more than others (e.g. physical design). So, for example, I'll largely assume the reader is happy with the general issues around state management for different types of project solutions, as well as the specific range of solutions .NET offers in this arena. Note that you'll need the whole package if and when you come to take this exam!
Lots more material is available at http://msdn.microsoft.com/architecture/. The main reference for this series of articles is the Que publication: 'Exam Cram2 .NET Solution Architectures' which is generally accepted as the best preparation guide for the exam at the time of writing.
We'll be breaking down defining .NET solution architectures into the following areas, closely related to the 70-300 exam requirements ( http://www.microsoft.com/learning/exams/70-300.asp)
1. Envisioning the Solution
2. Gathering and Analyzing Business Requirements including
a. User requirements
b. Infrastructure requirements
3. Developing Specifications
4. Creating the Conceptual Design
5. Creating the Logical Design including
a. creating the logical data model
6. Creating the Physical Design including
a. deployment and maintenance
7. Creating Standards and Processes
That's 11 distinct topics of varying complexity that I shall attempt to consider in 11 corresponding similarly proportioned articles but we'll see how we go as some topics are more involved than others so this may not be possible.
What follows is a framework containing suggested approaches and ideas rather than a strict methodology to be followed. This framework should be scaled and adapted to the size and complexity of the project under consideration. There are options for employing various methodologies within the detail of the framework.
It is also important to note that the framework does not specify a set of serial activities. They are presented in the anticipated chronological order but there will, and should, be considerable overlap between activities in the RAD/ iterative model of software development now commonly employed.
This stage is concerned primarily with creating a vision statement and solution scope. These are high-level overviews of your project.
Key areas for consideration are:
Problem definition: what is the problem to be solved by the solution. Consider the business goals and your users in forming the problem definition.
Solution proposal: based on the initial problem definition what is the high-level solution proposal (vision and scope).
Solution feasibility assessment: is the initial solution proposal feasible from technical, business and resource perspectives?
Managing risk: even if the solution is deemed feasible you may well have identified potential risks to project success. These risks should be managed from these early stages. For example, there may be anticipated competition for resources.
Looking at these areas in further detail:
The first step is to define the problem that your solution will address. Suggested questions that will aid arrival at a good definition include, firstly, the obvious:
What is the problem?
The first project deliverable should be a problem statement agreed by all involved parties. The key here is 'all involved parties' as different individuals and/ or groups may have very different ideas of what exactly the problem is or problems are. The resultant problem statement should not be lengthy. Typically it will fit on a single sheet of A4.
Once the problem statement is agreed it should be signed off before proceeding.
What are the business goals?
The business goals are closely related to the defined problems, often simply being the reverse of the problem. Business goals address the 'what’s in it for me?' question often key to getting spending approved for the project. At this stage it is good practice to work with the client to prioritise a list of goals that may become particularly important later if you find you do not have time to meet all the defined goals.
Who are the users?
More detailed user requirements analysis will follow but users must be considered from the start. Can your solution user population be split into differing categories, roles or 'personas'? For example, internal employees and external customers. You might choose to sub-divide external customers further. For example, a user visiting you web site for information and a user visiting your web site to purchase a specific item.
Scope and Vision
Scope and vision are slightly differing concepts. The vision is often broader and more motivational. The scope is defined by the key goals of the project. A simple example:
Vision
To create a world class web application written in .NET that is sufficiently simple and intuitive so as
not to require any training. The application should be responsive, secure and increase users' working
efficiency.
Scope
- Replace the current application.
- Use the corporate intranet.
- Avoid lengthy user training.
- Use the latest corporate standard technologies.
Gap Analysis
A useful deliverable from the Envisioning Phase might be the results of a gap analysis between the current system state (before you implement your solution) and the desired system state (after you implement your solution). This can be simply done in the form of two lists. This exercise will also feed your other deliverables such as scope and problem statement. It should also be shared with stakeholders for validation and agreement.
Defining Success
It may be useful to discuss at these early stages what is meant by success in an IT project as this provides a means to start the negotiations with stakeholders. By common definition a successful project satisfies the three criteria:
Thus we have budget (i.e. available resources), deadlines and functionality to agree on. Of course they are all closely linked – if you pay for double the resources you're likely to get more functionality in a given time or the same functionality in less time.
The client might like to specify all three of the dimensions but it's up to you to tell him or her if the equation isn't solvable with those parameters. There is also a fourth dimension that is often used: quality, though quality and functionality are often related, e.g. if an application crashes every 5 minutes it can't be delivering functionality to users. However, it is frequently worth separating quality as a concept, particularly if you are building an air traffic control application (for example!).
We have our high-level solution proposal and we now need to test its viability against real world constraints, which it may break even at this high level. This can be done from three key perspectives: business, technical and resource. If the assessment reveals any issues then these must be considered before proceeding.
Business
Does the proposed solution address the business objectives it is supposed to solve? You should return to the stated problems and goals and verify one at a time that the proposed solution addresses them. If any aren't met you need to discuss why not and if the solution should be amended accordingly or whether the goal in question was not in fact realistic from a business perspective, e.g. it would cost too much to achieve. Any such changes should be agreed and documented.
At this stage you should also consider the end user again, as you should throughout the project though we'll return to focus on the detail of the user's role a little later. The users are likely to be key to your business objectives being met. Re-consider the problems and objectives focussing on the users at this stage.
Technical
Is the proposed solution feasible from a technical perspective? Has it been done before? This is not usually a big issue, as you will have borne such things in mind when coming up with the solution. That is, unless you have overlooked anything major.
Are you comfortable that it is possible to implement the chosen solution, even at the current high level, given the available technologies and within the constraints the stakeholders have placed on you?
Resource
Here's where we meet the Microsoft Solution Framework (MSF) for the first time. MSF has a considerable amount to say on the subject of resources. MSF is a set of best practices and concepts for designing, building, managing and deploying applications.
Will you have the correct resources available for the project? Microsoft recommends the following 6 roles for a project team:
Note these are roles and in a small team an individual might take on multiple roles, with certain restrictions e.g. your developer should not also be your tester. So you could possibly get by with a minimum of 2 people with appropriate assignation of roles. Whether such a formal approach would be sensible for a 2 person team is a separate issue.
Given the above the key question becomes: 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 is no it is time to renegotiate functionality, deadlines and/ or budget. If this is not an option then the resource issue becomes a 'risk factor'.
If we've reached this stage of envisioning the solution we know the project is feasible. This does not necessarily mean that no risks have been identified but that if there are any they are not insurmountable. At this stage you should identify any risks so that you will be able to manage them effectively during the project and ensure they do not leads to insurmountable issues.
The MSF approach to risk management commences with risk identification. This may entail a brainstorming session with peers and stakeholders. One approach would be to assess risks from the perspective of each of the 6 MSF team roles previously listed. The resultant risks should then be ranked. You may choose to discard lower ranked risks at this stage. Remaining risks should be assigned a meaningful risk statement.
Next comes risk analysis: after ranking the risks subjectively you need to assess their impact objectively. A common method is multiplying the probability that the risk might occur by a value scales presenting the risk's impact in the success of the project. From this exercise MSF recommends creating a top 10 risks lists or approximately 10. If there is a risk that ends up ranked at number 11 you feel strongly about, include it.
Risk Action Planning is the next step; this involves creating plans of how you could manage each risk on your list. This is achievable by 4 key (related) tasks.
You should control your risk by putting in place whatever plans have resulted from the other steps. Another strategy that falls into this area is the creation of a 'proof of concept' application allowing you to prove the riskiest technologies early on. Another way to mitigate risks is via the use of patterns. These are sub-architectures that have been proven to work by others.
Whatever your approach, you should track your list as the project proceeds, perhaps reviewing your top 10 during weekly meetings and acting accordingly.
Completion of the envisioning phases is a major milestone and should be formally recognised and signed off. As with all such formal sign off this should make future change management easier as all parties are coming from an agreed base. However, this is all very high level so far. We have an idea of the big picture but have some way to go into the detail, which may well feed back into the big picture. We next make a start in defining some of the required detail.
Exam Cram 2 .NET Solution Architectures
Cornish et al.
Que
http://msdn.microsoft.com/architecture/