Isn't this the nature of software? Software changes. Hopefully over all for the better but often "better" isn't better for everybody. Remember when MS introduced the "ribbon"? That worked well for some and not very well for those that were depending on the old menu style. Every software company faces these challenges. If BMC didn't try to improve their products then they would lose market share and go out of business. Do these "improvements" work well for everybody? No. That doesn't mean it isn't the right thing to do. Managing IT is complex and IT professionals can be very creative when finding solutions (on that note I find many IT people are musicians, artists, etc.). BMC (or any software vendor) cannot make and maintain a product that works for everybody 100% of the time; especially a flexible product.
BMC CMDB and Asset being implemented as more or less the same thing as Shawn noted might be considered a mistake. The BMC CMDB has come a long way since v1 and BMC was very active in making it a common IT tool. They had to make choices when starting out. Some of them in hindsight they probably wish they went a different direction. At the end of the day they needed to draw some lines and ship a product. This recent change around life cycle data addresses an issue with the original implementation of some attributes. Do I think there are times when BMC could be more helpful in making successful transitions? Absolutely! Just like our organizations they have resource and time limitations that impact the feasibility how much help they can provide; how "gentle" and forgiving a technology transition can be. There comes a point where you just need to let the fallout happen and deal with it on a case by case basis. If we waited for everything to be perfect all the time nothing would ever move forward. Ok, that turned out a bit longer than I thought it would... By no means do I want to minimize the impact to your organization. This change has obviously presented challenges that your organization and any organization would rather not have to deal with to keep on a current version. Jason On Fri, Jan 17, 2014 at 8:38 AM, Ortega, Jesus A <Jesus.Ortega@ lyondellbasell.com> wrote: > There is a defect open for this : SW00462392, but BMC considers this a > RFE. > > Thank you for the information about what they did. It makes it a bit more > clear about they did it, but it still does not help me sell the upgrade. > The is more to it than just the process itself. This change impacts a large > number of Business objects reports and will require that we evaluate > whether the latest version's universe, 7.6.6., takes into account the new > structure. We are forced to upgrade that application and to rewrite report. > So, our upgrade path has gotten more complicated than we anticipated. > > > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto: > [email protected]] On Behalf Of RainingRemedy > Sent: Friday, January 17, 2014 1:07 AM > To: [email protected] > Subject: Re: CMDB 8.1 Status bug? > > Jesus, > > This is not considered a bug. The AssetLifeCycle status field has been > effectively moved from the CMDB forms and placed on the AST:Attributes form. > The Status field you see is just the leftover core field that is not being > used. From what I've read, I don't think there is any plan to use that > field in the future. Would be curious to see what BMC says about it. > > The whole point of the CMDB and Asset split was to separate the > configuration(discovery) of CIs with the lifecycle managing (Asset Mgmt) > of the CI. That is why they reconstructed all of the joins and now all the > classes are joined with the AST:Attributes form. This is the form where > all lifecycle managed attributes will be stored. These are typically > non-discovered attributes like financial info, location info, status, etc. > > The CMDB forms are now in theory supposed to only be tracking what is > discovered, or the configuration of a CI. The configuration may change > several times during the lifecycle of the CI however, the actual lifecycle > attributes can remain the same. This is the vision BMC had when they split > the attributes up. Config data in one spot, lifecycle management data in > another spot. > > As far as your current scenario is concerned, why do you need to use the > status field as the trigger to promote the data into the production dataset? > Would it be possible to bring in the data as you do now, allow the asset > admins to modify the data as you stated, and then when they are finished > the admins could set a custom attribute to "Ready for Import" for example? > Then during the Identify and Merge job you could just set the Status field > of these CIs to Constant "In Inventory" as stated in your process? Not > sure if something like this would work in your case without knowing more > info about your integration and process. Just trying to throw an idea out > there as a work around. > > > > -- > View this message in context: > http://ars-action-request-system.1093659.n2.nabble.com/CMDB-8-1-Status-bug-tp7594610p7594641.html > Sent from the ARS (Action Request System) mailing list archive at > Nabble.com. > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the > Answers Are, and have been for 20 years" > > > > > Information contained in this email is subject to the disclaimer found by > clicking on the following link: > http://www.lyondellbasell.com/Footer/Disclaimer/ > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
