What I Learned at TRW Credit Data about Enterprise IT

This post continues my look back at lessons learned from my career in enterprise IT. My first such job, at Macy’s headquarters in New York City, came to an end in late 1976 when Dorothy and I, now with an infant daughter, Susanna, moved to Southern California. 

In that first post I shared how, starting as a trainee, I eventually took over support for Macy’s daily credit card billing cycle. I was also responsible for the export of customer information for monthly submission to TRW Credit Data. Now known as Experian, it was and still is one of the three major consumer credit reporting services in U.S. When I announced my decision to relocate to Southern California, my primary user manager, the Accounts Receivable director, graciously offered to pass my name on to his sales rep from TRW Credit Data, which just so happened to be based in Orange County. 

That referral turned out to be critically important. When I arrived in SoCal, I started responding to classified ads and had three job offers within two weeks.¹ But the offer from TRW was the best. Some months later, my new manager, Rick Range, told me, “I don’t know what kind of pull you had back at Macy’s, but our sales rep was pretty insistent that I had to interview you.” 

Lesson Learned: Value every business relationship. You never know which ones will be instrumental in the future. And, be sure to “pay it forward” whenever you can. Today, LinkedIn and other social networking sites make it easy to stay connected, but too often we still do not maintain those relationships. 
 

One of the World’s Largest Data Centers

At the time I was hired, the offices and data center of TRW Credit Data (officially, Information Systems & Services, or IS&S) were in unmarked buildings on Katella Avenue in Anaheim.² The data center at 1761 W. Katella was one of largest in the world in terms of storage. Maintaining credit history on over 200 million Americans took a lot of disk drives in those days. The photo at the top of this post (source) shows the disk drive farm from the early 1980s, a good five to eight years after I worked there, but it gives a sense of how enormous it was. At the time I was there, there was one IBM mainframe and one Amdahl plug-compatible machine, to maintain some balance of power with IBM. 

It was such an impressive site that it served as a location for the 1985 film Prime Risk. The screen shot below is from that film. 
 

 

Dumpster Diving

On my first day, Rick gave me a facility tour, including a walk through that data center. But there was an unusual stop on the tour. Rick took me out behind the data center to the loading dock, where there were several large dumpsters filled with green bar computer printouts to be scrapped. They all had locks on them. He explained that, in the past, criminals had searched through those dumpsters and had obtained access credentials into TRW’s consumer credit database, which they used to steal credit card numbers. This led TRW to secure those dumpsters. 

Lesson Learned: Everyone in the enterprise must be security-minded. Many people think IT security and identity theft only became a problem with the dawn of the Internet. Not true: It was a problem back in the 1970s, and TRW took active countermeasures against it. Security not only included technical measures, but also physical security, such as securing dumpsters. Moreover, it was not just outsiders who were a threat. The company was highly sensitive to insider threats—employees inappropriately accessing credit reports, either out of curiosity or for more nefarious reasons. The system monitored all access and audited which employees accessed which credit reports. If you accessed a credit report for no legitimate reason you could be fired on the spot. 
 

A Theoretical Foundation in Software Development

Because of my experience with accounts receivable, Rick assigned me to the subscriber billing system, which was written in COBOL. I also developed new systems for sales reporting and a new system to handle billing for a new credit reporting system acquired by TRW. As I’ll note shortly, I was only at TRW for about 18 months, but I wrote a lot of software.³ 

It was also a great place to develop my programming and software design skills, with courses taught in house. I also enrolled in several graduate courses at the University of California Irvine (UCI), which was and still is one of the top schools in the country for computer science. It was also convenient, being only about a mile from our home. 

My favorite course was Introduction to Software Engineering, taught by Peter Freeman, who later went to Georgia Tech the become the Founding Dean of the College of Computing. Despite the name, the course was anything but elementary. We covered the work of software luminaries such as Ed Yourdon, Daniel Teichroew, Ed Dijkstra, B. H. Liscov, Michael Jackson, Grady Booch, Fred Brooks, and Glenford Meyers. Professor Barry Boehm came down from Los Angeles to give one guest lecture—coincidentally he also worked for TRW, in its Defense Systems Group. 

The course ended for me on a high note. The final class exercise was to take one of the methodologies we had learned and apply it to a theoretical project. But I had a real project assignment from work—to develop a system to maintain accounting tables for the billing system—and I decided to apply three of the techniques (i.e., HIPO, Structured Design, and Jackson Design) to develop the system. I scored an A+ on the project, and Dr. Freeman wrote to me, in part: 

An outstanding project! This project shows much thought and care in its preparation. This perhaps is because you intend to implement the system. 

I was most interested in your use of different design techniques depending on what stage of design development you were at. This is quite an innovation. Also, as your critique reveals, this choice gave you the opportunity to evaluate the utility of each of the design techniques used. Impressive. 

Keep up the good work (and ask for a raise). 

After this class, I was so thirsty for knowledge I applied and was accepted in UCI’s Master’s program for computer science. But with a full-time job and one-year-old Susanna at home, it was more than I could handle, and I never enrolled. Still, I continued to take other classes over the years.  

Lesson Learned: Never stop learning. Many of the principles underlying today’s best practices in software development have their roots in principles we learned in those years. For example, object orientation is consistent with Structured Design principles of cohesion and coupling. Although the Agile Manifesto was decades in the future, it had a precursor in Barry Boehm’s promotion of spiral development. And, as I continued my studies, I found myself more and more interested in moving my focus earlier and earlier in the software development process, from coding to system design, to functional design, and to business requirements. This would be a sign of where my career would be heading.
 

Large Scale Project Management

There is another interesting chapter in the history of TRW Credit Data. As noted earlier, its consumer credit database was one of the largest in the world. In fact, it was so large that we actually needed three databases to cover the U.S.—with an East Coast, Midwest, and West Coast database. 

But now, imagine what needed to happen when a consumer moved from one region to another. The system had to move that consumer’s records from one database to another. For this reason, and others, there was a process at the time called “Reorg” that had to run, I believe, weekly. In fact, it took the whole week—when the data center finished one reorg, it started the next one. It was a burdensome tape-oriented process. The 1985 film Prime Risk, mentioned earlier, has one scene as shown in the screen shot nearby, which shows row after row after row of the enormous tape library. 

It soon became evident that the entire consumer credit database would need to be rewritten. The project had just been launched when I started with TRW in 1976, under the unassuming name “Project Rewrite.” Shortly thereafter, management gave it a new name, “Project 78.”  The reader may guess what the 78 stood for. In any event, the project was was suspended  until it was restarted in 1994 as Project Copernicus and completed in 1996 under the project name File One, with a $110M budget and 400+ person project team. As I understand it, the big reason the project was finally completed was that it was a contingency for the leveraged buyout that allowed TRW to spin off the business as Experian.⁴ 

Lesson Learned. Manage the schedule. The number one reason projects exceed their budgets is because they do not meet their schedules. Conversely, spending what it takes to push a project over the finish line can be a better choice than letting a project run unconstrained in its schedule and not delivering on its objectives. It also helps when there is a critical business need with no other option, as was the case here. A decades-long project schedule slip is unusual, of course, but the principle applies to more typical projects. 
 

Time to Branch Out from Accounting Systems

As noted earlier, I only stayed at TRW for about 18 months. I was still young in my career, and I was itching for a place where I could continue to develop new skills. Accounting systems were getting boring to me, and I read in Computerworld that there were opportunities in manufacturing. So, I started another job hunt. But that will need to wait for the next chapter. 

---

Footnotes

¹Cross country job hunting in 1976 was nothing like it is today. There was no internet, no online job boards, email, or video conferencing. When Dorothy and I decided to relocate, my only information regarding job opportunities was the classified ads in the Los Angeles Times, which I managed to pick up at a NYC newsstand. That at least gave me an idea of what kind of jobs were out there and where they were located. But no employer in SoCal was going to consider, sight unseen, a programmer/analyst candidate with less than three years’ experience from across the country. So, the job hunt really couldn’t begin until I physically relocated. 

²The office building (then at 1871 W. Katella, now a strip mall) had originally been some sort of motel, and there was an open courtyard in the middle with palm trees. Muzak was piped throughout the facility. It was quite a pleasant environment, far from the hustle and bustle of Manhattan. The office building and data center were unmarked, and for good reason. Consumers who had been denied credit based on TRW reports had been known to enter TRW offices and threaten employees. I shared an office, which had originally been a motel room, with another co-worker, Ken Romans. He was working on the core credit data system and had (and still has) much deeper technical skills than I did. Within the first year, TRW moved the offices from the converted motel to a new midrise office building in The City in Orange. But the data center continued at 1761 W. Katella until 1992, when TRW moved it to Texas.

³In an interesting twist, a family friend worked at TRW decades later. She told me that, during their work remediating the Y2K problem, she heard developers refer to a program as “so old, it must be one of those written by Frank Scavo.” I wonder if any of those programs are still in production. 

⁴There is another twist to this story. The program director who eventually took File One over the finish line was Don Miller. Don was a close friend and associate of Dan Husiak, who came to work for me in 1998 and in 2000 became my business partner and co-founder of Strativa, our management consulting firm. Don became one of our trusted advisors. As a result, other ex-Experian executives came into my network, including Michael Scharf, Don Lavoie, and Will Sproule.

A Personal Experience of Lateral Thinking

I missed the news earlier this week of the death of Ed de Bono. De Bono was the father of lateral thinking, a framework for creative thinking. Wikipedia has a decent outline of his ideas and influence. 

De Bono was one of the authors that most influenced my consulting career. I adopted many of his tools, most of them quite simple, in analyzing business problems and coming up with creative solutions. The tools are especially useful in facilitating groups. I only regret that I have not applied his methods more consistently in client engagements and even in my personal life. 

One of my favorite tools is the random word stimulation, which is great for brainstorming sessions. Simply put, when you are trying to come up with ideas that are "outside the box," you generate a random word (e.g., pick it out of a dictionary) and use that word as a jumping off point to come up with new ideas. The key, as always with brainstorming, is not to look for ideas that make sense, just generate as many as you can.  When you run out of ideas, do another random word, and another. As with any kind of brainstorming, no judgment of the ideas is allowed.  Save that for a later step. 

In explaining this method, I like to point to one experience from a consulting engagement many years ago. My late business partner, Dan Husiak, was leading a client engagement to develop a new business strategy for a division of what was, at the time, one of the largest health plan providers in the U.S.  We had scheduled a brainstorming session the next day, and Dan assigned me to facilitate the session. The objective was to come up with some new out-of-the-box ideas for new products or lines of business. 

I suggested we use random word stimulation and explained how to do it.  Dan didn't like it. 

Dan: You mean you just pull out some random word, like "Pluto?" 

Me: Okay, good example. Do you mean Pluto the planet, or Pluto the cartoon character? 

Dan:  I don't know, just "Pluto." 

Me: Okay, let's think about this. Pluto the planet. It's small, it's far out. We need far-out ideas. Not much there. Now, Pluto the dog. He's a dog. He's an animal. He's a pet.  Hey, we can offer health insurance for pets! 

That was enough to let Dan give me permission to try it the next day. 

The brainstorming session was a success. In fact, at the beginning of the session, I used the "Pluto" story as an example of how to use random word stimulation. After a couple of hours, the client project team had come up with a number of promising new ideas--enough for us to start evaluating them the next day.  

The best part of this story is that at the end of the session, the top executive for the firm's Medicare HMO product line came up to me and said, "I want to talk to you about that pet insurance idea. You know our seniors love their pets, and pet ownership correlates with positive outcomes. We should look into how to offer a pet HMO."  

Keep in mind, this was before health plans for pets were a widespread practice. 

Thinking tools like random word stimulation are not only effective in creative thinking and problem solving. They are also fun. 

Ed de Bono will be greatly missed. But fortunately he left the world with a long list of books, courses, and other publications for learning how to think.  A good place to review them is his website. 

Enterprise Buyers Not Looking for a One-Stop Shop

There's been an interesting discussion on Twitter over the past few days, which I started with this deliberately ambiguous tweet. 

IMO, very few enterprise buyers are really looking for a "one-stop shop." 

As intended, that brought out replies from several friends and associates, such as Vijay Vijayasankar, Oliver Marks, Holger Mueller, Jody Lemoine, Shane Bryan, John Appleby, and others. 

So, what did I learn from the dialog? 

First, I was thinking back to client meetings I've sat through over the decades, where business leaders positioned "one-stop shop" as a key element of their desired strategy. 

In other words, in the market we serve, customers are typically looking for 10 things.  But today, we only offer seven. If we can offer all 10 things, we can become a one-stop shop! Customers will not have to go anywhere else but will have the convenience of having us satisfy all their needs. 

In enterprise software, this might translate to an ERP system vendor attempting to offer a CRM system or supply chain management suite, or product data management, or a host of other complementary products. Invariable, because these systems take years to develop from scratch, in practice this means acquiring those complementary products. It may also mean offering other elements of a complete solution, such as a development platform, tooling, system integration services, even databases or hardware. 

I don't know if Oracle ever used the term "one-stop shop," but it certainly behaved as if it had. It has been on a multi-decade acquisition spree, not only in business applications, but also in databases (its roots), infrastructure software (BEA), even hardware (Sun). To be fair, it also plowed profits from those products into new development, such as for its Fusion cloud applications. And it is now competing with Amazon for cloud infrastructure services. It is a poster child for the one-stop shop. 

SAP has had its own version of the one-stop shop, acquiring a variety of systems (Holger calls some of them the seven sisters). It also built its own proprietary database, and it also has its own development tooling. 

What About One Throat to Choke? 

One can imagine why such a strategy might be attractive to technology sellers.  But is it attractive to technology buyers? 

I say, no.  In decades of consulting, I don't think I've ever heard a client say, I just wish I could buy everything I need from a single vendor. What I need is a one-stop shop. 

But isn't a one-stop shop the same as "one throat to choke?" I say no. One throat to choke means that in a system implementation, for example, there is a prime contractor or service provider ultimately responsible for delivery. If another partner in the deal is not meeting its commitments, the prime contractor or service provider serving as overall program manager is responsible.  It doesn't mean that there is only one service provider or vendor in the deal. 

What About Integrated Suites? 

Holger asked, "Are you saying that [integrated] suites are done?" Not at all. But I have two responses to this. First, many integrated suites are anything but.  Especially if, as noted above, the vendor built its suite from piece parts that it acquired over time. It takes years to integrate software acquired from various sources. So, buying from a vendor attempting to be a one-stop shop does not ensure you are really getting an integrated suite. 

Second, I have seen very few large deals where there was only a single software provider in the deal. There are almost always complementary products whether they be for sales tax reporting, factory data collection, data analytics, or countless other niche requirements. 

Third, no IT organization's application portfolio only has software from a single vendor, not even a handful of vendors. Even small companies buy software from dozens of vendors. There is no one-stop shop in enterprise software. 

What About Application Rationalization? 

But what about vendor consolidation? Maybe one vendor isn't reasonable, but isn't it a good idea to limit the number of software providers and rationalize the applications portfolio?  Certainly, many companies need to consolidate applications, especially if they grew through mergers and acquisitions and now have two, three, or more ERP systems, for example. 

But that does not mean they need to only buy from one vendor. 

Vendors love to talk about vendor consolidation, as long as the surviving vendor is them. They call this gaining in their "share of wallet," as in the buyer's wallet. 

In my view, when it comes to vendor consolidation you can have too many vendors and you can also have too few. You don't want to have so many vendors that you have redundant types of systems. On the other hand, you don't want to have too few vendors to the point that they gain leverage over you.  

To this point, I've heard of customers engaging in multi-year programs specifically to reduce dependence on certain Tier I vendors, as they become too powerful and attempt to engage in wallet fracking, as my friend Brian Sommer calls it. 

Is there a way to have the benefits of integration and applications rationalization without becoming overly reliant on a single vendor?  I think there is.  Modern cloud systems have become API-oriented. And to be fair, the major vendors, even those aspiring to a greater share of wallet, are building with this model. They have to, if they want market acceptance. Cloud leaders, such as Salesforce, do it by providing a platform that partners can write to, even leveraging Salesforce objects, to provide that integration. Oracle's NetSuite offers a similar capability. Cloud ERP vendors, like Acumatica, Plex, and Sage Intacct are very integration-friendly. Oracle's cloud applications and SAP's offer open APIs, as does Workday. Microsoft has similar capabilities. 

If this is the future, then maybe vendors will give up the strategy of the one-stop shop. 

Deploying Low-Latency Applications in the Cloud

Cloud has become the preferred deployment option for most categories of enterprise systems. But conventional wisdom is that some systems that require low latency and a high degree of system availability, such as warehouse management systems (WMS) or manufacturing execution systems (MES), are best deployed on-premises.

The argument is that response time over the Internet is never as fast as over a local area network and that such systems cannot tolerate any level of unscheduled downtime inherent in using a cloud application. 

Nevertheless, cloud systems are invading even this category of software. Although still in the minority, there are some vendors providing such low-latency applications as a cloud service. 

One example is Plex Systems.  And, interestingly, it is not a new example. 

Read the rest of this post on the Avasant website: Deploying Low-Latency Applications in the Cloud.  

Why Would Oracle Want TikTok?

Oracle is reportedly in talks to acquire the certain operations of social video service TikTok. 

I'm hearing through the back channel that the move is not being well received within Oracle itself this morning. 

From the Verge: 

Oracle has expressed an interest in acquiring TikTok, according to the Financial Times, giving Microsoft a potential competitor in its bid to control the Chinese social video app in the US. Larry Ellison’s enterprise software giant has reportedly held preliminary talks with TikTok’s parent company ByteDance already, working with venture capital firms including General Atlantic and Sequoia Capital, and is “seriously considering” acquiring its business in the US, Canada, Australia, and New Zealand.

So why would Oracle acquire a business that is so far out of its market space? 

I've heard speculations from various quarters. It could be motivated by a desire to leverage TikTok's user data to enhance Oracle's marketing products. It could be motivated by a desire to get into a consumer business. It could be motivated by a desire to hurt Microsoft--something that would fit Ellison's competitive nature. 

There's one more possible motivation I haven't heard mentioned, and that is to get TikTok's huge workload for Oracle Cloud Infrastructure (OCI). Oracle's market share lags far behind Amazon, Microsoft, and even Google's. There is a bit of a chicken-and-egg problem facing Oracle, however. Cloud infrastructure providers need large workloads to realize economies of scale, making them price competitive. But how can Oracle achieve that scale? One way is to buy the workloads. And what bigger workload than a video-sharing service? 

This is likely the reason that it offered a deal to host some of Zoom's workloads on OCI. So, it might also be the primary motivation for Oracle to pitch for TikTok. 

Anyone with me?  

Impact of the Coronavirus Pandemic on IT Budgets in 2020

Over at Computer Economics, we just published our annual IT Spending and Staffing Benchmarks study, now in its 31st year (click to download the free executive summary). 

This year, however, there was a bit of a complication: The COVID-19 pandemic hit right in the middle of our survey period. So, in order to measure the impact of the pandemic, we added special questions to our survey and also went back and re-surveyed those who had already responded. We published the results in a special supplemental report: Impact of the Coronavirus Pandemic on IT Budgets in 2020. The results are interesting, and we plan to repeat the survey in the coming weeks.  

In addition, Dave Wagner and I gave a free webinar to present a summary of the results of both reports. Click the image below to watch the full replay. 

 

IFS and Acumatica Living Together in the ERP Space

Photo Credit: Jon Reed, Diginomica

When does the relationship between two tech vendors look like a merger but is not actually a merger?

For all intents and purposes, that’s exactly what just happened with two players in the enterprise resource planning (ERP) industry. EQT Partners, a global private equity fund, recently finalized a deal to buy Acumatica. Although EQT already owns another ERP firm, Swedish-based Industrial and Financial Systems AB (IFS), it is not merging them. Rather, the two firms will work closely together, while remaining separate entities under the same EQT holding company. EQT’s Jonas Persson will serve as chairman of both companies, and IFS CEO Darren Roos (pictured above, on the right) will assume a seat on Acumatica’s board.

IFS may not have the name recognition of SAP, Oracle, or Microsoft, but at about 10,000 customers worldwide, IFS is much larger than Acumatica. It counts in its arsenal corporate giants such as Toyota, BMW, Pepsi, John Deere, and the largest container ship company in the world, Maersk.

It’s not that a merger was not on the table. EQT’s acquisition came after IFS considered buying Acumatica outright, Roos said recently at an analyst event. After carefully considering the situation, EQT decided that IFS and Acumatica are different enough that a different strategy was needed, to keep the two firms separate.

For its part, Seattle-based Acumatica has grown to more than 5,200 mostly small and midsize customers in 11 years. It is known for packaging its products into industry “editions.” Each edition marries Acumatica’s horizontal functionality (primarily financials, distribution, and customer management) with industry-specific modules, such as commerce, construction, manufacturing, field service, and distribution. Acumatica sells these editions through a network of value-added resellers (VARs).

Read the rest of this post on the Strativa blog:
IFS and Acumatica Living Together in the ERP Space

The Use and Misuse of PaaS

One of the key advantages of modern cloud systems is that they often come with rapid development platforms that allow the vendor, partners, and even customers to build extensions and customizations to the system without affecting the underlying code or architecture of the base system. These are generally known as Platform as a Service (PaaS).

Examples include the Salesforce Lightning (formerly Force.com) platform, the SuiteCloud platform of Oracle’s NetSuite, Acumatica’s xRP platform, Sage Intacct’s Platform Services, Microsoft’s Power Platform, and many others.

However, as with so many good things in life, PaaS can be used and abused.

Read the rest of this post on the Strativa blog:
The Use and Misuse of Platform as a Service 

The Benefits of Business Process Framing

In selecting and implementing a new enterprise system, business leaders have learned the importance of evaluating business processes. “Let’s not make this an IT project,” they say. “Let’s really understand our current business and our vision for the future.” Without a doubt, this is right, and we encourage our clients to do exactly that.

However, business leaders often think that this means they should begin with detailed process mapping of their existing processes. “Let’s have someone come in and map all our business processes,” they say.

At first glance, this seems logical. If we want to define our business requirements, what better way than to map our “as-is” processes?

Why is this not a good idea? There are at least three reasons.

Read the rest of this post on the Strativa blog: The Benefits of Business Process Framing

Time for a Declaration of Independence from Software Vendors?

When it comes to enterprise IT, every so often we begin to notice things that cause us to question our basic assumptions. The latest is about the role of commercial software.

The traditional advice for companies is that it is best to standardize on a commercial software vendor for the core of the applications portfolio. It might be a major vendor, such as SAP, Oracle, or Microsoft, or it might be any number of other providers. Custom software should be the exception, not the rule, whether for unique industry requirements, or for modifications and extensions to the core system. The more you can rely on a commercial software vendor, the better.

We’ve been giving this guidance for decades, whether for on-premises systems or with cloud-based systems.


Nevertheless, some of our clients are starting to rebel against the conventional wisdom by developing more of their own software in-house. Moreover, they are not doing it just on an occasional or exception basis or for niche applications. They are doing it for domains where we traditionally assumed that commercial software was the natural choice.

Read the rest of this post on the Strativa blog: Time for a Declaration of Independence from Software Vendors?