Although it might sound like one of Master Yoda’s wise sayings, it is in fact one of the realities of modern IT. In fact, it’s more than a reality, it’s a significant challenge for most CIOs today. Years and years of disconnected technology investments are driving many organizations to a state where data duplication becomes a harsh fact of life. Simple questions like “where is you customer data located?” have in many cases multiple answers. This is not necessarily a bad thing, as long as there is a clear methodology to manage data. Unfortunately, most of the time there is no such thing in the organization. The fact that “where is your customer data located?” has multiple answers is worsened by the fact that “which application manages your customer data?” has multiple answers. To make matters even more complicated, most of the applications referred in the response will claim they own the “customer”.

MDM (Master Data Management) is emerging as a potential way to address the challenges mentioned above. Unfortunately, many organizations believe that by simply implementing a MDM solution all of these challenges will be addressed. That’s a big (and potentially costly) mistake. In most cases, along with the MDM solution itself, you also need a serious shift in the organization’s data management mindset. Failure to drive the mindset change will inevitably lead to the failure of the MDM solution implementation. Such a mindset change should result in at least the following:

• A data governance program that spans (preferably) the entire organization
• A master data model
• Changes in applications that interact with master data
• Coherent maintenance processes

Obviously, these are major changes for any organization, and they should be supported by the appropriate toolset. SQL Server 2008 R2 brings for the first time to the Microsoft Application Platform such a toolset, in the form of SQL Server 2008 R2 Master Data Services (MDS). Basically, MDS provides you the infrastructure to implement a master data hub for the central management of master data entities and hierarchies. This infrastructure provides services like management portal, versioning, data-centric workflows, extensible business rules, and role-based security.

For the first time on the Microsoft Application Platform we have the necessary tools to morph the vision of unified, enterprise-wide master data management into tangible reality. All we need is the ability to drive the change in mindset.

To find out more about this promising technology I encourage you to go to the SQL Server 2008 R2 Master Data Servicessite.

I have to admit I was a little bit worried about the overall performance of the new Visual Studio 2010 shell based on the Windows Presentation Foundation technology. I had some mixed feelings while using the preliminary releases like Beta 1 and Beta 2. Don’t get me wrong, I am a big fan of the new VS simply because WPF opens a whole new range of possibilities for it. My concerns were focused around its performance on mid-sized machines. I am perfectly aware of the fact that not all developers are going to code using VS 2010 on quad/octo-core hardware with 16/32 gigs of RAM. This is why I am using my Acer Aspire 1420P notebook as a benchmark to measure the quality of the development experience with VS 2010 (to make things clear, the machine has 4 gigs of RAM and a dual-core Intel Celeron CPU running at 1.2 GHz).

After one and a half day of use in heavy coding I have to say I am impressed and many of my original performance concerns are now things of the past. True, I haven’t had yet the chance to try all the different designers and project templates, but I can say there is a significant improvement in performance when compared to Beta 2. Jason Zander does an excellent reviewon Channel 9 related to the significant changes made in VS 2010 RC.

It certainly looks like VS 2010 together with .NET Framework 4 are on the right track to rock the world of developers once they hit RTM.

Most complex applications will rely on certain types of functionalities that are not tied to a certain layer or tier. Since they affect entire applications it is highly desirable to place these functionalities in a centralized location in code in order to avoid unnecessary duplication. The certain advantage you gain with this approach has its own Achilles' heel: you’ve just created the perfect location for high-impact design mistakes. Because of these interesting characteristics these functionalities are commonly referred among software architects as crosscutting concerns. Some of the most common crosscutting concerns are:

• Authentication and authorization
• Caching
• Communication
• Configuration management
• Exception Management
• Logging and instrumentation
• State management
• Validation

The 2nd edition of the Microsoft Application Architecture Guide has an excellent discussion about crosscutting concerns.

Since they are so common among software applications, it’s no surprise that every single application deals with (hopefully all of) them in its own way. Fortunately, most application platforms offer support to architects and developers in order to address the crosscutting concerns. The .NET Framework 4 in particular and the Microsoft Application Platform in general are no exception. But there’s a catch here: at the core level there is no integrated approach. Take .NET configuration files for services for instance. There are tons of things that you can do with configuration files in the development environment but there’s not much out-of-the-box functionality to handle them once they are deployed.

From the point of view of software architecture, one of the very interesting developments in Windows Server is the Application Server role. Indeed, Windows Server has come a very long way from being a platform providing fundamental APIs to being a true application server. At the heart of this journey there are two fundamental parts: the Microsoft .NET Framework and the Internet Information Services. Today, .NET Framework 4 provides all the necessary building blocks for the development of robust and scalable distributed solutions. IIS on the other hand evolved from a HTTP-based web server to a multi-purpose, multi-protocol, secure and robust hosting environment for application services. Add WAS (Windows Process Activation Service) to the mix and what you get is a pretty strong and scalable application server.

Building on  top of the existing functions in .NET Framework 4 and the WAS/IIS environment, Windows Server AppFabric brings the Application Server to the next level. And by next level I mean that in addition to existing fundamental APIs and hosting environment the AppFabric brings out-of-the-box, robust, and scalable solutions for the following crosscutting concerns:

• Caching
• Communication
• Configuration management
• Logging and instrumentation
• State management

These concerns are addressed via the following categories of functionalities:

• Better deployment, management, and configuration for WCF and WF services hosted in WAS
• Persistence management for workflows
• Tracking profiles (together with dedicated, queryable storage)
• Monitoring of hosted services
• PowerShell integration (custom management scripts)
• Caching of any serializable CLR object and caching APIs at enterprise scale
• Caching available as a service
• High availability and automatic load balancing

It is very important to understand that Windows Server AppFabric will not provide comprehensive solutions to the concerns mentioned above. Nevertheless, it is an excellent and powerful piece of the puzzle that software architects can take into consideration when designing software solutions.

For more details about Windows Server AppFabric you can check the dedicated section from the Windows Server Developer Center.

One of the new rendering extensions available in Reporting Services in SQL Server 2008 R2 is the one that renders reports in the ATOM data feed format. This is an excellent new and standardized way to get the raw data from a report (supposing for instance that you do not need the formatted version) when your only point of connection is the reporting service itself. The ATOM data feed can be consumed by virtually any application that can handle data feeds. What's really cool here is that the new ATOM functionality is nothing more (from an external point of view) than a rendering extension which makes it blend in a very natural way into the overall Reporting Services landscape.

One particularly interesting example of ATOM feed consumer for Reporting Services is the new PowerPivot technology available in Excel and SharePoint 2010. Obviously, it's not the only one. As I mentioned above, anything that understands data feeds can benefit from this new functionality.

So… how do you get the ATOM feed? It’s as simple as using an URL access string like:

http://<server>/ReportServer?/<path>&rs:Command=Render&rs:Format=ATOM&rc:DataFeed=<datafeedname>

Read more about getting data feeds from reports here.

In the past two weeks I had the chance to talk to several architects and dev leads about Microsoft’s strategy for distributed software solutions. One thing that caught my attention was a bit of a recurring confusion related to the AppFabric concept, so I thought it would be a good thing to make a few remarks on the matter.

First of all, we’re dealing today with two distinct AppFabric “editions”: Windows Azure platform AppFabric and Windows Server AppFabric. And to much of some people’s surprise, they are dealing with slightly different things. The big and obvious difference is that one of them is a cloud technology while the other is an on-premise one.

Second, I really have a hard time understanding why on earth did Microsoft go on the path of using the same name for two (apparently) rather different sets of technologies. Somehow reminds me of the .NET Framework 3.0 which is not actually a new framework since it still runs on the 2.0 CLR :) Well…

Windows Azure platform AppFabric is the thing that we used to call “.NET Services” (remember it from all the slides?) and that helps developers connect services and apps in the cloud or on-premises. Two of the most important things that it provides are a Service Bus for connectivity and Access Control for federated authorization. You can learn more about this technology at http://msdn.microsoft.com/en-us/azure/netservices.aspx.

On the other hand, Windows Server AppFabric is what you get by driving Windows Server with high velocity through Dublin…. To be more specific, Windows Server AppFabric (Beta 1 is currently available) is the beta outcome of two technologies previously named “Velocity” and “Dublin”. “Velocity” was the name of the distributed caching technology while “Dublin” was the name of the WF and WCF services management one. Consequently, Windows Server AppFabric merges these technologies into a platform with three core capabilities: distributed caching, workflow management, and service management. You can learn more about this at http://msdn.microsoft.com/en-us/windowsserver/ee695849.aspx.

Since AppFabric (regardless whether it’s the cloud stuff or the on-premises one) is going to have a huge impact on the architecture of our distributed applications built on the Microsoft Application Platform, I’ll get back in the coming weeks with a more detailed analysis of the architectural challenges it tries to address.