Art & Science of Being an IT Architect

Art & Science of Being an IT Architect

Philip Hartman

Share:
Share:
A mix of crisp insight and totally random thoughts on software development, estimating, corporate politics, consulting skills, and more.
A mix of crisp insight and totally random thoughts on software development, estimating, co...Read More
Episodes (6)
Newest to Oldest
Sort Episodes:

Still More on Reverse Eng...

18 Dec 2007 | 01 min 09 secs

Still More on Revers...

18 Dec 2007 | 01 min 09 secs

Reverse Engineering of UM...

18 Dec 2007 | 05 mins 24 secs

Reverse Engineering ...

18 Dec 2007 | 05 mins 24 secs

On War and Aggessive Proj...

18 Dec 2007 | 59 secs

On War and Aggessive...

18 Dec 2007 | 59 secs

Perils of Over-Customizin...

18 Dec 2007 | 01 min 49 secs

Perils of Over-Custo...

18 Dec 2007 | 01 min 49 secs

The Global Lifestyle Time...

18 Dec 2007 | 04 mins 11 secs

The Global Lifestyle...

18 Dec 2007 | 04 mins 11 secs

Learn to Love Your SAP ID...

18 Dec 2007 | 05 mins 41 secs

Learn to Love Your S...

18 Dec 2007 | 05 mins 41 secs

 

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.

Copyright © 2007 by Philip Hartman - All Rights Reserved

"},{"@context":"https://schema.org","@type":"Article","mainEntityOfPage":{"@type":"WebPage","@id":"https://beta.hubhopper.co/episode/the-global-lifestyle-time-challenge-1584697835/2746799"},"headline":"The Global Lifestyle Time Challenge","datePublished":"2007-12-18T23:22:31.000Z","dateModified":"2007-12-18T23:22:31.000Z","image":"?s=hh-web-app","author":{"@type":"Person","name":"Philip Hartman"},"publisher":{"@type":"Organization","name":"Hubhopper","logo":{"@type":"ImageObject","url":"https://files.hubhopper.com/assets/web/hh_logo_192x192.png","width":192,"height":192}},"description":"

I had a subtle career milestone today. Today I became fully aware that I was now \"Global\" ... with a capital \"G\" I think.

At about 6:30 am Central time I checked email at home before leaving for the airport. I saw an email from a business leader in the UK which set off alarms in my head that an important business decision my client needed to make was not being addressed. Knowing that a politically important deadline is approaching, I fired off a \"this is a big issue!\" email designed to alarm my readers that something important was not happening.

About 8 am Central time today I was waiting for a flight at the airport and my cell phone went off. It was that same business leader in the UK who took notice of my alarm. I don't know about you, but I don't get cell phone calls from people I've never met from other countries every day.

Shortly after arriving at my destination on the East Coast of the US, I scheduled a web meeting for tomorrow morning between people in Baltimore, Raleigh, California, and Beijing.

Later I was on a call between the US and Canada talking about interfaces to a system in China.

Still later I discussed architecture diagrams showing system components in Rochester (NY), Boulder, Dallas, Tulsa, Phoenix, Hong Kong, Beijing, and Toronto. I tried to figure out if the component in Hong Kong was really necessary. Could it be co-located with the rest of the stuff in Beijing?

I ate a hurried dinner of Tandoori Takki with two co-workers. One is a Norwegian citizen born in China but holding an American green card and the other was born in India but has been working in the US for a while. My history is boring compared to theirs.

Five minutes after checking into my hotel, I joined a conference call between the US and China but the co-worker from China didn't make the call. My co-worker later came online in China on instant messenger later and I pinged him about the call he missed. It turned out he was double booked for that timeslot. Heavy sigh. When are we going to solve time zone issues for calendars? I made sure he had the information for the web meeting in 9 hours.

This globalization thing isn't all its cracked up to be. Exactly when is it I am supposed to have some calm moments to think? When is it I am supposed to get more exercize like my doctor told me? Will the guy in California get up to make the web meeting at 6 am his time? Did I even have a right to call a web meeting that required someone to be there at 6 am? Will the guy in Beijing who has to join at 9 pm his time have a decent Internet connection? Did I have a choice on the time given that the guy we want to talk to was available then and it was a comfortable 9 am for him? Will my flight home on Friday be on time so I can make my daughter's piano recital? How early do I set my alarm clock for tomorrow? Early enough to hit the hotel treadmill or late enough to get another hour of sleep?

I have another trip to China coming up in two weeks. It is still fun for now. I can see how this could get old. I would love to hear how my readers in similar situations are handling the demanding hours, encroachment upon personal time, cultural differences, etc.

FYI, globalization has been a frequent topic of mine. You might take a look at some previous posts such as:

Copyright © 2007 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.

"},{"@context":"https://schema.org","@type":"Article","mainEntityOfPage":{"@type":"WebPage","@id":"https://beta.hubhopper.co/episode/learn-to-love-your-sap-idoc-1584697835/2746855"},"headline":"Learn to Love Your SAP IDoc","datePublished":"2007-12-18T23:10:25.000Z","dateModified":"2007-12-18T23:10:25.000Z","image":"?s=hh-web-app","author":{"@type":"Person","name":"Philip Hartman"},"publisher":{"@type":"Organization","name":"Hubhopper","logo":{"@type":"ImageObject","url":"https://files.hubhopper.com/assets/web/hh_logo_192x192.png","width":192,"height":192}},"description":"Over a year ago, I had a post in which I discussed how difficult it is for a custom application development person like myself to get adjusted to projects based on a packaged application like SAP. It had the somewhat humorous title How to Talk to an SAP Consultant (If You Must). If you keep reading this post, you will see that I am now starting to understand some of the SAP terminology which once seemed so incomprehensible. I hope you will find this post helps accelerate your own understanding of SAP if you are thrust into it like I was. I now have become all too familiar with the SAP interfaces for external system known by the name \"IDoc\". SearchSAP.com provides the following definition:

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program.

Being relatively new to the SAP world, these complex documents reminded me of database schemas generated by the old Computer-Aided Software Engineering (CASE) tools with many cryptic table names and field names that only an automated tool could keep track of.

For example, suppose you want to create an order from an external system in the Customer Relationship Management (CRM) module of SAP. What would you expect the interface to be called? How about something like \"Create Order\"? Wrong! My client's CRM team first instructed us to use a standard IDoc going by the rather unintuitive name of \"CRMXIF_ORDER_SAVE_M02\". Shortly later, they decided that this standard IDoc would not meet all their business requirements and they created a new IDoc from the standard one and gave it a name they prefixed with a \"Z\" and added a different ending. I will stick with the standard create order IDoc for this post, however. Ok, suppose you get past that detail, get into the right IDoc and start looking for the data representing the order header. Do you find it under something like \"Order Header\" or \"Order\"? No! Try looking for something SAP calls a \"segment\" and whose name is \"E101CRMXIF_BUSTRANS\". help.sap.com has this to say about segments:
Segments form the basic building blocks of an IDoc type and are used to store the actual data. A segment type is the name of a segment and is independent of the SAP release. The segment definition is the release-specific name of a segment. By combining the segment type and the release, the required segment definition can be determined: This way, you can assign segment definitions from previous releases to an IDoc type in the current release. This may be necessary if, for example, the partner is using an older release which supports your current IDoc type but not your current segment definitions. You then have to \"reset\" these in the \"StructurePartner profiles .

This segment type name is not completely random but is based on the phrase \"business transaction\" instead of order. I believe the addition of \"E101CRMXIF_\" to the beginning makes the segment type release-specific and specifies the segment definition.

Each segment can in turn have multiple fields. Some of these fields can contain data defined by another segment. These can be optional or mandatory. One segment can have a 1:1 or 1:n relationship with another segment. For example, the standard E101CRMXIF_BUSTRANS segment looks like this when I look at it in the XML editor of Rational Software Architect v7 (though truncated to what would display on my screen and still be readable): Note that the order segment has many individual elements (mostly strings) followed my many references to other segments. The graphical representation looks a lot like an object model or database design. An entire SAP IDoc can be huge! The entire IDoc for orders includes well over 200 IDoc segments. After I used my XML editor to format the XML schema of CRMXIF_ORDER_SAVE_M02 so that it was neatly indented and had line feeds before each level of nesting, the resulting XML schema file was a mere 38257 lines long. If your next project takes you down to the implementation level of SAP, I hope you're a detail-oriented person.

Copyright © 2007 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.

"}]

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.

Copyright © 2007 by Philip Hartman - All Rights Reserved

","url":"https://beta.hubhopper.co/episode/perils-of-over-customizing-sap-broken-reports-1584697834/2746732","publication":[{"@type":"BroadcastEvent","publishedOn":{"@type":"BroadcastService","url":"https://mcdn.podbean.com/mf/web/y8my4/over_cust_sap_broken_rpt.mp3"},"startDate":"2007-12-18T23:42:59.000Z"},{"@type":"OnDemandEvent","startDate":"2007-12-18T23:42:59.000Z"}]},{"@type":"RadioEpisode","name":"The Global Lifestyle Time Challenge","description":"

I had a subtle career milestone today. Today I became fully aware that I was now \"Global\" ... with a capital \"G\" I think.

At about 6:30 am Central time I checked email at home before leaving for the airport. I saw an email from a business leader in the UK which set off alarms in my head that an important business decision my client needed to make was not being addressed. Knowing that a politically important deadline is approaching, I fired off a \"this is a big issue!\" email designed to alarm my readers that something important was not happening.

About 8 am Central time today I was waiting for a flight at the airport and my cell phone went off. It was that same business leader in the UK who took notice of my alarm. I don't know about you, but I don't get cell phone calls from people I've never met from other countries every day.

Shortly after arriving at my destination on the East Coast of the US, I scheduled a web meeting for tomorrow morning between people in Baltimore, Raleigh, California, and Beijing.

Later I was on a call between the US and Canada talking about interfaces to a system in China.

Still later I discussed architecture diagrams showing system components in Rochester (NY), Boulder, Dallas, Tulsa, Phoenix, Hong Kong, Beijing, and Toronto. I tried to figure out if the component in Hong Kong was really necessary. Could it be co-located with the rest of the stuff in Beijing?

I ate a hurried dinner of Tandoori Takki with two co-workers. One is a Norwegian citizen born in China but holding an American green card and the other was born in India but has been working in the US for a while. My history is boring compared to theirs.

Five minutes after checking into my hotel, I joined a conference call between the US and China but the co-worker from China didn't make the call. My co-worker later came online in China on instant messenger later and I pinged him about the call he missed. It turned out he was double booked for that timeslot. Heavy sigh. When are we going to solve time zone issues for calendars? I made sure he had the information for the web meeting in 9 hours.

This globalization thing isn't all its cracked up to be. Exactly when is it I am supposed to have some calm moments to think? When is it I am supposed to get more exercize like my doctor told me? Will the guy in California get up to make the web meeting at 6 am his time? Did I even have a right to call a web meeting that required someone to be there at 6 am? Will the guy in Beijing who has to join at 9 pm his time have a decent Internet connection? Did I have a choice on the time given that the guy we want to talk to was available then and it was a comfortable 9 am for him? Will my flight home on Friday be on time so I can make my daughter's piano recital? How early do I set my alarm clock for tomorrow? Early enough to hit the hotel treadmill or late enough to get another hour of sleep?

I have another trip to China coming up in two weeks. It is still fun for now. I can see how this could get old. I would love to hear how my readers in similar situations are handling the demanding hours, encroachment upon personal time, cultural differences, etc.

FYI, globalization has been a frequent topic of mine. You might take a look at some previous posts such as:

Copyright © 2007 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.

","url":"https://beta.hubhopper.co/episode/the-global-lifestyle-time-challenge-1584697835/2746799","publication":[{"@type":"BroadcastEvent","publishedOn":{"@type":"BroadcastService","url":"https://mcdn.podbean.com/mf/web/7wefs/global_lifestyle.mp3"},"startDate":"2007-12-18T23:22:31.000Z"},{"@type":"OnDemandEvent","startDate":"2007-12-18T23:22:31.000Z"}]},{"@type":"RadioEpisode","name":"Learn to Love Your SAP IDoc","description":"Over a year ago, I had a post in which I discussed how difficult it is for a custom application development person like myself to get adjusted to projects based on a packaged application like SAP. It had the somewhat humorous title How to Talk to an SAP Consultant (If You Must). If you keep reading this post, you will see that I am now starting to understand some of the SAP terminology which once seemed so incomprehensible. I hope you will find this post helps accelerate your own understanding of SAP if you are thrust into it like I was. I now have become all too familiar with the SAP interfaces for external system known by the name \"IDoc\". SearchSAP.com provides the following definition:

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program.

Being relatively new to the SAP world, these complex documents reminded me of database schemas generated by the old Computer-Aided Software Engineering (CASE) tools with many cryptic table names and field names that only an automated tool could keep track of.

For example, suppose you want to create an order from an external system in the Customer Relationship Management (CRM) module of SAP. What would you expect the interface to be called? How about something like \"Create Order\"? Wrong! My client's CRM team first instructed us to use a standard IDoc going by the rather unintuitive name of \"CRMXIF_ORDER_SAVE_M02\". Shortly later, they decided that this standard IDoc would not meet all their business requirements and they created a new IDoc from the standard one and gave it a name they prefixed with a \"Z\" and added a different ending. I will stick with the standard create order IDoc for this post, however. Ok, suppose you get past that detail, get into the right IDoc and start looking for the data representing the order header. Do you find it under something like \"Order Header\" or \"Order\"? No! Try looking for something SAP calls a \"segment\" and whose name is \"E101CRMXIF_BUSTRANS\". help.sap.com has this to say about segments:
Segments form the basic building blocks of an IDoc type and are used to store the actual data. A segment type is the name of a segment and is independent of the SAP release. The segment definition is the release-specific name of a segment. By combining the segment type and the release, the required segment definition can be determined: This way, you can assign segment definitions from previous releases to an IDoc type in the current release. This may be necessary if, for example, the partner is using an older release which supports your current IDoc type but not your current segment definitions. You then have to \"reset\" these in the \"StructurePartner profiles .

This segment type name is not completely random but is based on the phrase \"business transaction\" instead of order. I believe the addition of \"E101CRMXIF_\" to the beginning makes the segment type release-specific and specifies the segment definition.

Each segment can in turn have multiple fields. Some of these fields can contain data defined by another segment. These can be optional or mandatory. One segment can have a 1:1 or 1:n relationship with another segment. For example, the standard E101CRMXIF_BUSTRANS segment looks like this when I look at it in the XML editor of Rational Software Architect v7 (though truncated to what would display on my screen and still be readable): Note that the order segment has many individual elements (mostly strings) followed my many references to other segments. The graphical representation looks a lot like an object model or database design. An entire SAP IDoc can be huge! The entire IDoc for orders includes well over 200 IDoc segments. After I used my XML editor to format the XML schema of CRMXIF_ORDER_SAVE_M02 so that it was neatly indented and had line feeds before each level of nesting, the resulting XML schema file was a mere 38257 lines long. If your next project takes you down to the implementation level of SAP, I hope you're a detail-oriented person.

Copyright © 2007 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.

","url":"https://beta.hubhopper.co/episode/learn-to-love-your-sap-idoc-1584697835/2746855","publication":[{"@type":"BroadcastEvent","publishedOn":{"@type":"BroadcastService","url":"https://mcdn.podbean.com/mf/web/3hhdzy/love_idoc.mp3"},"startDate":"2007-12-18T23:10:25.000Z"},{"@type":"OnDemandEvent","startDate":"2007-12-18T23:10:25.000Z"}]}]}