How to Authenticate Web Users with Windows Azure Active Directory Access Control is an easy task, if all steps are mentioned. Besides, a video shows often more than pictures can make clear. That's why I made a video wherein I make this principle of using more identity providers for an MVC application really work. It'll start with one video with the overall picture.
If I think some things should need more focus, I will add videos. The video is companioned with an internet address with the text backing up the video. This text doesn't have the critical step to make all things work, which step you WILL find in the video.
"per aspera ad astra! "
Windows Azure PowerShell is a powerful scripting environment that you can use to control and automate the deployment and management of your workloads in Windows Azure. Whether you are experienced with Windows PowerShell or a new user, instructions are available to help you get started provisioning virtual machines, setting up virtual networks and cross-premises networks, and managing cloud services in Windows Azure.
Before you can start using the cmdlets in Windows Azure PowerShell, you will need to download and import the module, as well as import and configure information that provides connectivity to Windows Azure through your subscription. For instructions, see Get Started with Windows Azure Cmdlets.
To get started with the Windows Azure module for Windows PowerShell, you’ll need to:
A Windows Azure management certificate is an X.509 v3 certificate used to authenticate an agent, such as Visual Studio Tools for Windows Azure or a client application that uses the Service Management API, acting on behalf of the subscription owner to manage subscription resources. Windows Azure management certificates are uploaded to Windows Azure and stored at the subscription level. The management certificate store can hold up to 100 certificates per subscription. These certificates are used to authenticate your Windows Azure deployment.
"aut viam inveniam aut faciam"
Before you start working on something, it is essential to have a ticket system like Jira, TFS or the like. Before you choose a ticket system or issue tracker, it is important to define for what you will be using it. TFS for example is mostly focussed on Software Development projects, while Jira is more focussed on overall issues which are more related to processes on a higher level.
This is not a blog about the differences between these ticket applications, but it is about telling you that such a system is essential for work tracking. Without it, you swim in the dark and the project manager, supplier, contractor and client are not able to get the proper insight in what needs to be done, what is already done and are we getting the work done in time, with the given resources and with the given budget.
Often I see Excel sheets, documents, email and what not, miss used for issue tracking. If you are in such a situation; be sure of the fact that you have blind spots and you are not aware of all the work done and work coming your way. In other words, you are throwing away money, which belongs to the client.
As a contractor it is your responsibility to always make it for the client as transparent as possible what you're going to do, what the workload is, what can be done with whom and for what money. Some sort of an issue and work item tracker is in such cases indispensable.
Doing without it is hiding your work behind curtains. The client can be sure that the work done, being done and must be done will stay in the dark and its money is used in some sort of gamble.
I give you some links to TFS and Jira, as examples. You can relate these example to other programs alike.
I do not believe in gurus. But Brian Keller is a guy I respect a lot for the contributions he did on the topic of Software Development Life Cycle Management with TFS. Check him out and stick with the guy.
Brian Keller on TFS and SDLMS
Scrum at Microsoft: See the TFS Agile Team do a Scrum
Jira in a nutshell
Jira tutorial for beginners
Jira tutorial video
Jira to improve visibility and productivity
"perfer et obdura; dolor hic tibi proderit olim"
More often nowadays I see it happen that suppliers who fight for a contract give presentations which in short suck. More often nowadays I see it happen that the clients are not fully aware that those presentations suck. And more often nowadays I see it happen that the supplier who gets the job doesn't get the job done because its presentation and thus its insights did - indeed - suck.
How can we be sure that the supplier knows what it must do and what the project consists of? In the old days we used the good old (Nesma) FPA to check the amount of function points of a system to build. In these days I do not see this happening anymore, only within the really big projects. But everything under the million seems to be target for sloppy planning.
How can a supplier be sure how much time it takes to build something without proper function point analysis? I used to work a lot with Cocomo II. It's not the holy grail but what it did and had was analyzing a projects function points compared to a big database wherein we could find similar projects. True, if you didn't know what you was doing, the outcomes sucked also. But, if you knew what you were doing, the outcomes were very interesting.
You can do FPA at three levels: indicative, global and detailed. When project managers came to me for estimations about projects, I gave them three plannings. I gave them an indicative, global and detailed FPA planning on the discovered function points of a system. These function points were surrounded by the Cocomo constructive cost model elements based on function points and the proper chosen programming language.
Indeed, this does not give you the certainty that the planning 100% fit the bill, and often the project managers were choosing the indicative to communicate with the client. But, it is far more responsible than what I see happening in these times. They come up with global Use Cases, Story points, System parts and what not and start doing the math on these very global functional system elements. People, that is not enough.
To be honest: I use Use Cases and User Stories myself all the time. Also to get a clear picture of the system to build. A nice document about this way of estimating your to build system is included in this post. But, it is not enough. Although this guy Clemmons is doing a real nice job, I prefer to go a bit deeper and take the defined Use Cases and split them up in function points; whether they be indicative, global or detailed. This gives them a more realistic body.
Having said this I think that it must be clear by now that the planning of the system to build is a serious business and not something you can do in a global functional and commercial presentation. It is not enough when a supplier answers the project questionnaire all positive. That gives us not enough proof that they understand what they have to do. At least we want the suppliers to have a clear picture of the complexity of the system to build and the knowledge of how many functional elements the system has.
Another very interesting thing is the quantitative risk analysis for project managers. Included is a paper about it. This paper is the final report of the RAND Internal Research and Development (IR&D) project “Risk Management and Risk Analysis for Complex Projects: Developing a Research Agenda.” The aim of the
project was to survey how quantitative risk management and risk analysis methods were applied to the planning and execution of complex projects, particularly those which planned to utilize new and untried technologies. One recent RAND study indicated that such methods, while widely advocated, were not used to plan and manage a critical government satellite development project. This paper recommends several research areas in which RAND could contribute to evaluating the utility of these methods and improving their applicability.
Document : rand_wr112.pdf (included)
What it shows you is that this quantitative risk analysis means serious business and especially when things are new. When I relate it to SharePoint and Azure for example, then we are talking about new things. When we rig up complex Azure SharePoint farms, combined with BizTalk Azure farms and Navision Azure farms which are interconnected with on premise farms with interconnected AD's, databases, resources and what not; then we are talking about serious business. It is incredible to realize that many suppliers approach these kinds of projects without doing the proper FPA, UCP or quantitative risk analysis.
To round things up, I found a nice document about integrated qualitative and quantitative risk analysis of project portfolios submitted for the "Enterprise Risk Management Symposium"of April 2013 in Chicago. Project portfolio risk management and risk analysis is one of the critical components of ERM. Organizations measure and analyze risks associated with projects, project portfolios, and programs. Such risks can be related to project schedules and affect project durations, completion dates, costs, resources, success rates, etc.
Document : erm_2013_paper_virine.pdf
This integrated qualitative and quantitative risk analysis should somehow be related to upcoming projects for organizations. Just as you can do an indicative, global and detailed FPA or UCP planning; you can also do a indicative, global or detailed integrated qualitative and quantitative risk analysis which depend on the complexity of the project. Not doing it at all is asking for trouble and makes the project more a gamble. The outcome of the project in such a case is more like a poker game of black jack. Don't be surprised if you loose and get hurt.