Last December, Arvindra Sehmi of Microsoft EMEA (Europe, Middle East and Africa) created JOURNAL – the Microsoft’s Architects JOURNAL – to great success. Now, with the publication of JOURNAL 2, we have launched JOURNAL’s new homepage on the MSDN Architecture Center. You can read the articles online in the MSDN library or download the full issues as PDFs. (To anyone who previously downloaded the JOURNAL 1 PDF, we’ve reformatted the PDF so that it will print on A4 or US Letter sized paper without having to shrink it to the point of near-unreadability.)

BTW, you do have to fill out a profile questionnaire to get access to the PDF’s. And since we want to encourage people to fill out the profile questionnaire, we’ve only published one article from JOURNAL 2 on MSDN so far. We’ll publish one of the remaining articles on MSDN every couple of weeks. However, to whet your appetite, the article we choose to publish is the cornerstone of JOURNAL 2 – Pat Helland’s Metropolis. It’s based from Pat’s Architecture Strategy Series presentation of the same title, where he drawn a parallel between the evolution of cities and the evolution of information technology shops. It’s a very powerful analogy for understanding that we’re at the very beginning of the Information Revolution and that we have a long long way to go.

Please drop me a line or leave a comment with your thoughts on JOURNAL. It’s a quarterly publication, so look for JOURNAL 3 in July. In the meantime, we’re always looking for authors, so let me know if you have an idea for an article.

It’s been around a while, but I only just noticed the Microsoft Solutions Framework website because they just published their whitepapers on the Download Center (RSS feed for Download Center provided by ThunderMain – thanks guys!)

From the overview, MSF is:

Microsoft Solutions Framework (MSF) is a deliberate and disciplined approach to technology projects based on a defined set of principles, models, disciplines, concepts, guidelines, and proven practices from Microsoft. This white paper introduces MSF and provides an overview of its foundational principles, core models, and essential disciplines, focusing on how their application contributes to the success of technology projects. Finally, the paper provides references for further information about MSF and references for guidance in implementing MSF within an organization. In an appendix, the paper briefly compares and contrasts MSF to other industry methodologies and standards and describes how MSF can be used in combination with them.

MSF includes two models – team and process – as well as three management disciplines – project, risk and readiness. They also have a bunch of MSF templates you can use in your own projects.

One of the nice things about MSF is that it works with other methodologies. I.e. you don’t have to give up RUP/XP/TDD/<insert your favorite methodology here> in order to use MSF.

Update: Lorenzo has compiled a list of MSF links you can check out.

Via Udi and Tiago, I found an article on DevX called “Kiss the Middle-tier Goodbye with SQL Server Yukon“. While that article should have been titled “XML Technologies in SQL Server Yukon”, both Udi and Tiago have interesting posts about SQL Server as a platform and the role of the database going forward. Personally, I see two primary forces at work that I believe will drive the middle tier into extinction: Moore’s Law and Service-Orientation.

Why do we distribute applications across multiple systems today? Is it because we like managing multiple systems? No! It’s for scalability. We exploit the fact that tiers of a multi-tier app have different processing loads and scalability methods. Typically, we scale the web/app tier by throwing more servers at the farm while we scale the data tier with bigger servers. However, as Moore’s law increases the performance of these machines, the need to scale becomes reduced, From my experience, many smaller apps could easily run a single machine today (esp. when you consider the increased efficiency of eliminating the network and process hops). Moore’s law will continue increase the headroom these machines provide and expand the definition of “smaller apps”. If you can run the app on a single hardware node, there’d be little reason not to run as much of it as you can inside the database, other than “we might want to scale this out someday”.

Of course, it will be a long long time before Moore’s law can provide a single machine to run a BIG enterprise app (think something like SAP). This is where service-orientation comes in. While some people see services as a way to interoperate BIG apps, I think the future of services is to free us from building BIG apps, or at least from build BIG apps as monoliths. If you figure a BIG app like SAP has hundreds or thousands of business process or resource management operations, you could build that system where each operation is implemented as an independent service. The benefit of this approach is that it is orders of magnitude more flexible in the face of process change than the BIG app approach. If you haven’t seen it, check out the Technology Roadmap session from the Architecture Strategy Series. One of the points that the presenter Norm Judah makes is that “it is the business processes in an organization that are unstable, but the individual things that people do…are the things that are stable.” (He says that during Slide 9 – “Why Do Architecture Projects Re-Occur?”) If you accept that, then having your business processes hard coded in a BIG inflexible app starts to look like a bad idea. These “individual things that people do” (such as sending out invoices) get mapped to services and are aggregated into business processes by some tool we haven’t seen yet (though I think BTS 2004 is a good start).

If service-orientation shreds your BIG app into many pieces, it is highly likely that those pieces will be small enough to run on a single hardware node. In addition, as services communicate with asynchronous messages, they tend to have lower scalability needs than synchronous systems. And since these services all need a database (Pat refers to the database as the soul of the service) it makes sense to run the service inside the database itself. It even makes sense to build a both an application and a messaging infrastructure directly into the database engine. SQL Yukon provides the application infrastructure by hosting the .NET framework and provides the messaging infrastructure with the SQL Service Broker.

However, we need more than faster computers and service-oriented systems to eliminate the middle tier. We also need better management. And not incrementally better, orders of magnitudes better. If you’re going to replace a single BIG app with hundreds of independent services, incremental manageability improvements are not going to cut it. Because we realize this too, Microsoft is investing heavily in the Dynamic System Initiative. If you’re a developer, you’ve probably seen the Whitehorse designers coming with Whidbey. That’s just part of DSI. We’ve got a great architectural overview of DSI as part of our Architecture Strategy Series or you can read more on the DSI homepage.

Do you think the middle-tier will become extinct? If it does, is that a good thing? Obviously, it’s an unknown and a big change, which makes it hard to gauge. But what does your gut tell you?

Like the rest of the known universe, I recently read The Da Vinci Code by Dan Brown. I had read Angels & Demons on a plane trip back from Alaska when my laptop battery had died. A&D was good, esp. considering the low bar of killing several hours flying back from Anchorage. I tried to read Digital Fortress but just couldn’t stand it. I liked the crypto part of it, but the characters were blown so out of proportion that I just could never get into it. Also, who starts a thriller with that much backstory? So I approached Da Vinci Code with some trepidation, but also hope.

Of course, it hooked me instantly and before I knew it I was 100 pages in. This was much much better than Fortress or A&D. In addition to the great plot and characters, this book does an amazing job of obfuscating the line between reality and fiction. While I don’t believe the events actually occurred or that Robert Langdon exists, the background history of Da Vinci, the Holy Grail, Christianity and the incorporation of pagan traditions was fascinating. Given the success of Passion of the Christ – by all accounts a hyper-literal interpretation of the Bible – I think it’s interesting that the equally-successful Da Vinci Code essentially refutes that the Bible is THE word of God. Of course, the Da Vinci Code is a novel so I’m not really sure where the facts ends and the fiction begins. I haven’t read a book that blurred that line so well since Jurassic Park.

Unfortunately, while Dan Brown may be a brilliant researcher and steadily improving as a writer, it all comes apart in the end. The true identity of the Da Vinci Code’s primary nemesis left me (and subsequently my wife) very disappointed. I kept wondering how he was going to pull it all together in the end. For all the finely detailed logic and history of this story, it felt to me as if the author essentially picked the least likely character to be the bad guy for the sole purpose of minimizing the chances the reader would guess it. It’s fine to be surprised at the end, but it’s got to make some sense. What’s the point of building to a climax only to pull it out of your ass when you get there?

I used to say that everything we build should be a platform except for games. What’s interesting is that games are becoming platforms in their own right. Dungeon Siege has the freely downloadable Siege Editor which allows you to “rework nearly every aspect of the gaming world, making Dungeon Siege not only a game, but also a platform for those who wish to create their own spells, dungeons, and even entire worlds.” There are several projects that do just that. And Dungeon Siege II is coming later this year, which looks amazing (all trailer graphics were rendered with the game engine). If RTS is more your speed, Relic – developers of Impossible Creatures – has their developer network which provides both a companion tool for enhancing Impossible Creatures as well as the Impossible Creatures SDK “which includes source code from the IC engine that can be used to create Total Conversion Mods for IC” (Relic Developer Network requires registration). Of course, there’s also the Allegiance source code which was released a few months ago.

I guess the new viewpoint is that everything we build should be a platform, including games.