Posts Tagged ‘BSC’

Business Service Composer – pain in the… artifact?

Friday, March 22nd, 2013

I’ve been starting actively using Business Service Composer for creating my service trees in TBSM It’s really powerful tool, that helps you doing a lot of things with service structure, regardless component CDM classes (or any classes in any namespace, regardless their origin), however with one big glitch – it’s a huge step back in single administration console approach by deselecting TIP to be portal of choice in Tivoli and using Java GUI instead. There are two conveniences:

– If you really want to enjoy BSC GUI – don’t use it via ssh tunnel from within your Putty session to TBSM server (MS Windows users). Loosing focus on buttons or just selected menu items is so frequent that more times it doesn’t work and confuses than it works ok. It’s a nightmare, let’s put it straight. Just run it on your local workstation instead, it will save you a lot of nerves and time.

– But – once you run it on your desktop, you’ll have to come over the pain of updating project files via SCP (Windows users) there and back again in order to upload any single change to your static resources or policies.

It would probably be better if you run it all mounted locally from a remote site, where projects directory remains already in the right place for xmltoolkit script to pick it up and load it to artifacts without all that copy nightmare.

This is it. Powerful, conditionally usable, still some way from a nice tooling. And has nothing to do with TBSM Service Editor. Confusing? We have application descriptors and templates to model a dependency of CIs to applications first, then we have some functions of TADDM GUI, then we have BSC and at the end we have TBSM Service Editor. Confusing? It all works and has special use, but I’d have piece of a better advice for development. And I promise to share it.


TBSM in telco industry

Tuesday, April 12th, 2011

After months of break in posting on my blog, I’m coming back and publishing again. After spending a few months in one, bigger project for one of our bigger customers in Europe I’m full of different thoughts on TBSM and its technical use scenarios, as well as on business perspectives of getting this kind of tools to work. I will do my best to present all the interesting aspects and observations and share some of my experience.
First thing to mention is definitely form of my blog. Still the same, maybe will change the layout, but I’m definitely switching to English. Reasons can be justified by business, I believe that english publications remain valuable for polish engineers who may be looking for an interesting content in my blog, and who mostly speak english anyway, and remove the natural language barrier for audience from all over the world. I also believe in delivering more interesting content from now on and rely on your feedback more.
Like I mentioned, I’ve been participating in large TBSM project for telecommunications company in role of implementer and solution co-designer. It’s been very interesting time, lot of experience to gain, long hours and evenings spent over business services design, status and KPI rules, and dashboards. Product such as TBSM, which is highly customizable, and can basically be used in so many ways, may give you both lot of fun and trouble. Up to how open is your solution scope, TBSM design itself can take regular project time or way longer.
There are many things to say how to deal with such project requirements, how to address customer’s suggestions, how to translate use scenarios to TBSM service model, rules and dashboards. But I think it’s better to start from, say, “demythologization” of what TBSM can do and is for.
TBSM is not a network manager tool, or if you prefer – network topologies or hierarchies visualization tool. It’s rather obvious, but service models design may confuse you especially when you try to show dependency of some devices functions on other devices functions. Like you know, everything in TBSM is a service, or business service, even if representing a device, an application or a process. So presenting those objects in TBSM, named after their real, original name, like BSC or SGSN, and links connecting them in Service Viewer portlet, may confuse people less familiar with the tool and drive their minds to think that graphical link represents a physical link between devices, so has a critical meaning for signalling or data flow. Also naming services after devices doesn’t help here. Like I said, TBSM is not network manager or monitor, it just doesn’t have the right tools, like ping, telnet or cgi scripts, even though can present network objects with nice icons, KPI results and SLA violations. For network manager, you’re recommended to learn more about ITNM (IBM Tivoli Network Manager, former Micromuse Precision), if speaking about Tivoli. For open source, they’re writing interesting stuff on op5 in Linux magazine (at least recently in polish edition). For simple visualization of links between locations, I encourage to try Netcool Webtop Maps (new Webtop version was named WebGUI).
Second thing, TBSM can show many services in a tree or relationships view, but there’s a reasonable limit. They say 50’000-100’000 is fair limit nowadays. And 50 child services per parent. But watch out the product role again. It’s business services manager. Are you really running 50’000 business services in your company? So services that you make money on and their components? If yes, you must be IBM! 🙂
Of course I’m kidding, you may run many services, much more than that and I don’t know how many services they could identify in IBM in WW total. It’s not the point. It’s rather a question: which services are important to you enough to spend weeks on analysis and workshops, identifying their dependencies, collecting technical details, establishing the missing and reconfiguring the existing monitoring and performing all tests? It still can be many, like hundreds top level services plus 10 levels of key components. But all the key components presence in TBSM service models should be justified and reasonable, and preferably: pre-documented, in order to deploy and implement a working solution on time. So TBSM shall be the last place where unverified and unconfirmed service topologies come in.
Last but not least, TBSM audience. I’ve done many projects after which TBSM box landed on shelf. So many customers order it, pay for it (maybe was volume price), are interested in it, after then just one enthusiast remain engaged and all the other personell switch back to old good monitoring tools they know from a decade. Or worse for both IBM and the customer: project slows down, become a critsit and even gets fixed, but bad impression remains. I’m that lucky that my recent project has been done by many enthusiastic people and also the customer, one among a few, has had a realistic vision of and need for TBSM use. It’s a pleasure to work with such mature customer, who is aware of TBSM place in their infrastructure and plans TBSM to be part of their information flow. Likely real life issues and obstacles, usually coming up during every implementation, are way easier to solve if there’s common understanding of what TBSM can and cannot do, and the only question remains open: when this all will be ready?
I hope to share some more interesting thoughts soon. I also encourage you to share your opinions on TBSM projects in different companies and industries, in general or in particular. Topic doesn’t really matter, can be about TBSM or Tivoli. Tivoli’s competition in monitoring or open source. Feel free to post your thoughts. I’m looking forward to hear from you about your bad experience with TBSM, Tivoli or IBM, as well as well done projects and what you’ve learned from them. Welcome and post you soon.