US Central Region Architect Evangelism Team

Is is safer to stay with Visual Studio 2005 or go to VS 2008?

craeblog — Mon, 22 Oct 2007 15:09:17 GMT

That's what one of my web focused customers asked recently. I thought about it and I came to the conclusion, that Visual Studio 2008 provides a great balance between higher productivity and risk mitigation. Read more at: Visual Studio 2005 or 2008? What's more risk?

Silverlight Runtime Updating

craeblog — Mon, 30 Jul 2007 19:19:00 GMT

As Tim announced last week, Silverlight 1.0 Release Candidate 1 is live.

Now if you're wondering how you and the users of your Silverlight apps are seamlessly getting from RC to RTM and beyond to take advantage of new features and security updates, you can find the details in my post at: http://weblogs.asp.net/cschittko/archive/2007/07/27/how-silverlight-update-works.aspx

XML Serialization Types From Example Docs

craeblog — Thu, 03 May 2007 20:47:00 GMT

Are you still writing deserialization classes for XML types? Don’t you just want to copy an example XML document and have Visual Studio auto generate the deserialization class?

Steve Maine just showed this little tool that’s currently available in the BizTalk Services SDK that takes an instance doc like this:

<bla>

<foo />

</bla>

Then you select Paste XML as Serializable Type from the Edit Menu in VS (2005 or Orcas):

And you’ll get a class to deserialize the document:

[System.Xml.Serialization.XmlRootAttribute(Namespace = "", ElementName = "bla")]

public class BlaClass

{

private string fooField;

[System.Xml.Serialization.XmlElementAttribute(Namespace = "", ElementName = "foo")]

public virtual string Foo

{

get

{

return this.fooField;

}

set

{

this.fooField = value;

}

You can find the tool at:

C:\Program Files\BizTalk Services SDK\Samples\Web\Tooling

Enjoy,

Christoph

TFS Topics

craeblog — Fri, 21 Jul 2006 18:43:00 GMT

A customer recently requested a briefing on a list of topics related to Team Foundation Server (TFS) and Visual Studio Team System (VSTS). In response, we had a LiveMeeting call, during which I used the attached slide deck as the talking points.

Since many of my architect contacts have shown interest in these and other TFS and VSTS topics, I'm publishing the slides here. Their primary value is in the many links they give to deeper material. Also, I attached the excellent whitepaper on System Definition Model, since it can be a little hard to find.

CreateMachineKey Utility Program

craeblog — Thu, 20 Jul 2006 22:47:00 GMT

A couple of years ago I was showing a customer how to configure ASP.NET for use in a web farm. Part of the procedure requires you to adjust the <machinekey> element in each server to the same settings, so that the ASP.NET encryption logic is using the same keys throughout the farm.

MSDN article KB312906 showed a simple command-line utility for generating the keys, but I wanted something more like the CreateGuid utility included with Visual Studio. Therefore, I wrote a WinForm version of the KB utility that I call CreateMachineKey and gave it to my customer and a few other folks who heard about it.

Recently I revisited CreateMachineKey in order to update it for ASP.NET 2.0, which has some significant changes that are described in a Patterns & Practices document. Since I had the code open on the operating table, I decided to zip it up and make it available via this blogsite. It's attached to this article, and I hope you find it useful.

For those of you who are really picky: Yes, I know CreateMachineKey doesn't support MD5, but that wasn't necessary for my purposes. However, if you decide to add that feature, please post it in a comment. Likewise if you find any bugs, although I doubt that's even possible. :-)

Dave Schmitt
July 20, 2006

Have you stopped beating your dog?

craeblog — Wed, 19 Jul 2006 23:30:00 GMT

A customer recently sent me a long list of questions with a generally skeptical tone. Since I spent a good deal of time generating a written response, I thought it would be useful to share it with readers of this blog.

Note that this is my representation of Microsoft’s history and policies, based on many years as a Microsoft-focused customer, teacher, writer, and now as a Microsoft employee. Any errors are mine alone, and I would appreciate you pointing them out to me.

Dave Schmitt

July, 2006

Questions for Microsoft

Platform Independence and Portability

Is C# only going to be available on Windows for the foreseeable future?

The C# language and the related .NET runtime known as the Common Language Infrastructure (CLI) have been standardized for more than 4 years by ECMA and more recently by ISO. See the following links:

http://news.com.com/2100-1007-995108.html
http://www.ecma-international.org/publications/standards/Ecma-334.htm
http://www.ecma-international.org/publications/standards/Ecma-335.htm

Microsoft has fulfilled its commitment to continue this standardization approach as C# and the CLI have evolved since their initial release nearly five years ago.

In contrast, the Java language has not been standardized and is controlled primarily by Sun. The Java runtime (in the form of J2SE, J2EE, JVM, and so on) is controlled by Sun but heavily influenced by prominent Java platform vendors such as IBM and BEA, as well as by the Open Community Process (OCP).

Because they are standards, C# and CLI are open to anyone who wants to implement them on any platform. Microsoft focuses on the many versions of the Windows platform, ranging from very large server clusters to very small mobile devices. In addition, Microsoft provides a demonstration source code package called Rotor that shows how to implement the C# and CLI standards in a portable way and includes build scripts for BSD Unix and Windows. Novell is working on a commercial version called Mono that runs on Linux and other platforms.
Does .NET solely depend on the Microsoft architecture, and if so what are the risks/limitations of such dependency?

It is definitely true that if you download one of the .NET Framework versions from Microsoft’s web site, you will get an implementation that only runs on specific versions of the Windows OS. It’s also true that the Common Language Runtime (CLR) portion of the .NET Framework includes not only the generic CLI but also many classes that go beyond the CLI standard in order to expose features unique to Windows. In that sense, the CLR depends on the Microsoft architecture, that is, on the Windows OS. However, many aspects of Windows, such as its GUI features, have counterparts in other operating systems, which is why Mono goes beyond the CLI standard and implements source-compatible versions of many CLR features.

It’s also useful to note that popular Java platforms such as WebSphere and BEA include features that are not in “the Java standard” in order to provide more efficient coupling with subsystems unique to the platform. Thus it’s fairly common to encounter large Java systems that are tightly coupled to a specific platform and do not have the “write once, run anywhere” characteristics that are frequently touted as a Java advantage.

Regarding risks and limitations, you need to assess these in your specific context. For instance, consider the issue of hardware risk. Windows runs on any hardware that conforms to the industry-standard PC specifications, which are available at the Windows Hardware Developer Center. Although this is commonly known as a Wintel platform (meaning Windows on Intel), Windows actually has many versions running on a variety of hardware, including RISC processors such as the StrongARM series. Microsoft operates a Windows Hardware Quality Lab (WHQL) that is available to hardware manufacturers who want to ensure that their products conform to the Windows standards. Successful execution of the Hardware Compatibility Test (HCT) in this lab enables the manufacturer to display a logo indicating that the hardware is fully compatible with Windows.

In the past Microsoft shipped versions of Windows NT for processors such as SPARC, although these were discontinued because of the overwhelming popularity of the Wintel hardware. Nonetheless, the internal architecture of Windows still rests on a Hardware Abstraction Layer (HAL) that makes it relatively easy to conjure up a version of the desktop or server OS for non-standard hardware. The Windows source code is available under license, and we also offer products such as Windows XP Embedded and the Server Appliance Toolkit to facilitate some of these scenarios. In addition Windows Mobile Edition (aka Windows CE) is available to OEMs in a kit form together with tools for building custom versions.

When you consider the risks and limitations of doing business with the world’s largest software platform and tool vendor, here are a couple of points to keep in mind.

First, the vast majority of notebook, desktop, and server systems are manufactured according to Windows hardware standards. The ubiquity of Windows-compatible hardware means that IT purchasing agents can negotiate with a broad range of vendors, thereby keeping prices very competitive and avoiding hardware vendor lock-in.

Second, if you choose the Microsoft platform, you are only limited in the sense that you might not be able to run your application on a classic mainframe or midrange machine or on a non-Wintel server or desktop. In most practical situations, enterprises are not interested in moving new applications to their legacy mainframe/midrange systems and would rather migrate the mainframe applications to more cost effective servers. Legacy servers not running Windows remain viable in some scenarios, and they typically use a Unix variant. However, commodity Wintel servers are usually able to offer better TCO. In the desktop/laptop market, Apple hardware is the primary Wintel competitor. Microsoft has been shipping a Virtual PC product for the Mac that enables users to run Windows XP software in that environment. However, now that Apple is moving to a Wintel (or at least Intel) platform, it’s quite possible that Apple will offer even better support for Windows applications. Finally, the mobile device market continues to have several strong OS vendors, including Microsoft, but we are seeing a definite move to the Windows Mobile platform.

The bottom line on risks and limitations is that Windows runs on a broad variety of commodity-priced hardware available from a huge number of vendors. Only Microsoft is able to cover the spectrum from tiny mobile devices to huge server clusters with a cohesive and unified OS and development tool suite that is priced for volume sales and is well supported.
J2EE is being engineered by a group of companies that include hardware and software vendors, it seems that there would be advantages to this. Is Microsoft doing this, and if not, what is the rational for not doing so?

Many, if not most, of the major companies participating in the Java effort are also Microsoft partners in one way or another. You can visit sites such as the Windows Hardware Developer Center mentioned earlier and the Microsoft Developer Network (MSDN) to see the effects of this robust interaction with our partners.

For example, the initial version of .NET was in the hands of developers for nearly two years before its official release in 2002, and it was the beneficiary of a huge amount of feedback during that period. Since then, .NET as well as many other Microsoft products like SQL Server 2005, have been routinely exposed to developers early in the cycle through our Community Technology Previews (CTP) and many other collaborative opportunities.

Microsoft employs a large group of technical evangelists whose primary job is to ensure that users of our technology are well-versed in its capabilities, understand our roadmap, and are encouraged to provide feedback from their particular application efforts. You can see many examples of this work at our case study site.
J2EE is an open forum architecture where specifications are reviewed, weighed, and analyzed by the community before they actually become standards. It seems this would be an approach that would identify more security risks and many other factors when developing new standards, is there a reason why Microsoft is not engaging in a more open fashion like J2EE is?

At the risk of being flippant, I’m tempted to ask why, if the Java community is so interested in standards, none of the Java specifications have been put through a formal standardization process with ANSI, ECMA, ISO, or other such bodies. As noted earlier, the foundation of .NET has been standardized by ECMA and ISO. Furthermore, Microsoft (together with IBM and BEA) founded the Web Services Interoperability organization, which has been developing industry standards that are making web services the lingua franca for service oriented architectures. Sun joined this effort long after it started, and the Java specifications continue to lag well behind the actual Microsoft implementation of the interoperability standards.

In addition to our efforts with the standardization committees and industry groups such as WS-I and W3C, Microsoft exposes its architectures to intense scrutiny by vast numbers of users and experts, including many in the Java community. Indeed, one can show that a good number of the J2EE subsystems mimic Windows features released years earlier by Microsoft, and clearly the Java specifications continue to follow Microsoft in areas such as web services.

The major difference between the Java OCP and Microsoft’s approach is that we are motivated to adopt the simplest and most effective solution, whereas the Java community has difficulty reaching that point of closure. As a result, the Java developer often faces a bewildering series of choices in order to cobble together a system appropriate to his or her problem space. That’s why enterprise customers typically adopt a single-vendor approach to their Java needs, choosing WebSphere or WebLogic because IBM or BEA has made the tough choices for them.

Many industry pundits have decried this complexity, which is largely due to the vagaries of the OCP. For instance, a recent report from the Burton Group contains the following summary:

“Java Platform, Enterprise Edition version 5 (JEE5) was intended to simplify the incredibly complex Java Platform, Enterprise Edition (Java EE) but failed to deliver on that promise. The primary value proposition of Java EE—a common programming model for a complete enterprise platform—makes the platform susceptible to disruption by platforms that emphasize ease of development. In this overview, Senior Analyst Richard Monson-Haefel explains how JEE5 fails to save Java EE and why it’s a harbinger of the end of Java EE as the dominant enterprise platform.”
.NET supports one operating system and is supported by one vendor. How difficult is it if (for some reason) we have to implement .NET in Unix or is it even possible?

Windows is many operating systems with a consistent programming model, so in that sense, .NET supports more than one OS. Regarding .NET on Unix or other systems, see the Rotor and Mono comments above.

You might also consider the reverse question. How difficult is it to run a Unix or Java application on a Microsoft OS? Windows has long supported a Unix-compatibility layer that has enabled notable Unix applications such as the original HotMail to rapidly move to more cost-effective Windows servers. The .NET language suite includes J#, a baseline version of the Java language suitable for applications written at the JDK 1.1.4 level. Microsoft is also heavily into virtualization, with its Virtual PC and Virtual Server products as well as the virtualization features baked into the upcoming Longhorn server. Finally, other vendors have been working on the notion of running JVM code on top of the .NET Framework, the most notable effort being IKVM.

What are the benefits with one vendor support?

Since most enterprise Java customers choose a single platform vendor (typically IBM or BEA), the benefits of one vendor are well known and are not unique to the Microsoft platform. Clearly you want a vendor who will remain viable, has a reasonable technology roadmap, provides high-quality, well-supported products, and conducts business in an honorable manner.

Suffice it to say that a single-vendor approach gives the customer one throat to choke.
What are the disadvantages with one vendor support?

Again, this should be obvious. Even if the vendor has what I need today, will they have it tomorrow? Once they get me locked in, will they play pricing games or screw me up in other ways? What is their track record for long-term support of their platform? If they drop support, what will it cost me to move to some other platform? To get a handle on these questions, you need to examine the vendor’s current and past practices, as well as their willingness to share their future roadmap with you.

Microsoft is proud of its support legacy. We have seldom, if ever, discontinued any popular platform technology. Indeed, you can still run ancient MSDOS apps on modern versions of Windows, and COM is still fully supported as the component programming model from the 1990’s. Our large staff of evangelists is constantly briefing customers, user groups, and industry pundits about our future plans, and they also solicit feedback that helps modulate these plans to better meet customer needs and to provide more seamless support for interoperation with or migration from other platforms.

Security

Microsoft has a poor track record with security, is there any defense to this statement?

Microsoft actually has an excellent record dealing with security issues in a forthcoming manner with an appropriate (and quite large) commitment of resources. For instance, during the first 18 months after Windows Server 2000 was released, Microsoft issued 55 security bulletins. During the same period after the release of Windows Server 2003, the number was 17, due largely to the massive amount of work (reportedly costing upwards of $300 million) to carefully examine every line of code for security problems.

A detailed review of security issues with Microsoft and other platforms is beyond the scope of this document, but we can arrange a briefing from one of our security experts if appropriate.
Along the same lines as above, the community seems to believe that Microsoft is more prone to viruses and worms, why is this and how does Microsoft handle this?

In December 2004, Nathaniel Paul and David Evans of the University of Virginia compared security in Java and .NET. They found that after 3 years of life, the Java VM had 15 major platform vulnerabilities, as compared to zero such vulnerabilities in the .NET CLR after a similar period. At the time of publication of their analysis, security analysts had discovered 44 major platform vulnerabilities in the Java VM, while the total for .NET was zero. The authors argue “that .NET’s design is fundamentally more secure than Java’s, and in particular, that it benefits from following general security principles that have been learned and reinforced from experience with Java.”
Is it a true statement that Hackers target the Microsoft platforms due to the known track record in security and making Microsoft an easier target?

Hackers target the Microsoft platform for the same reason that burglars target mansions, because that’s where they are liable to find expensive jewelry. The ubiquity of Microsoft technology in mission critical applications provides what military planners call “a target-rich environment.” Hackers are no longer immature young men looking for a moment of glory. Rather, they are criminals seeking financial gain or cyber-terrorists working for a variety of disruptive purposes.

Again, Microsoft has security experts and guidance documentation focused on these issues and our response to them.

Some Fortune 500 companies selected J2EE due to its more proven track record on security, has .NET compromised on security?

In October 2004, Gartner Research published the results of an Enterprise Tracker study showing that the use of .NET for mission critical enterprise applications exceeded the use of any other platform.

Forrester’s survey of 822 North American enterprises conducted in May of 2004 found that 56% of them prefer .NET for their primary enterprise platform, versus 44% for J2EE.

Time to Market and Tool Set Productivity

Learning curve for prior users of Microsoft tools & technologies
Majority of App Delivery Teams Favor J2EE; and some .NET.
Does J2EE provide tool sets that are more productive than .NET?

Numerous benchmarks and actual case studies contradict these statements. See Microsoft Marketing Bulletin: Comparing .NET to J2EE and the document .NET Momentum Evidence. These are both in the attached zip file.

Scalability and Performance

There are claims that .NET has more independence, scalability, and performance issues than J2EE, what steps has Microsoft taken to prove it’s worth in these critical categories?
Are record transactions and simultaneous user activity as scalable as J2EE?
Being that the latest .NET framework is newer than J2EE, does it lack maturity?
Questions persist about the scalability and transaction capability of the Windows Platform, how does Microsoft live up to these areas?
Does J2EE have better Application Availability & Reliability that .NET?

Many of these questions are addressed in the documents mentioned earlier and in the hundreds of case studies published on the Microsoft web site. If this evidence does not convince you, we can arrange to have our experts drill down deeper as appropriate.

Maintainability and Complexity

How easy (or difficult) to modify applications under the .NET platform?

Obviously it depends on the overall soundness of the original application architecture. Every architect and developer knows that you can design weak applications on strong platforms, but it’s difficult to build a strong application on a weak platform. The .NET platform has proven to be extremely strong and robust, with a superior tool set, a huge knowledge base, and strong community support.

In our case studies, developers often comment on their increased productivity when they moved to .NET Framework because it has a cohesive OO design that follows industry best practices and standards.
What is the Market Resource Availability for .NET developers compared to J2EE developers?

In March 2006, Tim O'Reilly said on his blog: "Based on book sales data, it looks like ASP.Net 2.0 is on fire, with ASP-related book sales up 53% since the same period a year ago, versus PHP, down 3%, and JSP, down 25%."
Is there a stronger resource pool for C# vs. VB .NET?

Yes in some geographies, no in others. C# is attractive to the “semicolon” crowd, made up of C, C++, and Java developers. VB.NET is attractive to experienced VB developers or those who prefer a more verbose language.
Are there any benefits of one .NET language over the other?

The .NET Framework was designed from the beginning to support multiple programming languages, as evidenced in the term Common Language Infrastructure (CLI). The type system and other CLI features enable an implementation of just about any programming language on this platform, and more than two dozen .NET languages have entered production from Microsoft and its partners. These include not only C++, C#, VB, and J# from Microsoft, but also such classics as Fortran, Cobol, and RPG from other vendors.

As Don Box once noted, “Your programming language is merely your viewport to the runtime system.” So, as long as a .NET language gives you an unobstructed view, language choice is simply a matter of syntactic and stylistic preference, not functional differences. The main .NET languages supplied by Microsoft give you an unobstructed view of the CLR, and so are equally viable choices for building robust .NET applications.

Longevity of Product and Company

Firms that spend a higher percentage of revenue on IT are more likely to do the majority of development on J2EE and .NET is often the primary development platform for small and medium size companies. Is this a correct statement? Why is that?

In December 2005, IDC published a study of adoption of .NET among small, medium-sized, large and very large organizations. The report draws from demand-side research data that IDC collected in a survey of software developers worldwide conducted in the spring of 2005. .NET leads Java, by 49% to 29% in small organizations, 48% to 38% in medium organizations, 42% to 39% in large organizations. In all cases, organizations planned to use .NET in the future at a higher rate than Java. This study was not funded by Microsoft.

Introducing the MSDN Wiki

craeblog — Thu, 06 Jul 2006 16:34:00 GMT

The new MSDN Wiki encourages contributions from users in order to improve the documentation of Visual Studio and other developer products. I decided to give it a try and so I tacked my words of wisdom onto the LoginView class description. It’s something unusual that I discovered while showing a customer architect how .NET 2.0 simplifies declarative role checking.

This is a pretty cool way to contribute our discoveries to the MSDN documentation without going through a lengthy publishing process.

Microsoft Unified Communicaitons strategy - Office Roundtabel is really cool!

craeblog — Mon, 26 Jun 2006 21:19:00 GMT

I just posted a blog about Microsoft Unified Communications strategy we just unveiled:

http://blogs.msdn.com/hanuk/archive/2006/06/26/647627.aspx

- hanuk

WinFX rebranded as .NET Framework 3.0!

craeblog — Sun, 11 Jun 2006 21:55:00 GMT

Look at my blog entry for high level information on our recent WinFX rebranding: WinFX rebranded as .NET Framework 3.0!

- hanuk

Don't try to understand SOA; just get it done!

craeblog — Mon, 24 Apr 2006 20:46:00 GMT

Based on my recent conversations at NAF there seems to be this dichotomy between Enterprise Architects (EA) and Solution Architects (SA) in terms the chances of success of SOA at a larger scale. Winning the hearts and minds of SAs is one of the fundamental critical success factors for SOA implementation strategy to get off the ground.

Following is a link to my post on what Enterprise Architectss should do to win over Solution Architects in creating a working SOA strategy - http://blogs.msdn.com/hanuk.

Cheers,

hanuk

The softer side of architecture

craeblog — Tue, 07 Mar 2006 01:05:00 GMT

Well, my first team blog entry. I work with Dave, whom you've met, except I cover MN, ND, SD, Iowa and Nebraska. I cover most accounts in those states with the exception of some of our big retail and healthcare accounts.

Ever since the idea of a team blog was floated around I've been thinking about what I'd write. Do I try to impress people and write some great posting on the next greatest technology? Give my two cents on upcoming products such as Origami? Why does anyone want to read what I have to say? Hmmm. Well, so what I came up with is I will blog mostly about two things.

The first is, as I get customer questions that I think others would be interested in hearing the answers, I'll try to take the time to post that here as well. It might be something interesting I come across that I want to tell people about or it might be on something specific like can you use ADFS for active client protocol.

The other, well, here is the deal. It's a fact that I'm different than all of the architects I meet with. Yes, I wear pink and I'm not going to stop. Yes, I hold events and quite often, I'm the only woman. I go to customers and I'm the only woman. Oh wait, every once and a while there is a project manager or an admin who is taking notes in the room to keep me company. Ugh! So, I might occasionally post on how it sucks that if I were male, I'd be in the bar networking over scotch, but since I'm not, I just get face time at lunch. Or I might touch on other aspects on the softer side of architecture like how you need to influence people to get them on board with your architecture. Enough on that for now...

I'll leave you with one final tidbit. We're nearing the launch and RTM of TFS. If you haven't seen it, check it out! It is one of the more exciting technologies we're releasing from a development improvement perspective. I can't wait to see what customers do with customizing it.

Jacquelyn

AE Biography -- Dave Schmitt -- North Central District, KS and MO

craeblog — Mon, 13 Feb 2006 20:22:00 GMT

Dave's computer career began during his high school years in the 1950's when he had the opportunity to work on a wood-burning mainframe system. By improving the stack algorithm, he was able to boost the power and reduce the risk of deadly emissions, which were a serious threat to early programmers.

Soon after electricity was discovered, Bell Labs designed a computer that used semiconductor chips instead of wood chips. Intrigued by this breakthrough, Dave joined that renowned R&D organization, where he was involved with fault-tolerant versions of C and Unix. After several years, he invented the No Fault System (NFS), which allows a CPU to divorce itself from an I/O channel without a lengthy court proceeding.

During one lab experiment, Dave was injured when a network cable accidentally detached and sprayed him with high-speed bits. While recuperating, he realized that his injuries would have been much more serious if the cable had contained a larger percentage of 1's than 0's. This led to an interest in compression algorithms, and he quickly devised a technique for squeezing all of the 0's out of a bitstream, leaving only the 1's that carry the essential information. This formed the foundation of modern audio and video compressors, which have the goal of reducing all content to a single bit. Always socially conscious, Dave has made several public service commercials warning users that cables must be securely fastened to prevent injuries when handling this dense information. He has also worked with the music, television, and motion picture industries to ensure that they produce insipid melodies, inane lyrics, and idiotic plots that can be easily compressed to one or two bits.

During the 1980's Dave and two friends formed Lattice, the pioneering C compiler company. Their compiler was praised because of its strong support for recursive programming, undoubtedly the result of the frequent cursing during its development. They actually had intended to design an RPG compiler, but somehow it morphed into a C development system that was the market leader until it stopped being the market leader. By that time Lattice had been acquired, the founders had split the money, and yadayadayada.

During recent years, Dave has taught COM programming for DevelopMentor, written technical books and articles, operated a consulting firm called Pivot Corporation, and served as CTO of Abiliti Solutions. Now he is employed by Microsoft as an Architect Evangelist working with customers in Kansas and Missouri.

Although well versed in modern computer technology, he is often nostalgic for the good old days and recently upgraded an ancient gas-fired server to run Windows Server 2003 Propane Edition.

Welcome to the US Central Region Architect Evangelism Team Blog

craeblog — Mon, 13 Feb 2006 19:42:00 GMT

Welcome to our team blog. We created this site in order to share the experiences and insights of the Microsoft Architect Evangelists who serve the United States Central Region.

This idea was suggested by Microsoft customers who attended our Central Region Architect Forum during the past few years. The interactive roundtable discussions proved to be the most popular part of the forum, and many attendees suggested that we find some way to continue these discussions throughout the year.

MSDN blogging looks like the answer, so we hope this site will become a popular place for architects to share information. We welcome any and all suggestions for improving this site.