So, I was back in the trenches. Most of the projects were enhancements of existing systems, while building up to a replacement of the main loan application processing system. I did a little project management along with Business Analysis on smaller projects.
One thing I did get some time to research was Business Rules, starting with the Business Rules Manifesto, and reading of proponents like Ron Ross. I worked on getting Business Rules defined explicitly in the company's requirements documents, which went well; I also attended 2 Business Rule Forum conferences, and did a track session at one of them on our use of rules in requirements.
I did the track session because it reached the point where I had been to enough conferences over the years that I thought I had something I could offer, rather than just attend. The conference organizers seemed to agree, as I did a few other Business Analyst World conferences on how I was doing requirements work.
Also, I had been ignoring the rise of blogs, until it became apparent to me at some point that it wasn't just for young people sharing their feelings and thoughts on movies; blogs on business and IT topics were emerging, and again I saw them and thought "I can do this", so I started this blog and did one over on IT Toolbox for a while. Being a Business Analyst can mean writing a lot, and I have found the blog a great outlet for writing that is not specifically for a project. I highly recommend it...
Tuesday, December 29, 2009
Thursday, December 24, 2009
Memories of IT - 2002 - DHL was fun while it lasted...
DHL Systems was located in the Bay area because it was felt that’s where the skilled systems people were. True enough, although the tech bubble had burst by now. Overall when I joined, DHL was owned by a combination of Deustche Post, Japan Airlines, and family of the original founders; then the Germans bought out JAL or something, and ended up as majority owners. (That’s why DHL vans and planes went from white with red/blue to yellow with black.) At some point someone in Deutschland decided that the Bay area was too expensive, so in December 2001, DHL Systems was ended. The operational part that ran the comm network moved to Arizona, but ATP was mostly dismantled and most of my friends end-dated. I think there was a lot of payback going on for past politics and disagreements. Somehow I, amongst a couple of other people, was offered a job elsewhere. Mine was in the London systems office I had visited. However, the salary was average, and not much was offered to help me and my family move. I also looked into what it would cost to put my sons in ‘american school’ in the UK, and that killed it. Probably for the best, as later on the London office was closed and the jobs moved to Prague. Nothing against Prague, never been there, hear its lovely, but I think it would have been too much of a culture shock.
…but, I am in the USA on an H1B sponsored by DHL. I start looking for a new job, but it’s a slim market, and no company wants to take over sponsoring me, so after some months its clear we have to move back to Canada if I was going to get work… so pack up and move, decide on Kitchener-Waterloo because we had been there before, my wife gets a job first, and then I get back into the workforce as a BA at a captive finance company, like GMAC, but it was for farm and construction equipment. So, out of the ivory tower and back into the trenches.
Afterword: I and my family certainly did like that time we spent in the Bay Area. Three out of 4 seasons was fine, although my son would go on school ski trips to Tahoe. We especially liked heading down to Monterrey and Carmel for weekends, and even just to Half-Moon Bay for the day, and drive up the coast to San Francisco. When I win the lottery, there is a little place on Monterrey Bay I may have to invest in...
…but, I am in the USA on an H1B sponsored by DHL. I start looking for a new job, but it’s a slim market, and no company wants to take over sponsoring me, so after some months its clear we have to move back to Canada if I was going to get work… so pack up and move, decide on Kitchener-Waterloo because we had been there before, my wife gets a job first, and then I get back into the workforce as a BA at a captive finance company, like GMAC, but it was for farm and construction equipment. So, out of the ivory tower and back into the trenches.
Afterword: I and my family certainly did like that time we spent in the Bay Area. Three out of 4 seasons was fine, although my son would go on school ski trips to Tahoe. We especially liked heading down to Monterrey and Carmel for weekends, and even just to Half-Moon Bay for the day, and drive up the coast to San Francisco. When I win the lottery, there is a little place on Monterrey Bay I may have to invest in...
Thursday, December 17, 2009
Memories of IT - 2000's - Architecture and the Ivory Tower
As the bringers of the new Architecture, we would get assigned to projects around DHL that say (or are told) that it will use the new way. The PMs would initially be happy, looking at us as another resource for their project. The shine would rub off when we recommended using the new methods to plan the project, especially if the PM had already built a plan. The other team members might get on board or, if the new way was very different from what they had been doing, they might resist. Eventually heated discussions would ensue, long conference calls, at odd hours depending where in the world the project team was.
The usual issue was the iterative aspect of the new architecture, which PMs or higher ups would be uncomfortable with because they wanted a completion date while we were looking to time-box the work and deliver what could be done in that time. Once during an all-hands IT meeting (DHL Systems and DHL USA), one of our key people raised a question about adoption of the architecture, and the senior guy in the room said iteration was never going to work in the real world. A sign of things to come…
The other angle in all this was that our Director actually reported to a VP in DHL central systems in London, U.K. This did mean that we would travel there and back on occasion. Having not been to the UK for decades, it was nice bonus, visited a few spots of interest; dropped over to Brussels once where DHL is actually headquartered, but all I saw was the airport, hotel and the office. The atmosphere in both locations was thoroughly byzantine, highly political, people jostling for position, you never knew when something you said might be turned around and used to bite you…didn’t happen to me but I saw it happen to others. The “Architecture” was often at the center of all this.
The thing was, though, the people I worked with in ATP are among the finest, smartest people I have ever known, so going to work was still great even with all the outside issues.
Quick aside: DHL was in the news a while back, and I know how it started. Back in 2000, DHL had no internal USA business to speak of; DHL was known rightly for being international. It also had a stupid way of measuring how it made money. Each country had its own DHL Corporation. Each one made money on shipments originating in its country, but got nothing for delivering shipments sent to their country, The USA got way more shipments sent to it than were sent out, so it always ‘lost money’, so whoever was running DHL USA looked bad. When I had this explained to me for the first time, I just could not believe it. I have to think that US management complained about this, but it wasn’t going to change.
So instead of more fairly reporting the real profits, DHL decided it would get into the domestic shipping business up against Fedex and UPS. They bought the smaller player Airborne Express, and then you started seeing yellow DHL trucks on the roads.
Well, seems to have not worked as DHL has announced it is getting out of US domestic shipping, going back to their focus on international shipping; hope they fixed their income reporting.
The usual issue was the iterative aspect of the new architecture, which PMs or higher ups would be uncomfortable with because they wanted a completion date while we were looking to time-box the work and deliver what could be done in that time. Once during an all-hands IT meeting (DHL Systems and DHL USA), one of our key people raised a question about adoption of the architecture, and the senior guy in the room said iteration was never going to work in the real world. A sign of things to come…
The other angle in all this was that our Director actually reported to a VP in DHL central systems in London, U.K. This did mean that we would travel there and back on occasion. Having not been to the UK for decades, it was nice bonus, visited a few spots of interest; dropped over to Brussels once where DHL is actually headquartered, but all I saw was the airport, hotel and the office. The atmosphere in both locations was thoroughly byzantine, highly political, people jostling for position, you never knew when something you said might be turned around and used to bite you…didn’t happen to me but I saw it happen to others. The “Architecture” was often at the center of all this.
The thing was, though, the people I worked with in ATP are among the finest, smartest people I have ever known, so going to work was still great even with all the outside issues.
Quick aside: DHL was in the news a while back, and I know how it started. Back in 2000, DHL had no internal USA business to speak of; DHL was known rightly for being international. It also had a stupid way of measuring how it made money. Each country had its own DHL Corporation. Each one made money on shipments originating in its country, but got nothing for delivering shipments sent to their country, The USA got way more shipments sent to it than were sent out, so it always ‘lost money’, so whoever was running DHL USA looked bad. When I had this explained to me for the first time, I just could not believe it. I have to think that US management complained about this, but it wasn’t going to change.
So instead of more fairly reporting the real profits, DHL decided it would get into the domestic shipping business up against Fedex and UPS. They bought the smaller player Airborne Express, and then you started seeing yellow DHL trucks on the roads.
Well, seems to have not worked as DHL has announced it is getting out of US domestic shipping, going back to their focus on international shipping; hope they fixed their income reporting.
Tuesday, December 15, 2009
Memories of IT - 2001 - B2B and early days of Rosettanet
After the Shipment Tracking project was over, I spent the next year working on several things, overlapping and simultaneously.
One cool thing was Rosettanet, the standards-based B2B architecture being developed, mainly driven first by IT and electronics companies. The idea was to define a set of supply-chain messages that companies could use with other companies who used the architecture. So, once you started using the message with one other company, you could then use them to communicate with other Rosettanet –using companies with little to no added effort.
One of the key set of messages had to do with making shipments of orders through a delivery company like DHL, including getting shipment status, and notice of delivery. So, Frank and I signed on as the representatives for DHL, and joined a working that included reps from Federal Express, UPS and a few smaller players.
The main deliverable consisted of XML message formats, with all the data defined that would need to pass from sender to receiver. ( A lot of the other messages sets were about automatically checking a suppliers inventory for desired product, then making the product order, and the supplier confirming the order, shipping --- which was our part ---, followed by invoicing. When we signed up, there were upwards of 100 individual messages defined, and about half had been created, and the first companies were starting to use them.)
Our messages were drafted during a couple days of meetings with all the reps, at a Fedex Ground location outside Pittsburgh. We took along an actual business person from DHL USA (also located near San Francisco) for Shipment knowledge. DHL’s acknowledged expertise at that time was in international shipments, so a lot of the message content about customs clearance came straight from us.
After that, we met weekly by conference call to iron out the final versions, after which they went through a formal Rosettanet review and approval process, after which they were published. The interesting thing about Rosettanet was the published services were free for any company to use, to spread their use, obviously. The core companies like IBM and others provided the most, and it cost to join in order to participate in development of the messages, worth the money if you made sure the messages were going to work for you.
I also went to one Rosettnet User Conference, in Chicago. A lot of it was about how to implement and start using Rosettanet at a company, with all day sessions or various tracks of one hour sessions, like most conferences. The basic structure was to have software sit in front of a company’s existing order and inventory systems, extract data as needed from them, use it to create the standard message and send them off. The same software would do the reverse as well, accepts messages, parse out the data and feed the existing systems. As you might expect, a number of vendors in the B2B space had already built and were hawking software packages to do just that, including services to automate the extracts from and feeds to existing systems. So, all the vendors were at the conference, of course. That always meant some free food and drinks and entertainment, which always helps make any conference more enjoyable.
In the end, the interesting thing was that some months later, Cisco and DHL entered into a logistics agreement, where DHL would warehouse Cisco parts around the world and deliver the parts when directed by Cisco…and their requirement was that these shipments would be triggered automatically using Rosettanet messages.
Anyway, its still out there, see www.rosettanet.org , check it out if you are serious about B2B...
One cool thing was Rosettanet, the standards-based B2B architecture being developed, mainly driven first by IT and electronics companies. The idea was to define a set of supply-chain messages that companies could use with other companies who used the architecture. So, once you started using the message with one other company, you could then use them to communicate with other Rosettanet –using companies with little to no added effort.
One of the key set of messages had to do with making shipments of orders through a delivery company like DHL, including getting shipment status, and notice of delivery. So, Frank and I signed on as the representatives for DHL, and joined a working that included reps from Federal Express, UPS and a few smaller players.
The main deliverable consisted of XML message formats, with all the data defined that would need to pass from sender to receiver. ( A lot of the other messages sets were about automatically checking a suppliers inventory for desired product, then making the product order, and the supplier confirming the order, shipping --- which was our part ---, followed by invoicing. When we signed up, there were upwards of 100 individual messages defined, and about half had been created, and the first companies were starting to use them.)
Our messages were drafted during a couple days of meetings with all the reps, at a Fedex Ground location outside Pittsburgh. We took along an actual business person from DHL USA (also located near San Francisco) for Shipment knowledge. DHL’s acknowledged expertise at that time was in international shipments, so a lot of the message content about customs clearance came straight from us.
After that, we met weekly by conference call to iron out the final versions, after which they went through a formal Rosettanet review and approval process, after which they were published. The interesting thing about Rosettanet was the published services were free for any company to use, to spread their use, obviously. The core companies like IBM and others provided the most, and it cost to join in order to participate in development of the messages, worth the money if you made sure the messages were going to work for you.
I also went to one Rosettnet User Conference, in Chicago. A lot of it was about how to implement and start using Rosettanet at a company, with all day sessions or various tracks of one hour sessions, like most conferences. The basic structure was to have software sit in front of a company’s existing order and inventory systems, extract data as needed from them, use it to create the standard message and send them off. The same software would do the reverse as well, accepts messages, parse out the data and feed the existing systems. As you might expect, a number of vendors in the B2B space had already built and were hawking software packages to do just that, including services to automate the extracts from and feeds to existing systems. So, all the vendors were at the conference, of course. That always meant some free food and drinks and entertainment, which always helps make any conference more enjoyable.
In the end, the interesting thing was that some months later, Cisco and DHL entered into a logistics agreement, where DHL would warehouse Cisco parts around the world and deliver the parts when directed by Cisco…and their requirement was that these shipments would be triggered automatically using Rosettanet messages.
Anyway, its still out there, see www.rosettanet.org , check it out if you are serious about B2B...
Monday, December 14, 2009
Memories of IT - 2001 - Arguments over interfaces...solved.
So, I deliver Use Cases and design/development begins. My group designs a service and interface following the Architecture. The KL systems people want a specific date/time-stamp form an existing system in the interface; our lead designer says no, that any other system using the interface should not know where the data provided came from, so that the service can be changed in the future without disrupting any systems using the service…. Things got quite heated. In a moment of prescience, upon hearing of this argument, I stepped in and said that this was a requirement issue, not a design issue. The date/time-stamp was actually the time a Shipment was first recorded in a DHL System. I added that date to our data model, then added it to the Use Cases, and the argument ended, at least publicly… there always seem to be some level of discord between DHL Systems ATP and Systems areas in DHL. We actually printed a poster of a white tower and put it on the wall heading into our office.
So, design and development went ahead for the pilot, was accepted, and then went live. For some period of time, at least, when you searched for your Shipment on DHL.com, you used a service based on my Use Cases.
So, design and development went ahead for the pilot, was accepted, and then went live. For some period of time, at least, when you searched for your Shipment on DHL.com, you used a service based on my Use Cases.
Friday, December 11, 2009
Memories of IT - 2001 - Architectures, RUP, Iterative, BEA and other stuff in the life of Architecture Technology Pathfinding (ATP)
This pilot was the first real test of the work of the group I had joined, known as Architecture Technology Pathfinding(ATP). The architecture in the title was actually multiple architectures, and multiple uses of the word.
The main Architecture was about application structure, and it was a detailed description of an N-Tier environment, with interfaces invoking Business Services which would then invoke Data Services and such. The implementation of it was based around the BEA web server product, and DHL Systems had in fact been an early customer and supporter.
But how do you define the applications? We were strong adherents to the Zachman Architecture Framework for starting with concepts, then models, then implementations of models down to code. Frank and I were focused on the Data Column of Zachman, with overlap into the Process column when defining the CRUD functions on data. In the application architecture these CRUD functions were the lowest level services that supported everything else. The overall approach across the architecture was service-based, with a service being defined and made available through an exposed interface, so that everything behind the interface was unaffected by what used it (and vice-versa) as long as it could provide what the interface said it needed. Very OO, of course, and a hint of SOA (which had not appeared as a term yet).
The other main use of ‘architecture’ was that as used in RUP, summarized as development of an application by first creating an overall architecture for the app, and then building it up in the multiple iteration approach of RUP (not Agile, which wasn’t a well-known term yet either). Selling RUP and its iterative approach was a big desire of the key people in ATP, as a means of moving away from a big-bang approach to development that had failed in the past.
The thing was, it had to be sold to IT execs in DHL proper, and there was one of those for almost every country in the world (although we focused on the USA and Europe as the likely place that success of RUP would then spread from.) Many an IT exec had blown off iterative, mainly because it was believed you could not define a specific end date for iterative development, and so you could not estimate it. The fact that past projects with planned target dates and estimates had usually missed both by wide margins didn’t count. The execs wanted something that made big-bang work, not something different they could not understand or felt they could control. However, the whole combined Architecture approach espoused by ATP had taken some time to develop, and had involved some other DHL areas, so it could not just be ignored. That is why the pilot for Shipment Tracking was devised, to illustrate the use of the Architecture and Methods. The complications came when the design started and some non-believers tried to undercut the whole thing….more next time.
The main Architecture was about application structure, and it was a detailed description of an N-Tier environment, with interfaces invoking Business Services which would then invoke Data Services and such. The implementation of it was based around the BEA web server product, and DHL Systems had in fact been an early customer and supporter.
But how do you define the applications? We were strong adherents to the Zachman Architecture Framework for starting with concepts, then models, then implementations of models down to code. Frank and I were focused on the Data Column of Zachman, with overlap into the Process column when defining the CRUD functions on data. In the application architecture these CRUD functions were the lowest level services that supported everything else. The overall approach across the architecture was service-based, with a service being defined and made available through an exposed interface, so that everything behind the interface was unaffected by what used it (and vice-versa) as long as it could provide what the interface said it needed. Very OO, of course, and a hint of SOA (which had not appeared as a term yet).
The other main use of ‘architecture’ was that as used in RUP, summarized as development of an application by first creating an overall architecture for the app, and then building it up in the multiple iteration approach of RUP (not Agile, which wasn’t a well-known term yet either). Selling RUP and its iterative approach was a big desire of the key people in ATP, as a means of moving away from a big-bang approach to development that had failed in the past.
The thing was, it had to be sold to IT execs in DHL proper, and there was one of those for almost every country in the world (although we focused on the USA and Europe as the likely place that success of RUP would then spread from.) Many an IT exec had blown off iterative, mainly because it was believed you could not define a specific end date for iterative development, and so you could not estimate it. The fact that past projects with planned target dates and estimates had usually missed both by wide margins didn’t count. The execs wanted something that made big-bang work, not something different they could not understand or felt they could control. However, the whole combined Architecture approach espoused by ATP had taken some time to develop, and had involved some other DHL areas, so it could not just be ignored. That is why the pilot for Shipment Tracking was devised, to illustrate the use of the Architecture and Methods. The complications came when the design started and some non-believers tried to undercut the whole thing….more next time.
Tuesday, December 08, 2009
Memories of IT - 2000 - ERDs, OO, UML, Use Cases and all that
The first thing I did at DHL Systems was learn and use Rational Rose, and learn more about the RUP methodology. The aim was to figure out how to marry classic ERD data models with the Object-Oriented development modeling, especially the Class Diagram. This actually involved a lot of discussion with the OO experts in our group. I even went on another UML course (my first visit to Denver), but I still wasn’t grokking it. I also read one of those “UML for Business Modeling” books, but it didn’t help.
So, I translated some of the existing ERD models into Class Diagrams, and then tried my hand at some Activity Diagrams to model how some Classes would be created in a business transaction. Frank (my boss and fellow Analyst) and I showed these to our chief OO designer/developer, and his reaction was negative. His opinion was that UML is a software design language, not be used for analysis or requirements. He stated that what OO developers needed from Business Analysts was a “concept diagram” ( a generalized Class diagram that just showed what the main things of interest are) and Conceptual Use Cases. Frank was concerned that my hard work had gone for naught, but we moved on. Our Architecture group was going to participate in a company wide pilot to use UML, OO, RUP and a new architectural approach to create new services for tracking shipments through the DHL website. My job was to first write the Conceptual Use Cases, which would be used to create a design and concrete use cases, to be vetted by DHL IT in Brussels and built by another DHL Systems group in Kuala Lumpur.
There were no business people involved directly, the KL group was positioned as our ‘customers’. As such, any requirements they had were technical and cause for much wrangling between them and the OO folks in my group (more about that later). So, I went back to the big data models built in years past because, as you might expect, they were all about Shipments and all the supporting things you needed to pick-up, send, and deliver a Shipment. I created a set of Query Use Cases based on the data models that would accept enough data to identify a shipment (or at least a short list of candidates) and return whatever data you needed about the contents of the shipment, where it was and so on. I actually thought they were pretty lame, as my IEF days had installed in me the belief that queries and reports didn’t need requirements the way Create, Update and Delete transactions did; but, they were accepted pretty well, mainly because previous attempts had produced requirements that were either too vague, or too technical… I had found the middle ground. Then the real fun began as we moved into design…
So, I translated some of the existing ERD models into Class Diagrams, and then tried my hand at some Activity Diagrams to model how some Classes would be created in a business transaction. Frank (my boss and fellow Analyst) and I showed these to our chief OO designer/developer, and his reaction was negative. His opinion was that UML is a software design language, not be used for analysis or requirements. He stated that what OO developers needed from Business Analysts was a “concept diagram” ( a generalized Class diagram that just showed what the main things of interest are) and Conceptual Use Cases. Frank was concerned that my hard work had gone for naught, but we moved on. Our Architecture group was going to participate in a company wide pilot to use UML, OO, RUP and a new architectural approach to create new services for tracking shipments through the DHL website. My job was to first write the Conceptual Use Cases, which would be used to create a design and concrete use cases, to be vetted by DHL IT in Brussels and built by another DHL Systems group in Kuala Lumpur.
There were no business people involved directly, the KL group was positioned as our ‘customers’. As such, any requirements they had were technical and cause for much wrangling between them and the OO folks in my group (more about that later). So, I went back to the big data models built in years past because, as you might expect, they were all about Shipments and all the supporting things you needed to pick-up, send, and deliver a Shipment. I created a set of Query Use Cases based on the data models that would accept enough data to identify a shipment (or at least a short list of candidates) and return whatever data you needed about the contents of the shipment, where it was and so on. I actually thought they were pretty lame, as my IEF days had installed in me the belief that queries and reports didn’t need requirements the way Create, Update and Delete transactions did; but, they were accepted pretty well, mainly because previous attempts had produced requirements that were either too vague, or too technical… I had found the middle ground. Then the real fun began as we moved into design…
Monday, December 07, 2009
Memories of IT - 2000 - A Canadian in California
For any Americans reading this post, you should know... there are Canadians amongst you. And I don't just mean Jim Carrey or Mike Myers or Neil Young or (so I am told) one of the guys on "Glee". For a while, there was also me, my wife and my two younger sons.
A true story... my wife and I were shopping at a little outdoor mall in Castro Valley CA, and there were booths set up for the day selling crafts and such. One booth, however, was for voter registration. A nice lady in that booth asked my wife as she passed if she had registered, and my wife said she couldn't, to which the lady replied with "why not?". "I'm not not a citizen" my wife told her. The Lady asked "where are you from?", and my wife replied "Canada". The nice lady then exclaimed, "Really? You look just like us!" But then she took a beat and then said "well, that was a pretty stupid thing to say...". So, we never complain about Americans or the USA, we just offer useful information when we can.
It was a big move again, of course, but my wife had always felt she should have been born in California, and we would have been there long ago if not for the world's longest undefended border. For the record, DHL sponsored me on a TN Visa and then an H1B. I know H1Bs are a touchy topic for some, but DHL was able to show that they had been looking to fill the job for a while (and they had), and had been unsuccessful until they found me.I believe that's what visas should be used for, and that it helps the USA in that case. If visas can be abused in some ways, though, that's not good.
We settled in the East Bay, first in Castro Valley then later in San Ramon. That did mean I had to drive over the San Mateo bridge every day, and it had not been widened yet. However, commuting has been something I have always done, and in a lot less interesting places than San Francisco Bay.
It was a great place to live. If you live there, you already know that. If you have never lived there, don't worry about the earthquakes or the state going bankrupt or whatever, mover there if you ever have the chance.
On other thing before I get back to the IT stuff; we actually got to California by driving to Chicago, and then taking the California Zephyr train out to Oakland. We planned it as a mini-vacation (that also meant that my wife did not have to fly..), and it was a great trip, across the plains to Denver, then up and down both the Rockies and Sierra mountains. I keep hearing they might stop running the Zephyr, but if they haven't, I highly recommend it.
A true story... my wife and I were shopping at a little outdoor mall in Castro Valley CA, and there were booths set up for the day selling crafts and such. One booth, however, was for voter registration. A nice lady in that booth asked my wife as she passed if she had registered, and my wife said she couldn't, to which the lady replied with "why not?". "I'm not not a citizen" my wife told her. The Lady asked "where are you from?", and my wife replied "Canada". The nice lady then exclaimed, "Really? You look just like us!" But then she took a beat and then said "well, that was a pretty stupid thing to say...". So, we never complain about Americans or the USA, we just offer useful information when we can.
It was a big move again, of course, but my wife had always felt she should have been born in California, and we would have been there long ago if not for the world's longest undefended border. For the record, DHL sponsored me on a TN Visa and then an H1B. I know H1Bs are a touchy topic for some, but DHL was able to show that they had been looking to fill the job for a while (and they had), and had been unsuccessful until they found me.I believe that's what visas should be used for, and that it helps the USA in that case. If visas can be abused in some ways, though, that's not good.
We settled in the East Bay, first in Castro Valley then later in San Ramon. That did mean I had to drive over the San Mateo bridge every day, and it had not been widened yet. However, commuting has been something I have always done, and in a lot less interesting places than San Francisco Bay.
It was a great place to live. If you live there, you already know that. If you have never lived there, don't worry about the earthquakes or the state going bankrupt or whatever, mover there if you ever have the chance.
On other thing before I get back to the IT stuff; we actually got to California by driving to Chicago, and then taking the California Zephyr train out to Oakland. We planned it as a mini-vacation (that also meant that my wife did not have to fly..), and it was a great trip, across the plains to Denver, then up and down both the Rockies and Sierra mountains. I keep hearing they might stop running the Zephyr, but if they haven't, I highly recommend it.
Thursday, December 03, 2009
Memories of IT - Spring, 2000 - California, here I come
Suffice it to say that I and my employer of three years parted ways in early 2000.
Through a series of timely connections and circumstances, I found myself on the phone with a fine gentleman from northern California, and that’s really when I first leaned about DHL.
Eight years ago, DHL was almost unknown in North America (and as it turns out, may be unknown again in a few years). The man who called me, his name was Frank, and he was soon to become and remains a good friend. Frank was the chief (and lone) data modeler in the architecture area of a subsidiary called DHL Systems, located in Burlingame, California. Burlingame is of those smaller cities/towns that hug the west side of San Francisco Bay between San Francisco and San Jose, just below the airport.
The group was similar to the TD group I had been in at Crown, and they were looking for a person with data modeling and information engineering experience to work for Frank. They had been having a hard time finding someone (really!), and apparently were willing to reach out far and wide in their search, and I had been found. After a good first phone conversation, they booked me a flight to San Francisco to be interviewed by Frank, his peer managers and the overall director. This was my first trip to the west coast and California, so it had the feel of an adventure. DHL Systems was in an office building right on the Bay, and I was put up at the suites hotel right next door.
Then off to a morning of interviews, lunch with the whole team at a fine restaurant also on the Bay, then back to meet with HR, during which Frank and the Director, Dee, came in and offered me the job right there and then. I was surprised, but I think I managed to respond professionally, said thanks and let me go home and talk it over with the wife and I will let you know… but it was pretty much a done deal right there and then.
Through a series of timely connections and circumstances, I found myself on the phone with a fine gentleman from northern California, and that’s really when I first leaned about DHL.
Eight years ago, DHL was almost unknown in North America (and as it turns out, may be unknown again in a few years). The man who called me, his name was Frank, and he was soon to become and remains a good friend. Frank was the chief (and lone) data modeler in the architecture area of a subsidiary called DHL Systems, located in Burlingame, California. Burlingame is of those smaller cities/towns that hug the west side of San Francisco Bay between San Francisco and San Jose, just below the airport.
The group was similar to the TD group I had been in at Crown, and they were looking for a person with data modeling and information engineering experience to work for Frank. They had been having a hard time finding someone (really!), and apparently were willing to reach out far and wide in their search, and I had been found. After a good first phone conversation, they booked me a flight to San Francisco to be interviewed by Frank, his peer managers and the overall director. This was my first trip to the west coast and California, so it had the feel of an adventure. DHL Systems was in an office building right on the Bay, and I was put up at the suites hotel right next door.
Then off to a morning of interviews, lunch with the whole team at a fine restaurant also on the Bay, then back to meet with HR, during which Frank and the Director, Dee, came in and offered me the job right there and then. I was surprised, but I think I managed to respond professionally, said thanks and let me go home and talk it over with the wife and I will let you know… but it was pretty much a done deal right there and then.
Wednesday, December 02, 2009
Memories of IT - late 90's - More projects, and ETL tools
!997, I am back in Southern Ontario, doing project work for my new insurance company employer, mostly forgettable stuff like how to restructure life insurance policies that had been sold on the promise of "Vanishing Premiums". I did escape the whole Y2K thing, so I can be thankful for that.
One interesting thing I worked on was ETL tools.I had done reading on Data Warehousing, especially Bill Inmon's seminal book on the topic. A lot of it was/is dependent on getting data from transaction systems into the DW in summarized, time-dependent structures. This was “Extract, Transform and Load”(ing) of data, ETL.
A different need for ETL came up at my new employer. Its growth had been fueled by acquiring smaller competitors. When you buy another insurance company, you get all its in-force (premium generating) polices, and all the computer systems that had been used at the company being bought. All of these systems were usually pretty unique, so my employer would end up having to run several systems for the same kind of insurance product, often variations of the same dominant insurance package system of the time. This was expensive and wasteful of resources, so the inherent desire was to migrate all the policies on all the acquired systems on to the latest/greatest system being used for new business.
That ain’t easy. Insurance is a non-physical product, so actuaries can dream up almost anything that they can sell and make money, and systems have to be customized to support very unique products. So the first hard thing to do was to figure out what the products/policies on the old systems really were, and if the new system could support them. That might mean the new system needs to be changed. After that, you have to get the data out of the old system, and get it into a format the new system could read and use to add policies. That could mean a lot of complicated and time-consuming programming, to create code that would only be used once, when the conversion from old to new system is done. My feeling was there had to be a better way, and a quick check of the marketplace showed that commercial ETL products were now available. I wanted something where the interface matched source data to the target database, accepted transformation rules, handled different types of files and databases, and generated the code to do the ETL process.
I found many such tools, and recommended we investigate them to acquire one to save time on ETL programming, as we had so many conversions to do and probably more coming in the future. I was in a line area, and most tech evals were done centrally, so I contacted the central area and they said they had no time, so go ahead yourself. So I contacted people in other line areas who agreed this might help them too, and got a part-time team together, generated requirements and went out and evaluated tools.
The best one was a product from an Austin company called ETI. It emerged from a research think-tank that major vendors and universities supported. It did exactly what I describe above.
I did up a full cost-benefit analysis, showed it was a good buy, and it had to go up to my VPs boss for approval because of all the other areas involved.
So we get the tool in, I and another analyst get trained, and we are lined up to do the next project, and then the push-back begins. The lead programmer decides she doesn’t want to get trained because she would have to travel, and she doesn’t like to travel, and the PM says OK. It becomes apparent that despite a good cost-benefit and management approval, programmers and some analysts don’t think much of the ETL tool; generating code meant no programming, and who wants that? They could not see that it meant no boring, repetitive programming, freeing up resources for new, interesting stuff.
So the whole thing stalled, which can happen when trying to implement change that frightens some people. It was too bad, the tool really worked as advertised. It was a sign...
One interesting thing I worked on was ETL tools.I had done reading on Data Warehousing, especially Bill Inmon's seminal book on the topic. A lot of it was/is dependent on getting data from transaction systems into the DW in summarized, time-dependent structures. This was “Extract, Transform and Load”(ing) of data, ETL.
A different need for ETL came up at my new employer. Its growth had been fueled by acquiring smaller competitors. When you buy another insurance company, you get all its in-force (premium generating) polices, and all the computer systems that had been used at the company being bought. All of these systems were usually pretty unique, so my employer would end up having to run several systems for the same kind of insurance product, often variations of the same dominant insurance package system of the time. This was expensive and wasteful of resources, so the inherent desire was to migrate all the policies on all the acquired systems on to the latest/greatest system being used for new business.
That ain’t easy. Insurance is a non-physical product, so actuaries can dream up almost anything that they can sell and make money, and systems have to be customized to support very unique products. So the first hard thing to do was to figure out what the products/policies on the old systems really were, and if the new system could support them. That might mean the new system needs to be changed. After that, you have to get the data out of the old system, and get it into a format the new system could read and use to add policies. That could mean a lot of complicated and time-consuming programming, to create code that would only be used once, when the conversion from old to new system is done. My feeling was there had to be a better way, and a quick check of the marketplace showed that commercial ETL products were now available. I wanted something where the interface matched source data to the target database, accepted transformation rules, handled different types of files and databases, and generated the code to do the ETL process.
I found many such tools, and recommended we investigate them to acquire one to save time on ETL programming, as we had so many conversions to do and probably more coming in the future. I was in a line area, and most tech evals were done centrally, so I contacted the central area and they said they had no time, so go ahead yourself. So I contacted people in other line areas who agreed this might help them too, and got a part-time team together, generated requirements and went out and evaluated tools.
The best one was a product from an Austin company called ETI. It emerged from a research think-tank that major vendors and universities supported. It did exactly what I describe above.
I did up a full cost-benefit analysis, showed it was a good buy, and it had to go up to my VPs boss for approval because of all the other areas involved.
So we get the tool in, I and another analyst get trained, and we are lined up to do the next project, and then the push-back begins. The lead programmer decides she doesn’t want to get trained because she would have to travel, and she doesn’t like to travel, and the PM says OK. It becomes apparent that despite a good cost-benefit and management approval, programmers and some analysts don’t think much of the ETL tool; generating code meant no programming, and who wants that? They could not see that it meant no boring, repetitive programming, freeing up resources for new, interesting stuff.
So the whole thing stalled, which can happen when trying to implement change that frightens some people. It was too bad, the tool really worked as advertised. It was a sign...
Tuesday, December 01, 2009
Memories of IT - 1997 - Salary, Regina and time for moving on...
One of the reasons for moving a company from Toronto to Regina is lower pay scales for your staff. If you moved from Toronto, you kept your current salary, but very quickly one raise or two would get you to the top of your job’s salary range and from then on your boss would say every year “I am really sorry, but no raise for you”.
Now, whether I really needed 2% raises or not, when this starts happening, you get annoyed. Also, some of what I used to do in TD about methodology was now thought to be needed again, and at a higher job level. I thought this sounded good and applied to the new position, All the people I worked with saw the job posting and said “Dave, that job is so you!” My application came back with a note that I was not right for the job. The HR person who told me this said that the senior IT VP hiring the position, who I had helped with methodology before, said he would be willing to meet with me if I wanted to discuss his decision, possibly a attempt to placate me as he was hiring somebody from outside the company he had worked with before. I most politely declined the offer, because I was steaming mad inside, and I may just have blown-up if I saw that VP. I shared this with someone I trusted and he said I had done the right thing.
This was also happening during my fourth winter in Regina, a horrible winter. So, all these factors came to a head and led me into an active search for a new job somewhere else. This was big decision, as I had worked at Crown Life for 17 years. It took a few months and I got an offer from a big insurance back in Ontario who would pay to move us back. I jumped at it.
Now, whether I really needed 2% raises or not, when this starts happening, you get annoyed. Also, some of what I used to do in TD about methodology was now thought to be needed again, and at a higher job level. I thought this sounded good and applied to the new position, All the people I worked with saw the job posting and said “Dave, that job is so you!” My application came back with a note that I was not right for the job. The HR person who told me this said that the senior IT VP hiring the position, who I had helped with methodology before, said he would be willing to meet with me if I wanted to discuss his decision, possibly a attempt to placate me as he was hiring somebody from outside the company he had worked with before. I most politely declined the offer, because I was steaming mad inside, and I may just have blown-up if I saw that VP. I shared this with someone I trusted and he said I had done the right thing.
This was also happening during my fourth winter in Regina, a horrible winter. So, all these factors came to a head and led me into an active search for a new job somewhere else. This was big decision, as I had worked at Crown Life for 17 years. It took a few months and I got an offer from a big insurance back in Ontario who would pay to move us back. I jumped at it.
Subscribe to:
Posts (Atom)