Author Archive
Experiencing IT
I’ve been in IT for longer than I care to admit.
This week, as we were putting the final touches on the exciting launch of our new Experience Manger product I had a recollection from the “beginning of time”. It was more than 20 odd years ago, and I was given ownership of the main logistics and maintenance operations management application for the Navy shipyards. No, not an SAP module – this is pre SAP times, and not a interactive application even. It was a batch application and users in the shipyards would feed it with information about planned and on-going production, maintenance and repair work on a daily basis by filling in data cards, to be punched in by “data processing clerks”. Our Main Frame COBOL programs would do their magic overnight and issue a set of reports that would be FACed to the yards (No, not FAXed – FACed as in “get them out with the First Available Courier). Nifty things could be done with these reports like identifying critical project paths, forecasted delays and applying workforce optimization. We were very proud of the smart code that produced them.
On my first day in my new role as the application owner I get a call from my chief customer, the guy who runs ops in shipyards. He cordially invites me over to visit, “I want you to come see how your stuff is used in the field”. Next thing I knew, I had a protective helmet and gloves on and was spending a day with the hardened men of the shipyard in the belly of submarines, metal workshops, and on the deck of the patrol ships being quality inspected for battle readiness. Everywhere I looked the input forms for our application and the output report cutouts were hung, and in the ops office planning officers were huddled around the planning charts produced the night before. They talked to me about application changes they need and about being able to update during the work day and to get reports on demand, and they repeatedly reminded me of the time when the reports did not arrive in the morning and work was halted, and when data was missing from the reports because it had not made it into the night run. They gave me a taste for what it feels like to be a customer of our applications and felt it was the very first thing they needed to do to make me a better partner.
Fast forward to today’s reality: the essentials have not changed – the most important thing IT professionals do is still putting business enabling products in the hands of our customers – the business users. And these products still have to work again and again and again for each and every user and continuously improve. A primary concern of IT professionals will always be a true and deep understanding of those users and the ways in which they use business enabling IT services.
20 years after MF batch heydays, we are fortunate to live in an era when understanding how users experience IT services does not require taking a ride to the shipyards or visiting the online consumer’s home. And as the underlying technology has evolved to be far more complex than those early COBOL days so has the focus on the quality of experience.
On this day of the launch of our Experience Manager product it feels great to take a part in making the IT experience a better one for all involved – the users consuming the services and the IT professionals providing them.
Add comment October 1, 2009
CMDB Dead on Arrival?
You know those weeks when ten different people happen to talk about the very same thing from five different angles? Well last week was CMDB week for me, and this week already started with the same topic on three different calls and five email threads.
Every customer, integrator, vendor and analyst with whom I spoke had a similarly sad story to tell. Projects that start with great expectations, ranging from pre-change impact assessment to post change operational business impact analysis and from business architecture mapping to technical application component dependency insight. Then varying degrees of positive experiences using the automated discovery tools to populate the CIs and their technical dependencies. And then a frustrating disillusionment. It becomes clear that these maps are not going to provide more than marginal value that hardly justifies the effort, and the great leap into real business service mapping must be taken.
Some take a “boil the ocean” approach. They spend the next three months with several people trying to map one business service such as “Online client support” top to bottom down to the granular service as consumed by users. All this time and effort is spent only to discover that the maps are incomplete due to reasons such as “it would take months just to reverse-engineer that old piece of black box we kept from the legacy system”. They are inaccurate due to reliance on “hard data” such as “I think we that for time deposit services we use the TXMP CICS transaction to do interest rate calculations, but not really sure, need to look at the programs…” And the worst of all, even the best maps no longer describe reality three months into the project because the application has already changed twice and the infrastructure setup once!
Others take the “let’s start with some high level maps” approach. Good on paper, and somewhat easier to implement, these approaches end up creating high level maps that are as good as telling you a tornado is impacting the state of Ohio now! Well it’s a pretty big state to go looking for the impacted communities and by the time you start the search based on this “mapping” 911 will already tell you who’s been impacted. The common response from management to status updates on these projects is ”want to tell me we invested all of this effort and money to uncover issues we already knew about?”
Bottom line: People with the best intentions to put CMDBs in the center of their IT alignment initiatives and power effective configuration, and problem change management processes that truly put them on a path to better service quality and improved operation efficiencies, are finding themselves in a tough spot. Projects are being scrapped, put on hold, and alternatives are being desperately sought.
It was gratifying to be able to share with these folks the experiences of organizations that enjoy truly automated business to IT mapping. As described in a previous post “Does change management impact your infrastructure or your business? – BTM adds tremendous value to the mapping of services to CIs. It not only provides these benefits standalone, which is a great approach to justifying CMDB projects if you have not engaged in one yet, but can also salvage failing and stalled CMDB initiatives and resurrect the confidence in their value to the business.
While clinically dead on arrival, a shot of BTM can definitely revive CMDB.
Add comment September 3, 2009
Connecting people
Like many other cell phone users I see the message “Connecting people” every time I turn on my phone. More than just giving away my manufacturer preference, I wanted to share in this post why that message strongly resonates for me as I think about BTM.
When discussing BTM a lot of the conversation centers on the technical complexity of business transactions. So for instance we were talking the other week about a simple “bill payment” transaction. Seems such a “simple” payment transaction flows in many cases across as many as ten IT environments: a client service portal (web front ends, security appliances, front end portal servers, portal personalization databases), then crosses over to the payment application (payment system app servers, master payment database and the interfaces to external payment services). There is huge value in exposing this technical flow across the two apps and the eight technical components.
But if we look beyond the technical complexity we’ll see that each and every one of the steps in this flow has a person behind it: from the business user behind the payment itself to the IT people behind the apps and infrastructure pieces. Everyone is focused on making their part of the overall story work well – but they all have very little to go by in terms of aligning their efforts with the overall goal. And the overall goal that really matters is getting that payment thru, without glitches, without holdups, time after time.
Well, transactions, when made visible, provide us the ultimate facility to connect these people, business and IT alike. Transactions expose the “lines between the dots” and provide a meaningful context to the people who participate in planning the systems, creating the apps and operating them. They allow them to focus on their jobs while effectively communicating with their peers. They provide a shared context around which they can all connect.
Think about it : “Transactions – connecting people”.
Add comment July 9, 2009
