Showing posts with label Lessons Learned. Show all posts
Showing posts with label Lessons Learned. Show all posts

Monday, February 11, 2008

International Conference on Global Software Engineering

If you have been a regular reader of my blog, you know that globalization is one of my favorite topics of discussion. Therefore, I would like to draw your attention to the International Conference on Global Software Engineering which will be held August 17-20, 2008 in Bangalore, India. (Recently renamed Bangaluru.) The event is sponsored by the IEEE Computer Society.

Please note that if you have some thoughts to share, there is still time to submit a paper. The deadline for abstracts is Feb 21, 2008 and the deadline for papers is Feb 28, 2008.

Yours truly is a member of the Program Committee for the event. However, that doesn’t mean I automatically get to attend. I still have pay the registration fee and pay to get myself there… or convince my employer of the wisdom of spending their money to send me. I had the good fortune to visit my team in Bangalore and interview a few programmers for positions back in the fall of 2004 and I would certainly enjoy a return trip for the conference. I would be curious have any of you (my readers) had success at securing funding for travel to this kind of thing? If so, I’d love to hear how you justified the expense to your employer.

Copyright © 2008 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Tuesday, August 21, 2007

Perils of Over-Customizing SAP-Broken Reports

I've been around clients for some great discussion on the perils of over-customizing SAP lately. I hope to collect some of the lessons learned here for your reading enjoyment and career enrichment.

Here's a comment made by a country sales manager at a meeting I attended in May 2007.
"They told us that the new SAP system would have over 160 reports out-of-the-box that we could use to run our business and we didn't plan on having to create a lot of custom reports. Now they tell us that's not true. Almost all the out-of-the-box reports are broken. Almost every report we need must be a custom development."
It seems this company made some customizations to their base SAP system (ECC) when they were only operating in a only single country and were focused only on a transactional, commodity type business model. They then moved into multiple countries and began to look closely at big, relational customers and value-added services. To support this, they planned to create a new CRM system running on top of their existing ECC. They were not happy to find out that their legacy of prior ECC customizations "broke" a lot of the standard SAP reports.

I'd love to hear from other people who might have an SAP over-customization lesson to share.

(Dec 2007) English not your native language? I've begun making podcasts of popular posts and they are available at http://artsciita.podbean.com/. Listen online at that URL, with the MP3 player below, or subscribe to the podcast using the RSS feed and listen with your favorite MP3 player.


The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Friday, April 20, 2007

Word from the China Front

I had the good fortune to make my second trip to visit my client in Beijing, China. My trip was extended twice and I wound up staying three and a half weeks.

  • The reason my trip got extended was that one of my team's biggest recommendations related to eCommerce was rejected by the client as too expensive and taking too long. Heavy sigh. A worthy competitor has been introduced into the overall solution as a result.
  • I got to observe an interesting phenomenon. When an army of English speaking people fly to China to conduct meetings in English with Chinese I/T staff, the English speakers tend to dominate the discussion while everyone is in the room. The Chinese are generally soft-spoken and before they can mentally translate from English to Chinese, the English speakers move on to the next point. The Chinese are too polite to interrupt and say "you're going too fast." Therefore, the English speakers think there is a consensus only to discover objections later that never got expressed during the meeting.
  • I joined the team tasked with creating an Enterprise Service Bus (ESB) for the client. This ESB must span from North America to China. I think it qualifies as the "Brokered ESB Deployment Pattern" as described in my earlier post ESB Patterns that "Click".
  • I've been learning more about SAP and integrating SAP to other systems.
  • On a personal level unrelated to I/T Architecture, I got to have dinner with a member of Communist Party, to be amazed yet again at the incredible changes taking place in Chinese society, to visit the Summer Palace, to visit the Lama Temple, and take a bicycle rickshaw ride thru an old Beijing hutong. I got really tired of Kung Pao Chicken too.

Me at the Summer Palace in March 2007.

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Wednesday, November 22, 2006

Companies that Need SOA the Most Are Least Likely to Implement It

My eyes were drawn today to an ITBusinessEdge post "Companies that Need SOA the Most Are Least Likely to Implement It". How could I resist that title? (That reminds me of a previous post of mine "Naming Well, an Essential Skill of an I/T Architect" but I degress.) That post in turn drove to yet another cleverly named post

Is SOA success in the genes? by ZDNet's Joe McKendrick -- Todd Biske recently responded to my post about Microsoft's recommended approach to SOA (inch by inch, it's a cinch; mile by mile, its a trial), and ponders whether some organizations can get SOA right away, but others will never get it. How do organizations end up with their IT out of synch with business [...]

The basic premise here is worth entertaining. Companies that already have good alignment of I/T and business, already have good governance in place, already think proactively and strategically about I/T, etc. will find moving to a Service Oriented Architecture just the next incremental step in their improvement process. For the other companies out there (the vast majority?), the gap between where they are today and SOA is an insurmountable chasm that they dare not even try to cross.

I think there is an element of truth. I've seen a lot of situations where a company could benefit from new approaches but because they organize a bunch of independently funded, tactical projects no one project can fund the leap to the next level of maturity and flexibility. (See also "The Scourge of the I/T Architect's Universe".) Just a couple of weeks ago an acquanitance of mine at a major manufacturer told me he was interested in using SOA software products for their EAI-like-middleware value but he didn't think his organization was ready to embrace SOA yet. I guess this is like "flying under the radar" to wait until the political situation is more receptive to SOA.

Copyright © 2006 by Philip Hartman - All Rights Reserved


The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Tuesday, October 31, 2006

Little Shop of IT horrors

For your Halloween reading pleasure: Check out Little Shop of (IT) Horrors.

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Tuesday, October 17, 2006

Halloween Horror Stories for I/T

Out of the many emails I get from the various online trade rags, one jumped out at me from my inbasket the other day. The email pointed me to one article with a title inspired by the upcoming Halloween season: 25 Terrifying Information Technology Horror Stories. There's even a great video clip from an old black and white horror movie, "The Brain that Wouldn't Die".

I won't say I've read through all of the horror stories but from what I can tell, the lessons learned are worth a visit by any serious I/T Architect, project manager, CTO, CIO, and anyone else who doesn't want to be pointed out to the whole world as an example of how NOT to execute an important project.

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Sunday, December 18, 2005

The Dangers of Wikipedia

It seems that I am seeing references to Wikipedia everywhere these days. The idea of tapping the expertise of millions of volunteer experts around the world to create an immense online encyclopedia is intriquing indeed. No doubt there are tons of useful information which we might otherwise not have available to us were it not for this information-age repository of knowledge. But... how do we know if the informaiton is correct? What if the volunteer was in error. What if they were just showing off?

The dirty secret is that it does happen. See a Boston Globe article "The Wiki Effect" which describes how one prominent free speech advocate found he had been listed as a suspect in the assasinations of both John F. Kennedy and Robert Kennedy. As it turns out, the man who posted this assertion which was freely available to all for months eventually admitted it was all a hoax designed to dismay a co-worker.

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.