다음을 통해 공유


Oslo and Models

As you may have already read on Doug's or Don’s blogs, “Oslo” is the codename for the new Microsoft Modeling platform. What’s important to understand is that when we say "Modeling Platform" we use the term "Modeling" in the broadest sense of the word to mean "an abstract representation of something that has a useful purpose".

The big question is: Why are models so important and what can you do with them?

Models can describe everything: a business process, an SLA, a computer farm, a single machine, a particular system deployment, a team, a person, a solution, a running process, and so on. They allow you to describe your environment in a useful way, but more importantly, they allow you to capture the relationships between models. There are several systems and solutions in existence today that allow you to describe some of the relationships in your system (like the connection between a computer and the applications that run on it), but no one to date (that I know of) had taken such a holistic approach that captures all the elements of the system, throughout the solution's lifecycle, in a uniform and open way, using one simple modeling paradigm, and made it part of an infrastructure play.

Making modeling part of the infrastructure allows the usefulness to emerge as we and others will leverage these models to create better ways to design, build, deploy, execute, monitor, and service systems. My personal opinion is that the language and the tools (cool, efficient, and useful as they are) are just means to an end – the real power of the system is in the Repository, which will store and provide proper access to these models and the relationships between them. Over time, this will be leveraged to:

  • Capture all the practical information regarding a solution in one place, and by that persisting the collective knowledge of the organization
  • Simplify cross discipline communication through persistent, non-lossy, high fidelity transition of artifacts from one stage in the application development lifecycle to another
  • Execute models, like XAML or deployment models, directly from the Repository
  • Perform impact analysis. For example, allowing one to know which business matrices will be affected if a specific machine is take down for 30min to install a patch
  • Simplify root cause analysis an issue resolution. For example, finding out that an SLA is not being met because a particular app was deployed to a machine with 1GB memory when the developer’s design calls for 2GB (the dev is easy to find if the model describing the developer is associated with the model describing the app), and fixing this by changing the deployment descriptor for that app
  • And much more ...

I am pretty excited about this commodification and democratization of models, and the potential it has to transform (simplify) the way in which we develop complex software. What do you think about this?

Comments