Passion * Technology * Ruthless Competence

Wednesday, August 02, 2006

Is SML Another Unwanted Modeling Language?

Piyush Pant wonders if SML solves a problem that nobody has? He also points out SysML project, which recently got folded into the OMG. Well, that explains why we called it "Service" instead of "System" modeling language.

Now that I work in IT, I can definitely say that SML will eventually solve a problem that I have. Most people agree that operations today is way to dependent on manual processes to scale effectively. Now SML doesn't solve that issue directly - as Piyush pointed out SML is a meta-modeling specification. However, SML is the foundation for the next generation of operational modeling tools like what we see in Visual Studio Team System for Architects. As I wrote several years ago, VSTS:A solves a very common problem - developers lack of understanding about the deployment environment. Piyush, haven't you ever had a long weekend going back to the drawing board because the solution you had built was undeployable and you didn't discover that fact until the operations team attempted to deploy it? If you haven't, I envy you.

On the surface, I agree with Piyush when he says that "history of software is littered with unsuccessful attempts to impose monolithic modeling constructs". However, the fact that it keeps happening indicates the problem hasn't been solved. Wanting to solve a problem and being able to solve a problem are two different things. Furthermore, the history of software is also littered with very successful attempts to raise the level of abstraction by the introduction of new programming languages: C, C++, VB and Ruby are all examples of this. Given that Code is Model, what we have is a history of software littered with some successful and some unsuccessful modeling constructs. I would argue that the successful modeling constructs have taken a bottom up approach - build a language a small abstraction step above something that actually runs and compile down. These unsuccessful modeling constructs (*cough* UML *cough*) take a top down approach - build a language way above anything that actually runs and hope a miracle happens to keep it in sync with the stuff you actually build.

The question is whether SML will be top-down (i.e. a failure) or bottoms-up (i.e. a success). So far, it's to early to tell, but I have high hopes.

Posted By Harry Pierson at 2:00 PM Pacific Daylight Time
Wednesday, August 02, 2006 3:27:37 PM (Pacific Standard Time, UTC-08:00)
Interesting points re: top down and bottom up - hadn't thought of things that way and in general I agree. For this to work, though, these things need mass adoption and in an increasingly heterogenous world where systems are not all written on the technology stack of one vendor, a bottom up approach that is trying to solve a problem with a large surface area has limitations. Also, an ambitious undertaking like this seems to assume that the solution to a communication problem ( which is essentially what a modelling language solves in my opinion) , is to teach everyone to talk the same language. It doesn't happen in the real world and I am sceptical it will happen in IT.

Monday, August 07, 2006 5:35:00 AM (Pacific Standard Time, UTC-08:00)
I have responded to some of your ( and Pratul Dublish's) points at
http://unhandledx.blogspot.com/2006/08/further-on-sml-debate.html

Comments are closed.
TechEd New Zealand
TechEd Australia

PDC08

patterns & practices
Summit 2008

Change Congress
Recent Bookmarks
Tags .NET Framework (2) ADO.NET (5) Agile (7) AJAX (3) Architecture (282) Guidance (6) Interop (2) Modelling (61) Patterns (7) Process (4) SOA (93) Web Services (5) ASP.NET (18) Battlestar Galactica (3) BI (2) BizTalk (4) Blogging (114) dasBlog (11) Podcasting (4) BPM (1) C# (6) C++ (4) Capitals (5) CardSpace (3) CLR (2) College Football (10) Comedy Central (1) Community (81) Concurrency (6) Consumer Electronics (1) Database (12) Dependency Injection (2) Development (115) C Plus Plus (1) Embedded (5) Lanugages (37) Media (2) P2P (11) Rotor (1) SharePoint (6) SOP (3) DIY (1) DLR (9) Domain Specific Languages (13) Durable Messaging (5) Dynamic Languages (9) Dynamic Silverlight (1) Education (3) Enterprise 2.0 (1) Entertainment (14) ETech (15) F# (39) Functional Programming (11) Game Development (2) Guidance Automation (3) Hardware (8) HawkEye (3) Hockey (29) Home Electronics (1) Home Network (4) Humor (5) IASA (1) Idempotence (3) infrastructure (5) Instrumentation (4) Integration (2) IronPython (15) IronRuby (4) Java (2) Job (3) LINQ (19) Lost (1) Master Data Management (1) Media 2.0 (6) Microsoft (28) MIX06 (2) Mobile Phone (1) Morning Coffee (166) Object Oriented (4) Office (5) Open Source (4) Open Space (2) Operations (3) Other (135) Art (1) Books (1) Family (30) Games (17) General Geekery (25) Home Theater (1) Movies (22) Music (20) Politics (3) Society (1) Sports (37) Working at MSFT (15) Parsing Expression Grammar (15) patterns & practices (2) PDC08 (1) Politics (39) PowerPoint (2) PowerShell (28) Presentation (5) Projects (1) HawkWiki (1) Python (3) Quote of the Day (4) Refactoring (1) Research (2) REST (18) Reuse (5) Robotics (1) Rome (5) Ruby (23) Sci-Fi (2) Scripting (4) Security (3) Service Broker (14) SharePoint (2) Silverlight (15) Social Software (1) Software + Services (2) Software Factories (11) Software Industry (1) Spark (1) SQL Server (2) Stephen Colbert (1) TechEd (7) TechEd06 (1) TechRec League (1) Television (6) Travel (6) Unified Client (1) Unit Testing (3) UX (1) Virtual PC (2) Visual Basic (1) Visual Studio (19) Volta (2) Washington Capitals (33) WCF (31) Web 2.0 (64) Web Services (5) WF (20) Windows Live (21) Xbox (1) Xbox 360 (51) XML (7) XNA (13)
Disclaimer: The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion.