Systems Center Configuration Manager 2007 (SCCM or, if you work in my office, affectionately known as scum because it's easier to say out loud) is a pretty important piece of technology from Microsoft. Important from an infrastructure perspective, that is. Wikipedia suggests: "System Center Configuration Manager, formerly Systems Management Server (SMS), is a systems management software product by Microsoft for managing large groups of Windows-based computer systems. Configuration Manager provides remote control, patch management, software distribution, operating system deployment, and hardware and software inventory."
Yeah, I'd go with that description, however in my opinion there are two big problems on the horizon for SCCM 2007.
The first is with the application architecture. It's 32-bit only. Alright, I hear you, I shouldn't be a snob when it comes to 64-bit architecture. The truth is I'm not, I develop both 64- and 32-bit applications on a variety of architectures and understand why one might go for 32- over 64- or whatever. The problem for SCCM 2007 is that it's going to get installed and be operated on the Windows Server 2008 64-bit platform in many circumstances.
Which means it's going to be running inside a 32-bit sandbox via WoW (Windows on Windows). Which means it can't take advantage of the native 64-bit architecture, it's running under emulation! Not good for an Enterprise application!!
This isn't the whole problem however, since it's not that big a deal to be running in a 32-bit sandbox on Server 2008, is it? The problem comes when you start to develop code for SCCM. Given the shonky half-hearted SDK for SCCM 2007 and plenty of investigation, the interface into SCCM is a lovely (I use the term loosely) dll exposed as SMSResGen.SMSResGen.1.
This 32-bit COM library (yes I said COM, even though it's 2008 already) is a part of SCCM and, as a consequence, also runs under 32-bit emulation on the 64-bit Server 2008 platform. So the limitations intrinsic to running 32-bit apps on a 64-bit OS apply.
Worse still of course, using the COM library via .NET means a nice wedge of COM Interop and this slows things down to a crawl.
Since this is my blog and I can pass comment, I would be thinking about getting SCCM into 64-bit like, yesterday, and I'd be shipping it with a native .NET assembly to replace the creaking old COM library. This would make it much easier for developers to leverage features and prevent the ten-fold increase in time it takes to test and debug even the simplest of applications written to leverage the API.