Comments on: The future (2006 version), has arrived http://stage.vambenepe.com/archives/1007 IT management in a changing IT world Tue, 09 Mar 2010 22:10:17 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Stu http://stage.vambenepe.com/archives/1007#comment-94526 Stu Thu, 08 Oct 2009 18:16:00 +0000 http://stage.vambenepe.com/?p=1007#comment-94526 Regarding that post-mortem and the lessons you draw from it. I agree the primary issue is a modeling problem, not a protocol problem. But (quelle surprise!), I disagree with your characterization that one can just "pick a protocol". OK, if you are just talking about "bits on a wire", then yeah, pick one. But I think the broader part of the "modelling problem" is the whole issue of data management: stewardship, provenance, governance, identification, lifecycle, etc. As you've suggested, we've been busy working on *mechanism* for manageability, and our industry's attempts at management integration standards have usually devolved into more mechanism for manageability. Perhaps one reason is that these approaches have neglected that data management is an essential part of management integration. The SOA world saw this problem too, and it led to a twinkle of interest in customer data integration hubs, data services platforms, or master-data management (MDM) servers, but these solutions still seem to be relegated to the data warehousing and BI communities. And in the management space, CMDB's solve this problem no differently from how a data warehouse solves the problem, i.e. reasonably well for some use cases, but at great expense to maintain. The main reason I am such a proponent of REST has little to do with HTTP, to the point that I almost bristle when we, as a community, too easily conflate the two. While 80% of the noise over REST is about HTTP, the real insight and excitement has to do with URIs and hyperlinking. These concepts bring data management to the forefront of networked application architecture. "Bits on the wire" are not the centre of the universe; the identifiable and/or referenced information resource is the centre. This industry has to evolve beyond message passing and "throw everything into a big database", if we're ever going to make major headway with integration problems. Regarding that post-mortem and the lessons you draw from it.

I agree the primary issue is a modeling problem, not a protocol problem. But (quelle surprise!), I disagree with your characterization that one can just “pick a protocol”. OK, if you are just talking about “bits on a wire”, then yeah, pick one.

But I think the broader part of the “modelling problem” is the whole issue of data management: stewardship, provenance, governance, identification, lifecycle, etc. As you’ve suggested, we’ve been busy working on *mechanism* for manageability, and our industry’s attempts at management integration standards have usually devolved into more mechanism for manageability. Perhaps one reason is that these approaches have neglected that data management is an essential part of management integration.

The SOA world saw this problem too, and it led to a twinkle of interest in customer data integration hubs, data services platforms, or master-data management (MDM) servers, but these solutions still seem to be relegated to the data warehousing and BI communities. And in the management space, CMDB’s solve this problem no differently from how a data warehouse solves the problem, i.e. reasonably well for some use cases, but at great expense to maintain.

The main reason I am such a proponent of REST has little to do with HTTP, to the point that I almost bristle when we, as a community, too easily conflate the two. While 80% of the noise over REST is about HTTP, the real insight and excitement has to do with URIs and hyperlinking. These concepts bring data management to the forefront of networked application architecture. “Bits on the wire” are not the centre of the universe; the identifiable and/or referenced information resource is the centre. This industry has to evolve beyond message passing and “throw everything into a big database”, if we’re ever going to make major headway with integration problems.

]]> By: Jayadeep Purushothaman http://stage.vambenepe.com/archives/1007#comment-92928 Jayadeep Purushothaman Tue, 29 Sep 2009 04:20:45 +0000 http://stage.vambenepe.com/?p=1007#comment-92928 The major difference between the management ingetration efforts of 2006 and now are that the existing management objects(hypervisor, clouds) by itself enable a lot of management integration of the provision,monitor,re-configure cycles, whereas that integration was something that a third party effort which promised the integration, which didn't really add much value. The other important difference is that management aspects are very much part of the solutions(hypervisors,cloud) rather than an after thought in the earlier days where it needed a third party vendor to close that gap. Fundamentally, management needs to be simple and self sustaining and should not get in between the real work. From that perspective, an overly simplistic view doesn't hurt IMO. The major difference between the management ingetration efforts of 2006 and now are that the existing management objects(hypervisor, clouds) by itself enable a lot of management integration of the provision,monitor,re-configure cycles, whereas that integration was something that a third party effort which promised the integration, which didn’t really add much value. The other important difference is that management aspects are very much part of the solutions(hypervisors,cloud) rather than an after thought in the earlier days where it needed a third party vendor to close that gap. Fundamentally, management needs to be simple and self sustaining and should not get in between the real work. From that perspective, an overly simplistic view doesn’t hurt IMO.

]]> By: El Kaim William http://stage.vambenepe.com/archives/1007#comment-92518 El Kaim William Fri, 25 Sep 2009 19:32:20 +0000 http://stage.vambenepe.com/?p=1007#comment-92518 My two cents. First, your blog is great ... Second, I'm not as expert as you are ... I think what is missing in the approach is more a systemic approach of IT instead of a very focused technical vision of infrastructure Mgt. CMDBf should be reused, we may need more explanation of why it is interesting, and provide some open source around it (or at least free of charge implementations). The job of sysadmin is also changing, so it will take some time for them to move to cloud. That's why I thing we need a more global vision of how it fits in new models. My two cents.
First, your blog is great …
Second, I’m not as expert as you are …

I think what is missing in the approach is more a systemic approach of IT instead of a very focused technical vision of infrastructure Mgt.
CMDBf should be reused, we may need more explanation of why it is interesting, and provide some open source around it (or at least free of charge implementations).
The job of sysadmin is also changing, so it will take some time for them to move to cloud. That’s why I thing we need a more global vision of how it fits in new models.

]]>