Software Engineering, Project Management, and Effectiveness
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.
My Related Posts
As part of our patterns & practices App Arch Guide 2.0, I put together a short list of resources I want to make sure my team is spending time in:
As far as some community sites, here's a short list of ones I've found helpful:
What's your favorite haunts for architecture nuggets?
I'm a fan of scenarios. Whether you use scenarios for scenario-driven development, scenario-based evaluations, competitive assessments or for shaping products ... scenarios are where the rubber meets the road. I think scenarios are particularly effective for evaluating architectures and for making architecture trade-off decisions. I wrote a short post on Shaping Software that reiterates a mantra I frequently use ... you can't evaluate architecture in a vacuum.
Today we posted our Arch Frame to CodePlex. Wednesdays are ship days (I don't ship on Fridays.) The App Arch Frame is a collection of hot spots you hit when building line of business (LOB) applications. The key to the buckets is that they organize actionable principles, patterns, and practices. They also help us overlay patterns & practices solution assets. You give feedback either in the comments here, or on the CodePlex page:
A few people have asked me for an abstract on the patterns & practices Application Architecture Guide 2.0 project (a work in progress). Here it is.
Conceptual Framework A picture is worth a thousand words. Here's the conceptual framework for the guide:
Tagline
"How to put the legos together"
Abstract The purpose of the Application Architecture Guide 2.0 is to improve your effectiveness building applications on the Microsoft platform. The primary audience is solution architects and developer leads. The guide will provide design-level guidance for the architecture and design of applications built on the .NET Framework. It focuses on the most common types of applications, partitioning application functionality into layers, components, and services, and walks through their key design characteristics.
Key Features
Key Scenarios
A few of my mentees mentioned that I'm not posting enough about effectiveness on my MSDN blog. That's true. I'll be posting more on effectiveness in the near future. Meanwhile, I've been posting insights and actions for work and life on Sources of Insight. It's how I scale myself and how I create reusable nuggets for my mentees. Sources Of Insight is one month old. Although the blog is only a month old, I ported my nuggets from my earlier blog, The Bookshare. There are more than 250 nuggets that will help you improve your life. Each nugget is carefully crafted to help you turn insights into action and improve your effectiveness.
As part of our patterns & practices App Arch Guide 2.0 project, we've put together an arch frame. The arch frame is simply a collection of hot spots. These aren't just any hot spot though. These hot spots represent key engineering decisions, anti-patterns, and opportunities for improved designs for more effective technical architectures. This Arch Frame is part of the larger App Arch Meta Frame. Think of it as an important branch off the main tree. It serves as a lens to cut through a lot of information to get to the most meaningful and actionable guidance.
Categories The following categories are the "hot spots" in the architecture frame:
What you might notice about the hot spots is that they map to common cross-cutting concerns when building applications. You also might notice that the hot spots map to various patterns & practices solution assets. For example, Enterprise Library includes blocks for caching, data access, exception management, logging, validation ... etc. The categories also map to very actionable decisions where you there's relevant principles, patterns, and practices. These buckets also contain many anti-patterns. The worst anti-patterns are the "do overs." Nobody wants a "do over" architecture.
Key Engineering Decisions This table summarizes the key engineering decisions within each hot spot:
Key Issues This table summarizes the key issues within each hot spot:
Key Guidelines This table summarizes the key guidelines within each hot spot:
How To Provide Feedback We're still banging through the frame. There's some rough spots. We want to make sure we can map problems, principles, patterns, assets, and technologies to the right hot spots. We want a prioritized list over a laundry list so we're still deciding what's in and what's out. We'll add it to CodePlex shortly. You can either comment here on my blog or wait until the frame is on CodePlex, and then provide comments in the Wiki.
Additional Resources
As part of our patterns & practices App Arch Guide 2.0 project, we've created a set of application archetypes ("app types" for short.) You can see our app archetypes on our Application Types (Archetypes) Index page. To keep it simple, we focused on a small set of common application types that customers identify with. Here's the cool part ... for each application type, we're taking a principle-based approach, then showing relevant patterns, p&p solution assets, and Microsoft technologies. Keep in mind we're still hashing it out.
Application Types
Mobile A mobile application will normally be structured as a multi-layered application consisting of user experience, business and data layers.
When developing a mobile application you may choose to develop a thin web-based client or a rich client. If you are building a rich client, the business and data layers are likely to be on the device itself. If you are building a thin client the business and data layers will be on the server.
See Mobile Application Type (CodePlex)
Rich Client Rich client user interfaces can provide high performance, interactive, and rich user experiences for applications that must operate in stand-alone, connected, occasionally connected, and disconnected scenarios.
Windows Forms, WPF, and Office Business Application (OBA) development environments and tools are available that allow developers to quickly and easily build Rich Client applications. While these technologies can be used to create standalone applications, they can also be used to create applications that run on the client machine, but communicate with services exposed by other layers (both logical and physical) that expose operations the client requires. These operations may include data access, information retrieval, searching, sending information to other systems, backup, and related activities.
See Rich Client Archetype (CodePlex).
Rich Internet Application (RIA) A Rich Internet Application (RIA) runs in the browser in a sandbox. The benefits of a RIA application include richer user experience, better responsiveness and network efficiency over traditional Web applications.
See Rich Internet Application Archetype (CodePlex).
Service A service is a public interface that provides access to a unit of functionality. Services literally provide some programmatic ‘service’ to the caller who consumes them.
Services are loosely coupled and can be combined from within a client or within other services to provide more complex functionality. Services are distributable and can be accessed from a remote machine as well as from the local machine on which they are running. Services are message oriented, meaning that service interfaces are defined by a WSDL file and operations are called using xml-based message schemas that are passed over a transport. Services support a heterogeneous environment by focusing interoperability at the message/interface definition. If components can understand the message and interface definition they can use the service regardless of their base technology.
See Service Application Archetype (CodePlex).
Web Application The core of a Web application is its server-side logic. The Web application layer itself can be comprised of many distinct layers. The typical example is a three-layered architecture, comprised of presentation, business, and data layers.
See Web Application Archetype (CodePlex).
Template for Application Type Guidance Here's the approach we're using to organize the guidance for each archetype:
You can walk the Web application example to see it in action.
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.”
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:
I shared the story of our patterns & practices Engineering Practices Frame on Shaping Software. In a nutshell, the Engineering Practices Frame is a set of categories to organize software development knowledge. The idea behind the frame is to help collect and share principles, patterns, and practices for life cycle activities and artifacts. It's meant to play well with SWEBOK, various Microsoft efforts around life cycle practices, and our customers and field in the trenches. The Engineering Practices Frame is also the foundation for our ALM Frame.
As part of our patterns & practices App Arch Guide 2.0 project, we're consolidating our information on our patterns & practices Performance Engineering. Our performance engineering approach is simply a collection of performance-focused techniques that we found to be effective for meeting your performance objectives. One of the keys to the effectiveness is our performance frame. Our performance frame is a collection of "hot spots" that organize principles, patterns, and practices, as well as anti-patterns. We use the frame to perform effective performance design and code inspections. Here's a preview of our cheat sheet so far. You'll notice a lot of similarity with our patterns & practices Security Engineering. It's by design so that you can use a consistent approach for handling both security and performance.
Performance Overlay This is our patterns & practices Performance Overlay:
Key Activities in the Life Cycle This Performance Engineering approach extends these proven core activities to create performance specific activities. These include:
Performance Frames Performance Frames define a set of patterns-based categories that can organize repeatable problems and solutions. You can use these categories to divide your application architecture for further analysis and to help identify application performance issues. The categories within the frame represent the critical areas where mistakes are most often made.
Architecture and Design Issues Use the diagram below to help you think about performance-related architecture and design issues in your application.
The key areas of concern for each application tier are:
Design Process Principles Consider the following principles to enhance your design process:
Design Guidelines This table represents a set of secure design guidelines for application architects. Use this as a starting point for performance design and to improve performance design inspections.
Jurgen Appelo put together an impressive list of what he calls the Top 100 Blogs for Software Development Managers (Q3 2008). I think it's a great way to find out about blogs you might not know about.
The Top 10 Here's the top ten blogs on the list:
No, I didn't make the top 10. I'm number 20.
Blogs That Made the List In Jurgen's words:
"The idea of this list is to promote popular blogs that are interesting to software development managers. Therefore, I ignored the blogs that did not have any (recent) content directly related to either requirements, design, coding, testing, management, process improvement or methodologies. I also discarded generic project management blogs without topics on software development practices. Likewise, I discarded the pure coding and technology blogs when they did not elevate to the level of "managing" or "ruminating about" software development. Last of all, I only considered blogs in the English language."
Darren at ProBlogger asks, what is great content? ...
I need to think about it. For now, I'll say that great content ...
To put it another way, it's got character, emotional appeal, and logic you can't help but to tango with. It changes what you think, feel, or do.
PS - I distinguish great content from great writing though they share some common attributes.
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.
One of my colleagues on the patterns & practices team, David Hill, collected and distilled feedback on what people would like to see from the App Arch Guide 2.0 project:
As part of our patterns & practices App Arch Guide 2.0 project, we're consolidating our information on our patterns & practices Security Engineering. Our security engineering approach is simply a collection of security-focused techniques that we found to be effective. One of the keys to the effectiveness is our security frame. Our security frame is a collection of "hot spots" that organize principles, patterns, and practices, as well as anti-patterns. We use the frame to perform security code and design inspections. Here's a preview of our cheat sheet so far.
Security OverlayThis is our patterns & practices Security Overlay:
It simply shows a common set of activities that customers already do, and then we overlay a set of security techniques.
Summary of Key Activities in the Life Cycle Our patterns & practices Security Engineering approach extends these proven core activities to create security specific activities. These activities include:
Security FrameSecurity frames define a set of patterns-based categories that can organize repeatable problems and solutions. You can use these categories to divide your application architecture for further analysis and to help identify application vulnerabilities. The categories within the frame represent the critical areas where mistakes are most often made.
When a method call in your application fails, what does your application do? How much do you reveal? Do you return friendly information to end users? Do you pass valuable exception information back to the caller? Does your application fail gracefully?
Architecture and Design IssuesUse the diagram below to help you think about architecture and design issues in your application.
Design GuidelinesThis table represents a set of secure design guidelines for application architects. Use this as a starting point for secure design and to improve security design inspections
PatternsDesign patterns in this context refer to generic solutions that address commonly occurring application design problems. Some of the patterns identified below are well known design patterns. Their use in certain scenarios enables better security as a secondary goal. Some of the main patterns that help improve security are summarized below:
As part of our patterns & practices App Arch Guide 2.0 Project, I'm scanning Microsoft for helpful architect and architecture related resources. One helpful resource I found is The Architecture Journal.
The Architecture JournalHere's the journal's description from their home page:
“The Architecture Journal is an independent platform for free thinkers and practitioners of IT architecture. New editions are issued quarterly, with articles designed to offer perspective, share knowledge, and help you learn the discipline and pursue the art of IT architecture.”
Sounds like just what the doctor ordered!
Article Map To make it easy for my team to find the articles, I created an index that matches the MSDN tree. We'll be digging through the articles throughout our project. Creating the map actually helped me quickly see the scope and range of the articles, so it was a great exercise.
July 2008 - Identity Management
April 2008 - The Role of an Architect
January 2008 - Mobile Architecture
October 2007 - Software + Services
July 2007 - Web Architecture
April 2007 - Infrastructure Architecture
January 2007 - Composite Applications
October 2006 - Software Factories
July 2006 - Data By Design
April 2006 - Generation Workflow
January 2006 - Strategies for Design
July 2005 - Integration Interchange
January 2005
July 2004
April 2004
January 2004
Architecture Journal LinksHere's the key links for The Architecture Journal:
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:
In my previous post, I summarized layers and tiers. In this post, I'll walk through the key components of the layers. This exercise is part of our patterns & practices App Arch Guide 2.0 project.
Layers and ComponentsHere's a visual of a layered architecture and relevant components:
Note that this is just an example of common components and layers. Your scenarios may vary.
Presentation Layer ComponentsHere's typical presentation layer components:
Business Layer ComponentsHere's typical business layer components:
Data Layer ComponentsHere's typical data layer components:
Cross-Cutting
FeedbackDoes this match what you see in practice?
Additional ResourcesHere's some relevant links:
As part of the patterns & practices App Arch Guide 2.0 project, we needed to nail down layers and tiers.
Layers vs. TiersThe original App Arch Guide distinguished between layers and tiers:
"This guide uses the term layer to refer to a component type and uses the term tier to refer to physical distribution patterns."
In other words, layers are logical and tiers are physical (two-tier, three-tier, N-tier). This distinction is helpful, particularly when you want to talk about where you run your layers (which tier).
Presentation Layer, Business Layer and Data LayerWhile there's some variations in layer terms, many people that build application will identify with presentation, business, and data layers. Here's an example:
Two-Tier, Three-Tier, and N-TierAs mentioned earlier, you can think of tiers as physical distribution patterns. Here are some visual examples:
Two-Tier
Three-Tier
N-Tier
Additional ResourcesHere's some links you might find useful:
As part of our App Arch Guide 2.0 project, we're creating scenario frames to organize customer problems into meaningful lists. These particular frames are an elaboration of our App Arch Meta Model. This helps scope our guidance. We also use them to test effectiveness. The value of the guidance is the value of the problems solved.
Scenario Frames on CodePlexYou can review and contribute to our scenario frames on CodePlex:
Presentation Layer Scenarios Frame Heres' the key hot spots for our presentation layer frame:
Business Layer Scenarios Frame Here's the key hot spots for our business layer frame:
Data Access Layer Scenarios Frame Here's the key hot spots for our data access layer frame:
Services LayerHeres's the key hot spots for our services layer frame:
As part of the App Arch Guidance project, we've created an organizing frame to help think about application architecture:
Anatomy of the App Arch Meta FrameYou can see from the figure, we have a few parts that work together:
How We Use the FrameWe use the frame to explore and gain insight into different aspects of application architecture. App arch is a big space. We'll be using the frame to catalog and organize our various principles, patterns, practices, and assets.
Keep in mind that this is a meta-frame (so it's a frame of frames.) We'll have a collection of frames that shine the spotlight on more focused areas.
FeedbackWhat do you think? ...
It's long overdo, but we're kicking off a project for v2 of the patterns & practices Application Architecture Guide. You might be familiar with Tom Hollander's post "Application Architecture for .NET" 2 - The Revenge. Well, now it's time for results.
Solution Architects / Dev Leads / DevelopersOur primary audience is solution architects, developer leads, and developers.
Principles, Patterns, and PracticesI'm a principles, patterns, and practices kind of a guy, so expect the guide to be principle-based, durable, and evolvable.
CodePlex Community Site It's a work in progress and it's early, but you can follow along here:
TopicsHere's some of the areas we're looking at for the guide:
Macro
Micro
Your FeedbackWhat would you like to see in the guide?
Sources of Insight.com is now live. It's a blog I use to share insights and actions for improving work and life. I have a lot of mentees at Microsoft so it helps me scale.
I have a very simple goal for the blog. It's to share the best insight and action to help you be your best in any situation.
It's a work in progress, but I treat it as a living KB of the best insight I can find from books, people, and quotes. While books are great mentors, I also draw from a lot of people. Some mentors have a knack for saying just the right things at just the right times. Sometimes the right quote says it best.
To make the most of the sight, first, start with the About. That will give you a pretty good sense of what the blog is about. Next, visit the Archives. Unfortunately, I haven't fixed all my links yet, so the Archives is the fastest way to hop around.
I'm still experimenting with format, style, and voice so that will continue to evolve. Sometime's it's tough for me to switch gears from writing technical guidance to writing life changing insight. The engineer in me wants precision. The writer in me wants impact. In the meantime, I can say that my mentees, friends, family, and colleagues have been using the nuggets to improve the quality of their lives.
Enjoy, JD
Aside from people, I think books are the best mentors. Ajoy mentioned to me that people like to know what books our team actually uses on the job. I can't speak for the patterns & practices team, at large, but I thought I would help bootstrap by creating a list of my favorite software books. The list includes the books that I continue to mine for principles, patterns, and practices for shaping software.