Among my other duties, I am co-ower of the architecture track at this year’s TechEd. We’ve got a great track lined up, including two new sessions from Pat Helland in his Metropolis series. You can see an earlier version of the original Metropolis session as part of the Architecture Strategy Series or read an article about Metropolis in the latest JOURNAL. I’m presenting a session on information architecture (guess I gotta get the slides done soon!). Plus there are 15 other great sessions to see on architecture. We’re also running two precon’s on architecture : One on patterns and practices (run by Keith Pleas, my recent partner-in-crime on .NET Rocks) and one on identity management.

After the precons on Sunday night, we’re having a party – the Architect Road Rally @ the San Diego Auto Museum. Party goers get a close up look at the history of Porshe, race RC cars and play the new Rallisport Challenge 2 on Xbox. We’re also giving away some RC cars as well as copies of RSC2. Plus, food & beer all evening (i.e. this is not an hor’dourves party). So please register and come have a good time.

Finally, we’re also planning on running focus groups @ TechEd – your chance to help us help you better with architecture. Also, people chosen to participate in the focus groups get something Cool. Register for the focus groups when you register for the road rally.

See you in San Diego!

Update: this post actually hasn’t been updated, I just deleted the original and crossposted from my main blog.

Among the responses to my endangered middle-tier post was this one by Ed Draper, architect evangelist for MSFT. While Ed makes some interesting points, on the whole his argument doesn’t hold much water.

First off, his point about Moore’s law is accurate, yet irrelevant. While Moore’s law does relate to CPU speed, I was using it as an example of the rate that overall computing power improves. Storage capacity and network speed improve along a similar trajectory. 64-bit machines are at the early stages of becoming commonplace. And while it’s true that scalability doesn’t equal performance, having better performing hardware can significantly improve scalability.

(Side note – if we’re going to be truly picky, Moore’s law actually refers to rate of improvement of the number of transistors per IC, which only roughly equates to performance. Intel’s Centrino technology is all about using those increasing numbers of transistors for other things like wireless networking and battery management.)

Ed spends quite a bit of time covering very low level computing concepts such as threads, locks, instruction cache, registers and the stack. I’m not sure why he does this. It almost feels like he only read the first part of my post, stopping right before he got to the part where I wrote: “Of course, it will be a long long time before Moore’s law can provide a single machine to run a BIG enterprise app”. In other words, I don’t expect to run my ERP, SCM, CRM or other BFD enterprise-scale app on one machine!

Ed has missed a basic point of my post that I didn’t spell out as I thought it was obvious: the independent services that make up a BIG enterprise class app can all run on different machines. I’m guessing he missed that point by the way he ended his post:

“Yes, distributed computing is a good thing.”

As Ted points out, it’s not just a good thing, “distributed computing is a necessary thing.” And a system of 100′s or 1000′s of independent services – which is what I’m describing – is significantly more distributable than the multi-tier monolithic applications we build today.

Of course, it is guaranteed that a small percentage of services will continue to need to use scale out techniques to reach their scalability requirements. For example, it will be a very very long time (if ever) before a single piece of hardware could handle the order processing load Amazon.com generates a week before Christmas or the tax return filing load at the IRS on April 15th. This problem isn’t unique to application design. To draw a parallel to the database design world, there are a small percentage of tables that benefit from using filegroups to isolate them on separate drives from the rest of the database. It happens – but it doesn’t always happen. It doesn’t even usually happen. I like Josh’s comment that “the vast majority of people who think they have workloads which require partition for scale are actually indulging in delusions of grandeur.”

The point I was making is that computers are going to continue getting faster and service-oriented systems are likely to consist of boatloads of independent services with only modest scalability requirements. The combination of these two forces drastically reduces the number of scenarios where you need to use multi-tier scale out techniques to achieve the scalability requirements. If you don’t need a multi-tier deployment, then there is a huge performance and scalability benefit to running the service logic in the database process. If you don’t need to scale-out to achieve your requirement, why would you take the performance and scalability hit to run your code outside the database?

It’s pointless to argue that computer aren’t getting faster or that running the code in process with the database doesn’t perform better. Ed (and Ted and Josh and everyone else reading this), I’d love to hear you opinions on the following:

• Will a service-oriented approach likely result in of boatloads of independent services where today we have one BIG app?
• If yes, will the vast majority of these boatloads of independent services have modest enough scalability requirements to run on a single piece of hardware in the near future?

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?