Software Engineering, Project Management, and Effectiveness
We did a focused set of security videos with Keith Brown a while back. The problem is they're not very findable (most customers I talk to aren't aware of them). I added them to soapbox and listed them below to see if it helps (note soapbox may prompt you to log in):
Input and Data Validation Videos
They're designed to help you get key concepts behind some of our security guidance. I also wanted to use somebody that was recognized in the field as somebody you could trust. Keith's proven himself for a long time in the security community. He also has the aura of an experienced trainer, which I think comes across in these videos.
We've used TFS for more than a year, so it's interesting to see what we're doing in practice. If you looked at our source control, you'd see something like the following:
+ Project X version 1+ Project X version 2- Project Y |----Branches |----Releases |----Spikes |----TeamStuff |----Trunk |----Build |----Docs |----Keys |----Source |----Tools
While there's some variations across projects, the main practices are:
I'll be taking a look at how customers and different groups in Microsoft have been using TFs for Source Control. If you have some practices you'd like to share, I'd like to hear them. Comment here or send mail to VSGuide@microsoft.com
When I last met with Rob Caron to walk him through Guidance Explorer, one of the concepts that peaked his interest was test-cases for content. He suggested I blog it, since it's not common practice and could benefit others. I agreed.
If you're an author or a reviewer, this technique may help you. You can create explicit test-cases for the content. Simply put, these are the "tests for success" for a given piece of content. Here's an example of a few test cases for a guideline:
Test Cases for Guidelines
What to Do
Additional Tests to Consider When Writing a Guideline
Benefits to Authors and ReviewersThe test-cases serve as checkpoints that help both authors and reviewers produce more effective guidance. While you probably implicitly ask many of these questions, making them explicit makes them a repeatable practice for yourself or others. I've found questions to be the best encapsulation of the test because they set the right frame of mind. If you're an author, you can start writing guidance by addressing the questions. If you're a reviewer, you can efficiently check for the most critical pieces of information. How much developer guidance exists that does not answer the why or when? Too much. As I sift through the guidance I've produced over the years, I can't believe how many times I've missed making the why or when explicit.
I'm a fan of the test-driven approach to guidance and here's my top reasons why:
Examples of Test Cases for GuidanceI've posted examples of our test-cases for guidance on Channel 9.
The ASP.NET 2.0 Internet Security Reference Implementation is a sample application complete with code and guidance. Our purpose was to show patterns & practices security guidance in the context of an application scenario. We used Pet Shop 4 as the baseline application and tailored it for an internet facing scenario. The application uses forms authentication with users and roles stored in SQL.
3 PartsThe reference implementation contains 3 parts:
The purpose of each part is as follows:
Key Engineering Decisions AddressedWe grouped the key problems into the following buckets:
These are actionable, potential high risk categories. These buckets represent some of the more important security decisions you need to make that can have substantial impact on your design. Using these buckets made it easier to both review the key security decisions and to present the decisions for fast consumption.
A final PDF is now available for our patterns & practices Application Architecture Guide, second edition. This is our platform playbook for the Microsoft application platform.
Here are the relevant links:
Here are some of my related posts:
Change happens. One of the many things Ward Cunningham taught me years ago was that Agile isn't about fast. It's about "responding to change." It's the Agile way.
I thought it was great that rather than pretend change doesn't happen, simply embrace it.
Simplicity was another aspect that I found compelling. Ward had a way to keep things simple. If something felt heavy or complicated, he would cut right through -- "What's the simplest thing we can do now?" Rather than get overwhelmed or lost in analysis paralysis, he simply decides to take action.
I remember thinking how sweet it is to put your burden down, and travel light.
One burden for me was all the stuff that was yet to be done. The other burden was all the stuff that might matter someday. The problem is, how do you plan for what you don't know or can't expect? You don't. Instead, you figure out the most valuable thing now to work on, and when you come to a bridge, you cross it. When there's no bridge, you build one. If that becomes the next most important thing now.
The sense of now vs. someday maybe is important. There's something empowering about knowing that you're on the right path, and that the path you're on flows value -- to yourself, for others, or whatever matters. Mistakes turn into lessons, and success builds momentum. Paving a path of value down a road of learning and responding beats betting on a map that no longer works or is no longer relevant.
Speaking of relevancy, time changes what's important. All the things we think we know, and all the things we thing we want, don't always match what we find, once we're there. The ladder may be up against the wrong wall, or the grass isn't any greener. In fact, sometimes there's no grass.
The irony is, the trip is lighter when we don’t carry the burden, and the trip mean more when we know it matters. If we don't enjoy the journey, and we don't end up with what we want, what's the point? Life's short. Throwing your time and energy down a path should matter. But, how do we carve out these paths that matter?
Stories. Stories help you find what matters. I remember the first time Ward asked me to tell him a story. He wasn't looking for once upon a time. No, he wanted to explore and test possible paths. He wasn't interested in a laundry list of requirements. He wanted a simple story told from the user perspective of a single, meaningful goal. We used the whiteboard and mapped out one scenario. Disney would have been proud.
This one chunk of value was compelling. The story put things in context. The flow made sense. Value was obvious and explicit. More than that, it was testable. A testable chunk of value. We could test whether it mattered, and we could test whether it was feasible. We could even test the risk early and reduce the gap from what we know, don't know, and need to know next.
Having a story helped us do a dry run. The dry run produced immediate feedback. Feedback is a good thing, and it supports learning and responding, the Agile way.
All this goodness in approach, painted a better picture, of a better way forward. Rather than over-engineer up front, or over-plan for some day maybe, start flowing value now. Rather than travel with burden and assumptions, travel lightweight and sustainable. Rather than fear change, allow for it, and embrace it – be adaptable. But does this approach to work, also work for life?
I asked Ward how he did his career planning and figured out his year ahead. He said he simply works backward from the experiences he wants. He writes his story forward, by focusing on the experiences he wants to create. He leads an experience-driven life. What a simple, yet elegant, and insightful approach. What an empowering way forward.
The journey is the trip and the destination. It's the way we travel and it's the end in mind. It's the Agile way.
This is why my latest book is Getting Results the Agile Way.
As part of our patterns & practices Azure Security Guidance project, we’re putting together a series of Application Scenarios and Solutions. Our goal is to show the most common application scenarios on the Microsoft Azure platform. This is your chance to give us feedback on whether we have the right scenarios, and whether you agree with the baseline solution.
ASP.NET Security Scenarios on Windows Azure We’re taking a crawl, walk, run approach and starting with the basic scenarios first. This is our application scenario set for ASP.NET:
ASP.NET Forms Auth to Azure Storage
Solution Summary Table
ASP.NET Forms Authentication to SQL Azure
ASP.NET to AD with Claims
ASP.NET to AD with Claims (Federation)
It's a platform, a playbook, and a language for application architecture.
At a high level, that's how I think about our patterns & practices Application Architecture Guide and Application Architecture KB.
The work has become a focal point both internally and externally as a playbook for the Microsoft application platform. It’s less of a guide, and more of a platform. Essentially, we’ve framed out a durable, evolvable backdrop for application architecture that we can build on in terms of products, tooling, services and experiences. I get daily/weekly mails from folks inside and outside the company that want to align their efforts with the frames and approach.
I think of the frames as collection of hot spots. The frames help cut through information overload and provide a common mental model. They also help identify hot spots in architecture and design that are opportunities for improvement. They also help map existing bodies of pattern work to relevant decisions that shape applications.
Here's a few data points that I think highlight the impact:
We created a Web Application with Domain Entity Application Pattern as part of our patterns & practices Application Architecture Guide 2.0 project. The purpose is to show a baseline architecture based on patterns.
Scenario Here's the backdrop we use for the baseline architecture:
Pattern Solution Here's our pattern overlay:
Tech Solution Here's our technology overlay:
Application Pattern You can review the full application pattern on CodePlex at:
Chapters At a Glance Here’s the chapters at a glance:
My Related Posts
How do you choose among the Microsoft .NET presentation technologies? Use scenario-based evaluation. At the end of the day, a technology is a set of capabilities. Map those capabilities to your scenario and requirements. OK, great, but where do you start? That's where our cheat sheet comes in. As part of our Application Architecture Guidance 2.0 project, we created a cheat sheet to help you quickly find your way through the technologies:
Cheat Sheet – Presentation Technology Matrix We posted our latest cheat sheet to CodePlex:
Presentation Technologies Here’s the technology combinations that we identified, evaluated and cataloged:
That’s a lot of options, but that’s a good thing. In a mature market, expect lots of options and specialization. This helps you use the right tool for the job. The challenge, of course, is knowing which one is the right tool, but that’s where our cheat sheet should help. Ultimately, the cheat sheet is a support aid and doesn’t replace your own thinking or analysis. Instead, it helps you consolidate some key information on the technologies, and help you consider some of the benefits and considerations.
Organizing the Technologies To organize the technologies, we use a simple frame:
By pinning the technologies against common application types (Mobile, Rich Client, RIA, and Web App), it made it very easy for us to slice and dice the technologies by relevancy, capabilities, and scenarios.
How We Created the Cheat Sheet
We started from a base set of application types and scenarios. We vetted from experience among the p&p development team. Next, we reviewed with various product team members, including Brad Abrams, Pat Helland, Glenn Block, and Ian Ellison-Taylor. Next we vetted with some customers. It’s a work in progress and we’ve been through several iterations. In fact, the version we posted today is version 35. Now it’s time to share with a broader community.
My Related Posts
I added a brief over deck of our patterns & practices App Arch Guide 2.0 project to codeplex:
It's actually a pretty fast slide deck. The first handful of slides give you a quick overview of the project goals and scope. The appendix is all visual. You can flip through and see how some of the key parts of our story are unfolding.
We posted an early draft of our guidelines for the following areas:
You can browse our set of guidelines from our Guidelines Index page.
This is part of our patterns & practices App Arch Guide 2.0 Project.
“Life is like skiing. Just like skiing, the goal is not to get to the bottom of the hill. It’s to have a bunch of good runs before the sun sets.” – Seth Godin
It's been a good run. After more than 10 years in patterns & practices, I'm on to my next adventure here at Microsoft.
For this post, I wanted to take a stroll down memory lane. During my time at patterns & practices, I learned more about project management, application architecture, software development, processes, teamwork, leadership, product success, and making impact than I think I could have ever hoped to learn anywhere else. Perhaps the best part, is that I have 10+ years of deliberate practice in the art of “best practices” and I’ve had a chance to work with some of the most amazing people in the industry, lead SWAT teams around the world on fantastic voyages and epic adventures, and leave a legacy of several high-impact Microsoft Blue Books, all while mastering the art of prescriptive guidance.
There are a few ways I can share my journey in patterns & practices. One of my managers referred to me as “the abilities PM” because of my focus on quality attributes (security, performance, scalability, etc.) and that’s a pretty good place to start. My role as a PM (Program Manager) in patterns & practices, can largely be defined in terms of my impact on these three areas: security, performance, and application architecture. (Yes, there is more to the story, but those three areas, serve as a good enough lens for now.)
The Security Story It all started when I joined patterns & practices (PAG or the Prescriptive Architecture Guidance team at the time.)
I moved from Microsoft Developer Support with the expectation that I would share and scale broadly with customers what I learned from living in across the hall from folks like Scott Guthrie, Brad Abrams, and other .NET Framework leaders. Having performed more than 650 customer architecture and design reviews, I was in a unique position to share all the principles, patterns, practices, and anti-patterns that I had seen across a large number of customer projects, many of which were on the leading and bleeding edge of this space.
But life has a way of throwing curve balls. Around this time, security was Jim Allchin’s top priority, and he asked patterns & practices what we were going to do about security. In turn, my manager asked me, what I was going to do about security. Coming from a middleware background, security was something I was usually trying to work around, especially when I had to flow callers to the backend. My new challenge was to design security architectures for our application platform on .NET. Boy, was I in for a ride.
I knew security was the name of the game, but I had a lot to learn in terms of leading project teams around the world, brokering in all the right parts of the company, our community, and the industry. I also had a lot to learn in terms of how to create prescriptive guidance. The purpose was not to just put out a book. The purpose was to drive customer success on the platform. This included creating a durable, and evolvable security story that our customers could build on, and that we could use to “train the trainers.” This also meant creating a knowledge base that we could use as an anchor for driving product feedback and platform change. This was all in addition to learning how to think about security from an architecture and design standpoint, in a way that could help customers build more secure applications.
And thus the first Microsoft Blue Book, Building Secure ASP.NET Applications, was born. It was our answer to IBM Redbooks.
While I learned a lot from doing end-to-end security architectures and putting our variety of products and technologies together, the real learning came from driving Improving Web Application Security, or “Threats and Countermeasures”, as we affectionately called it. This journey was about learning how to bridge the gap between architecture and design, development, test, and operations. It was about learning how to think about security from a threats, attacks, vulnerabilities, and countermeasures perspective. It was about thinking about security in a more holistic way, and our little mantra was “secure the network, host, and app.”
We had the ultimate security dream team, on mission impossible, and we pulled it off. Our core engineering team included Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan, and we had an extended team of industry champs including Joel Scambray of the Hacking Exposed series. (In fact, check out the extensive team list at the bottom of our Threats and Countermeasures Landing Page.)
How do I know we pulled it off? We had outstanding results in our platform security competitive study, and we were told that is was our prescriptive guidance that made the difference in a very big way. In addition, our guide was downloaded more than 800,000 times in the first six months, and it quickly established the mental models and language for how our growing customer base thought about security on the .NET platform. It was a powerful thing when customers would say to us back in our language, “We’re using the trusted subsystem model …” It was like poetry in motion.
The big thing we learned from the journey was the power of having end-to-end application scenarios, along with maps of threats and countermeasures, while baking security into the life cycle, and using proven practices, like threat modeling, to significantly change the game.
Here are some of the key security deliverables at a glance from the various security adventures over the years:
This doesn’t include the product feedback work we did, or the work we did to bake security into Visual Studio / MSF Agile, or the patents we filed, which were the icing on the cake. As a sidenote, behind the scenes we called our “threats and countermeasures” guide “WOMA.” It was short for weapon-of-mass adoption, because our field was continuously telling us stories of how they were winning accounts against the competition.
The Performance Story Performance was right up my alley, but it was a significant shift from security.
Ironically, I got a lot better at tackling security, by learning more about performance. The big lesson I learned was that you have to bound or constrain your efforts in some way. Just like performance can always be improved, so can security, so it’s all about prioritizing, knowing where to focus, and connecting back to the business objectives, aside from the technical perspective, and user experience.
Our first epic adventure in the performance space was the guide, Improving .NET Application Performance and Scalability (or, “Perf and Scale” as we affectionately called it.) It was where I first got to work with folks like Rico Mariani, Jan Gray, and Gregor Noriskin. It was mind blowing.
Working on performance and scalability was probably the most technically challenging exercise I’ve had at Microsoft. I remember spending countless days and nights walking through CLR internals, figuring out how to optimize collections, sorting through multi-threading patterns, and mastering how garbage collection really worked. Strangely enough, the “ah-ha” that I appreciated the most was figuring out that we could think of performance in terms of response time, throughput, and resource utilization (CPU, memory, network, and disk.) That little lens was the key to figuring out how to do effective performance modeling and solving nasty performance bottlenecks. It also helped us parse complicated performance scenarios down into bite-sized chunks.
Here are some of the key performance deliverables at a glance from the various performance adventures over the years:
While performance took me to the depth of things, it was application architecture that took me to the breadth of things …
Application Architecture Creating the Microsoft Application Architecture Guide was a chance to pull it all together.
It was a chance to finally showcase how to put our platform technologies together into common application archetypes. Rather than just a bunch of technologies, we could talk about our application platform very specifically in terms of application types: Web applications, RIA applications, desktop applications, Web services, and mobile applications. We could talk about scenarios and trade-offs. We could look at the shapes of applications in terms of architectural styles and patterns. We could look at cross-cutting concerns, such as caching, communication, concurrency, configuration management, data access, exception management, logging, state management, validation, and workflow. We could also walk the various quality attributes, like performance, security, reliability, manageability, usability, etc.
As you can imagine, this meant putting together a comprehensive map of our Microsoft application platform. The surprise for me was that by putting together the map and looking broadly at the industry, it was easy to see the forest from the trees, as well as better understand and anticipate where the industry was going in terms of what was growing and what was dying. It was a great way to get ahead of the curve. In fact, I’ve continued to map out our Microsoft application platform each year, as a way to quickly see the forest from the trees and to figure out where to spend my time.
During my adventures with application architecture, I got to learn a lot and work with amazing people. I also learned how to go across a lot of information faster and easier, and bring teams of people along the journey. The secret was to keep creating maps that helped everybody get on to the same page fast. This was an invaluable approach as our team was hunting and gathering all the pattern collections we could find. We basically built a large catalog and constellation of application patterns in the form of maps. While we didn’t include our maps in the guide, they helped our team and extended team ramp up in various spaces very quickly, as well as advance the practice of application architecture. Basically, we could browse patterns of solutions at a glance.
If you read nothing else, check out A Technique for Architecture and Design. Behind the scenes, we created this technique by synthesizing the expertise of more than 30 top solution architects, that had years of experience with structuring and designing end-to-end applications, dealing with security, performance, and reliability issues, and dealing with cross-cutting concerns. The idea was to put down on paper, a proven practice for rapidly modeling applications on a whiteboard and identify risks earlier vs. later.
What’s Next? I’ll have more to share as I go along. What you’ll most likely see is a shift to more focus on strategy, execution, and business impact. I’ll also share more information on the art and science of program management. I’ve been mentoring a lot of people and I think the PM role at Microsoft is a very special one. One of my mail goals is to broadly share the lessons I’ve learned from driving projects and leading teams and making impact as a PM on the patterns & practices team.
patterns & practices Guidance at a Glance Meanwhile, here is my catalog of patterns & practices guidance at a glance. Note that a lot of the prescriptive guidance I’ve worked on is out of date because of changes in technology. That said, you can still learn many of the key principles, patterns, and practices that the guidance is based on. In this respect, much of the guidance is “evergreen” in that it’s timeless and durable.
Developer Guidance Maps
Books / Guides
Practices at a Glance
Threats and Countermeasures
Questions and Answers
ASP.NET Security How Tos
WCF Security How Tos
Visual Studio Team System
Value Realization is hot. You can think of Value Realization as simply the value extracted from a process or project.
Business leaders want to understand the benefits they’ll get from their technology solutions. They also want to see the value of their investment deliver benefits and deliver real results along the way. And, of course, they also want to accelerate adoption so that they can speed up their value realization, as well as help avoid “value leakage".”
But how do you actually do Value Realization in the real world? …
This is a guest post by Blessing Sibanyoni. Blessing delivers advisory, IT architecture, and planning services to Microsoft’s top enterprise customers within the financial services sector. He has more than 17 years of experience in the IT field. He is currently an Enterprise Architect and Strategy Advisor on behalf of Microsoft Corporation.
As an Enterprise Strategy Advisor, Blessing helps organizations achieve challenging business and organizational goals. He does so by helping them leverage value from their current and future investments, enabled by technology. Blessing has a solid record of delivering large and complex initiatives within organizations while always doing this in a mutually beneficial way. You can connect with Blessing Sibanyoni on LinkedIn.
Without further ado, here’s Blessing on Value Realization …
Often we grapple with the notion of value. At first it seems like a very simple thing but when you really take time to consider it, you realize how complicated and multi-dimensional it becomes. Take a simple example of a person who follows a methodology, based on best practices, who crosses all the t’s and dots the i’s but at the end of the day experiences a failed project or is unable to reach goals that his customers appreciate. Or perhaps, what about the notion of another who is highly intelligent but working for someone far less “intelligent” from a credentials or even IQ perspective.
What has happened here?
Why do these paradoxes occur and how do you ensure you are not ending up experiencing the same?
I would argue that at the heart of these conundrums is the notion of value. Value is the worth of something in terms of the amount of other things for which it can be exchanged. Often it’s not about inputs but rather outcomes and many state that you cannot achieve it without effecting a transformation. The transformation itself can be virtual or manifested in the real world, but for true value to be derived, transformation in whatever form, must transpire.
For transformation to transpire a real pain must be felt.
After spending almost two decades in public and private enterprises, I’m still intrigued by why organizations decide to spend resources on some things and not others. Often it’s the thing that seem to make the least sense which these organizations decide to put all their resources into.
This curiosity is one that lingers on especially realizing that resources are often limited and logically, one would naturally be better positioned by focusing on projects or initiatives that offer more returns and deserve more attention. One could take the cynical view that common sense is not so common, or the perspective that organizations are made of people, and people are irrational and fallible beings that bring their own biases into every situation.
So the notion of value then or the expectation of what will bring value is often subjective and largely determined in the eye of the beholder.
I have met many stakeholders who are more interested in the qualitative rather than the quantitative. Surprisingly, this is true, even in financial services!
Giving such people a quantitative, seemingly logical justification is often destined to result in failure, and the converse is also true. So, knowing your stakeholders, what drives and resonates with them is more important that coming up with a definitive, objective, rational and quantitative hypothesis in order to convince them to take some action.
Recently I was fortunate to have worked with a senior executive who was very financially inclined with a major focus on bottom line impact. This stakeholder did so well in the organization that he was soon promoted. To my surprise the person who replaced him was much more people oriented and his biggest concerns were around how the changes proposed would impact people within the organization. The new stakeholder’s view was that people came first and happy employees result in a positive bottom line effect.
I believe both execs had a great view, even though it seemed that their perspectives were fundamentally different.
The key for me was to ensure that both qualitative and quantitative arguments were well prepared in advance so that we could tell compelling stories that drove the agenda regardless of the different concerns and viewpoints.
Knowing your industry and thinking ahead about what your stakeholders may not yet know that they need or desire, is also a very valuable thing to do.
Think about the world of tablet computers that nobody knew they needed just a few years ago, yet these things are now taking the world by storm...
At the beginning I spoke about blind implementation of a methodology being a less than great thing, I would argue that the following steps make great sense around realizing that value, in the eye of the beholder:
Paul Lidbetter on Value Realization
Martin Sykes on Value Realization
Mark Bestauros on Value Realization
Graham Doig on Value Realization
What you don’t know can hurt you. Sometimes the world can change under your feet and you never saw it coming. I like to anticipate and stay ahead of the curve where I can. As part of our patterns & practices Application Architecture Guide 2.0 project, I’ve been hunting and gathering trends that influence software development. Rather than make this exhaustive, I wanted to share "good enough" for now, and leave you room to tell me what I've missed and share what you’re seeing in your world.
Key Notes On Trends
Trend "Hot Spots" Rather than distinguish between trends and fads, I decided to focus on “hot spots” and simply identify the topics that keep showing up in various contexts with customers, in Microsoft, in the industry, … etc.
I know the list looks simple enough, but it actually took a bit of vetting to spiral down on the ones that have wood behind the arrow and have signs of a trajectory.
David Chou on Trends ... In this post, Cloud Computing and Microsoft, David Chou identifies the following trends:
Simon Guest on Trends ... In his talk, An Architectural Overview of Software + Services, Simon Guest outlines the following industry trends:
Simon connects the dots from the trends to how they support Software + Services:
Phillip Winslow on Trends … In an Interop Keynote Panel on Current Software Trends, Phillip Winslow responded to the to please predict the biggest IT story for 2008 as follows:
“ … decoupling of the end user platform. Virtualization and desktop virtualization and layering on SAAS… Salesforce.com, gmail, etc how we think about the desktop sitting on our desk will be much different.”
“ … decoupling of the end user platform. Virtualization and desktop virtualization and layering on SAAS… Salesforce.com, gmail, etc how we think about the desktop sitting on our desk will be much different.”
TrendWatching.com on Trends ... Here's a snapshot of interesting tidbits from a an earlier version of this trend report page on TrendWatching.com:
Here's the cool part. I saw GREEN on their page well before I noticed any of the Green IT initiatives show up. It struck me as an example of consumer influencing Enterprise.
Key Posts Here's some of the posts that I found to be useful for understanding the impact and influences behind some of the trends:
Additional Resources I know this looks like a laundry list of links but these are actually helpful to quickly get what some of the topics are about:
Here's a brief set of success patterns I've shared with a few colleagues. These are the patterns I see that make a difference in getting results.
10 Success Patterns
Success Patterns ExplainedHere's the essence of each:
Do you have any favorite success patterns to share?
My Related Posts
If you're building Web services or if you're implementing SOA on the Microsoft platform , then you're probably either working with or exploring WCF (Windows Communication Foundation.) When we started our patterns & practices WCF Security Guidance project, one of the first things I did was compile a list of WCF security resources for our team. This helped us quickly ramp up and as well as see gaps. One thing that surprised me is how much is available in the product documentation, if you know where to look. Here's a preliminary look at our WCF Security resources index which we'll include in our WCF Security Guide:
Documentation (MSDN Product Documentation)
patterns & practices
Product Support Services (PSS)
MSDN Support WebCasts
In my previous posts I showed layers and components, and layers and tiers. In this post, I'll show the services layer in a layered architecture.
Services LayerHere's a visual example of a services layer, where the application is exposing services:
Note that services don't need to be "web" services.
Key Services Layer ComponentsHere's the key components of a services layer:
We created an initial set of Application Patterns as part of our patterns & practices Application Architecture Guide 2.0 project. The purpose of the application patterns is to show a skeletal solution for common end-to-end applications. Each application pattern includes a scenario, a pattern solution, and a technical solution. This provides you with a relatively stable backdrop and starting point to reuse lessons learned from successful applications.
Application Patterns Here's our initial set of application patterns:
Example Application Pattern The heart of each application pattern revolves around the scenario, the pattern overlay, and the technology overlay:
Tech Solution Here's our technology overlay:
Application Pattern Template Here's the core structure of each application pattern:
At Microsoft, I learned to keep my energy strong while making things happen. The best ways I’ve found to do that are follow my growth and follow my passion. Another way, that’s very important, is to play to my strengths. Spending time in my strengths is the key to hitting the high notes and getting exponential results. It keeps me strong, my energy high, and produces more impactful results in less amount of time.
Whenever I find myself drained, all I need to do is take a look at where I’ve been spending my time. Sure enough, it’s always from spending too much time in my weaknesses and not enough time in my strengths. That’s the interesting lesson too … I can spend more time in my weaknesses, as long as I’m spending enough time in my strengths.
By strengths, I’m not talking about the skills I’ve learned. I’m talking about my natural strengths – the ones that I can count on no matter what. I didn’t find my strengths over night and it’s a continuous process of gaining clarity and precision. The key here is knowing the language. When you know what to look for, it’s easier to find your own strengths, label them, and use them to your advantage.
34 Key Strengths Marcus Buckingham and Donald O. Clifton, Ph.D. identified 34 key signature themes of strength. I have a brief description of each strength in my post, Finding Your Strengths. Here are the 34 signature themes:
24 Signature Strengths Martin Seligman named a set of 24 Signature Strengths. You can find out more about Martin Seligman’s work at the Authentic Happiness Center. Here are Seligman’s 24 Signature Strengths:
How To Use These Strength Vocabularies One way to use these is to take their tests and find out what they say about you. I do like the fact that they have framed and named the strengths which makes it easy to explore, test, and evaluate. Personally, I’ve found more value by simply exploring the labels and using them as lenses. I’ve been rationalizing them against the Myers-Briggs Type Indicator (MBTI) as well as my own frames for strengths, looking for underlying patterns and practices.
At the end of the day, the most important thing for me has been finding where I get energy from, and finding what takes it away. This leads me to a personalized strengths frame that I can use as a lens for investing in my portfolio of strengths … and this is the key to exponential results.
I like competitive studies. I'm usually more interested in the methodology than the outcome. The methodology acts as a blueprint for what's important in a particular problem space.
One of my favorite studies was the original @Stake study comparing .NET 1.1 vs. IBM's WebSphere security, not just because our body of guidance made a direct and substantial difference in the outcome, but because @Stake used a comprehensive set categories and an evaluation criteria matrix that demonstrated a lot of depth.
Because the information from the original report can be difficult to find and distill, I'm summarizing it below:
Overview of ReportIn June 2003, @Stake, Inc., an independent security consulting firm, released results of a Microsoft-commissioned study that found Microsoft's .Net platform to be superior to IBM's WebSphere for secure application development and deployment. @stake performed an extensive analysis comparing security in the .NET Framework 1.1, running on Windows Server 2003, to IBM WebSphere 5.0, running on both Red Hat Linux Advanced Server 2.1 and a leading commercial distribution of Unix..
FindingsOverall, @stake found that:
Approach@stake evaluated the level of effort required for developers and system administrators to create and deploy solutions that implement security best practices, and to reduce or eliminate most common attack surfaces.
Ratings for the Evaluation Criteria
Scorecard CategoriesThe scorecard was organized by application, Web server and platform categories. Each category was divided into smaller categories to test the evaluation criteria (best practice compliance, implementation complexity, quality of documentation, developer competence, and time to implement).
Application Server Categories
Host and Operating System Categories
Web Server Categories
More InformationFor more information on the original @stake report, see the eWeek.com article, .Net, WebSphere Security Tested.
In my 30 Day Improvement Sprints post, a reader asked, what tips do I have to make 30 days sprints more effective. Here's my short list
Few problems withstand sustained focus. There's a bit of captive genius in everyone that just needs to be uncorked. 30 days of focused improvement seems to be a great way to pop the cork. I'm finding improvement sprints refreshing because I now have a schedule for exploration. I can rotate through more interests. Most importantly, rather than tackle everything all at once, I just wait for my next 30 day focus. It's easier to put something aside for the moment, if I know I'll have a chance to immerse myself in it in the future. If I enjoyed something so much and I want to continue, I just do another 30 days.
Hope that helps!
You can now find our patterns & practices Team Development with Visual Studio Team Foundation Server guide on MSDN in HTML. It's the same guidance we hosted on CodePlex. CodePlex was our channel for agile release. Once we baked the guidance, we ported to MSDN. For some customers, MSDN is a trusted source, so being on MSDN is important. Additionally, MSDN provides some additional hooks and channels.
Contents At a GlanceHere's the guide at a glance
DownloadYou can download the Team Development with Visual Studio Team Foundation Server Guide from CodePlex.
Guidance Explorer ScenarioIf you want to tailor the guidance for your scenario, you can download Guidance Explorer from CodePlex. Using Guidance Explorer, you can create custom views by dragging and dropping the relevant guidance and then tailoring it as you see fit. You can then save your view or an item to Word or HTML.