Hi, I’m Travis Wright, a Senior Program Manager Lead on the Service Manager product development team. My team and I are responsible for part of the platform used in Service Manager and other System Center products. I spent 4+ years working on Operations Manager 2000, 2005, 2007 and the last two years working on Service Manager.
I will be posting a series of blog entries describing the platform. In each post, I’ll dive in a little deeper on different areas with the intent of giving you an “under the hood” view.
To begin with a little history, let’s recall the February 2008 announcement that Service Manager would be delayed following the first public beta. At that time, we announced that the reason for the delay was
“to replace specific components of the Service Manager infrastructure … and … align the product with the rest of the System Center family by taking advantage of proven technologies in use in those products.”
- Paul Ross, Senior Product Marketing Manager
I’d like to explain in more detail how the recently announced public beta has incorporated those technologies.
The Operations Manager, Service Manager, and Essentials products were built by one large team at the time this decision was made. For various reasons, there had been a separation of technology stacks between the Operations Manager/Essentials part of the team and the Service Manager team. Collectively, we decided that we could best serve our customers and partners by aligning on a common technology stack to achieve the following goals:
· Engineering efficiency would result in the ability to release products to market faster and/or add features at a faster rate.
· Higher quality due to code reuse.
· More integration scenarios could be enabled in less time.
· Customer/partner investments in learning one product could be applied to other products.
· User experience consistency would lead to a customers deriving value from the product faster.
To achieve these goals, we decided to align on the technology stack developed for Operations Manager 2007. We created three distinct product teams (Operations Manager, Service Manager, Essentials) and broke the common technology stack up into three pieces (Data/Integration, Workflow Engine, and Console Framework) and put one piece of the technology stack in each product team. Each product team also builds a set of solutions on top of the common technology stack [hereafter called “the common platform”].
As each product team evolves their portion of the common platform the other teams pick up the new versions and include them in their products. For example, the Operations Manager 2007 R2 version of the common platform workflow engine will be included in Service Manager as the workflow engine for Service Manager. This does not mean that there are any hard dependencies between the products. The platform components are essentially copied into each version of the product and installed seamlessly as part of each product’s setup. Each System Center product can be installed completely independently.
So, now that you know why we made this change and how the platform is being built, in the next post I’ll start to describe the common platform in detail and especially how it is leveraged in Service Manager. As a sneak peek, here is a thumbnail of the architecture diagram for Service Manager.
Next up is the model-based database .
|
|
Travis Wright |
|
|
Follow Me! |