TM1 FANBOY

Tag: TM1

  • Origins and the Initial TM1 Release

    Origins and the Initial TM1 Release

    TM1 does not have a single convincing birthday.

    That is not a failure of research. It is part of the history.

    Origins and the Initial TM1 Release break apart because different sources are describing different kinds of beginnings. Some point back to Manny Perez’s work at Exxon and the analytical problem that pushed him toward a new kind of system. Others begin with a prototype. Others start with the formation of Sinper. Others anchor the story in public announcement or visible commercial release. Once those milestones are separated, the disagreement becomes easier to understand.

    The more useful historical claim is therefore simple: TM1 did not appear all at once. It emerged through stages, and each stage answered a different question about what it meant for the product to exist.

    The Earliest Beginning Was a Business Problem

    The deepest layer of the story sits before Sinper and before the PC market. Later recollections consistently place the conceptual beginning inside Manny Perez’s work at Exxon, where supply, demand, and pricing calculations were expensive, difficult, and only awkwardly supported by the available tools.

    That point matters because it keeps the origin story grounded in organizational need rather than product mythology. TM1 did not begin as a technology looking for a market. It began as an attempt to solve a hard analytical problem inside a real business setting. The later architecture makes more sense once that problem is kept in view.

    The key move in these retrospective accounts is not simply “better spreadsheet.” It is the separation of stored data from the spreadsheet-like manipulation of that data. In other words, the system was trying to preserve the flexibility users wanted at the surface while changing what happened underneath. That is why TM1 later looked strange to people who expected a normal spreadsheet and also strange to people who expected a normal database. It came from a problem that sat between those worlds.

    Prototype, Company, Product

    A second beginning appears in accounts that place an early implementation around 1981 on a mainframe timesharing system. That milestone is historically useful even if the documentation around it is thinner than the later trade-press record. It marks the point where the story moves from problem definition toward technical embodiment.

    From there the chronology becomes easier to reconstruct. Cubewise’s community history places the formation of Sinper in early 1983 and describes TM/1 as being announced at PC Expo in New York that summer. By then, the project had crossed another threshold. It was no longer only an internal solution or a prototype idea. It had become a company, a product identity, and a public proposition.

    That does not yet settle the release question. An announcement is not the same thing as broad commercial visibility. But it does show that by 1983 TM1 had already entered the world of software companies, trade events, and product claims.

    1984 Is the Strong Public Anchor

    If the question is when TM1 becomes securely visible in contemporary evidence, 1984 is the strongest answer.

    Byte’s October 1984 notice, “Multidimensional Tables Manager Aids Decisions,” matters because it shows Tables Manager/1 already present enough in the market to be described for a public computing audience. That article does more than prove the product existed. It also shows how the market first struggled to classify it. TM1 appeared as a decision-oriented system with spreadsheet and database characteristics before later terminology made the category easier to name.

    InfoWorld reinforced that public visibility in January 1985 when it placed TM/1 among a small set of analytical tools aimed at managers rather than programmers. By that point, the product was not just internally real or conference-announced. It was part of the visible business-software conversation.

    That is why 1984 works as the best public anchor for the initial release story. It is not necessarily the first moment the system existed in any sense. It is the point at which the product becomes clearly legible in contemporary market evidence.

    The Date Problem Is Really a Definition Problem

    Once the sources are laid side by side, the date problem becomes less mysterious.

    Each source is selecting a different threshold:

    • the idea
    • the prototype
    • the company
    • the public announcement
    • the visible product in the market

    Those thresholds are not interchangeable. A technology can be conceived before it is embodied, embodied before it is incorporated, incorporated before it is announced, and announced before it is widely visible. TM1’s beginnings look unstable because later retellings often compress those stages into one symbolic founding date.

    The stronger reconstruction is a sequence:

    • around 1980, the analytical problem takes shape in the Exxon context
    • around 1981, retrospective accounts place an early prototype
    • in early 1983, Sinper is formed
    • in summer 1983, TM/1 is publicly announced at PC Expo
    • by October 1984, Tables Manager/1 is visible in the trade press
    • by January 1985, TM/1 is being framed as part of an emerging analytical-software market

    That sequence does not pretend to eliminate uncertainty. It organizes it.

    Why This Matters Beyond the Date

    This is not just a pedantic debate about anniversaries.

    The way TM1 entered the world helps explain what kind of product it was. Its origin was not a neat launch of a fully stabilized software category. It was a gradual movement from business problem to technical model to product identity to market visibility. That is one reason the early descriptions of TM1 feel unstable. The software was still crossing boundaries between spreadsheet logic, database structure, and analytical modeling before the market had a settled vocabulary for that combination.

    The historical value of the release question is therefore interpretive, not merely chronological. It reminds us that enterprise systems are often born through overlapping stages of experimentation, naming, incorporation, and public recognition. TM1 was not an exception to that pattern. It is one of the clearest examples of it.

    The Best Answer

    So when did TM1 begin?

    The best answer is not one date.

    If the question is about conception, the story reaches back to the Exxon problem context around 1980. If the question is about an early working system, the answer points toward the prototype accounts around 1981. If the question is about the company and public product identity, 1983 matters. If the question is about a securely documented market presence, 1984 is the strongest anchor.

    That answer is messier than a single founding anniversary, but it is historically stronger. TM1 did not begin in one moment. It became real in stages, and the stages tell us more than any single date can.

  • Before OLAP Had a Name: TM/1 and the Problem of Vocabulary

    Before OLAP Had a Name: TM/1 and the Problem of Vocabulary

    The easiest way to misunderstand early TM/1 is to describe it with vocabulary that did not yet exist.

    Today it is natural to place TM/1 inside a familiar category. We can call it an early OLAP engine, a multidimensional database, a planning system, or the ancestor of later enterprise performance management software. None of those descriptions is empty. Each captures something real. But each arrives too late.

    The more interesting historical question is not what TM/1 later became. It is how the product was described when the market still lacked settled words for this kind of software. The 1980s evidence is valuable because it records that uncertainty in real time. TM/1 moved through a vocabulary that was still unstable, and the instability itself is part of the story.

    A Product Without a Settled Category

    OLAP did not organize the market in the early 1980s. The later phrase Online Analytical Processing gave the industry a useful label for multidimensional, interactive analysis, but it also encouraged a retrospective simplification. Once a category becomes established, older products are pulled into it as if they had always belonged there.

    TM/1 resists that treatment.

    In the surviving trade-press and marketing record, TM/1 appears under several overlapping descriptions. Byte‘s October 1984 notice “Multidimensional Tables Manager Aids Decisions” presents Tables Manager/1, or TM/1, through decision-management, multidimensional, tabular-database, and spreadsheet language at the same time. InfoWorld‘s January 28, 1985 “New Analytical Tools Break The Mold” places TM/1 among analytical tools aimed at managers. Jeffrey Rothfeder’s July 1986 PC Magazine article “Breaking the Mold” describes TM/1 in the Exxon International case as a multidimensional, multiuser spreadsheet and table manager. William J. Lynott’s August 1987 Online Today review calls TM/1 Version 2.0 table-management and spreadsheet software. PC Magazine‘s October 27, 1987 “Analyzing Data From All the Angles” treats TM/1 as part of the 3-D or multidimensional spreadsheet world. Then Sinper’s June 1988 Byte advertisement asks, “What Is A Relational Spreadsheet, And Who Should Own One,” and answers by trying to make TM/1 the category itself.

    That variety is not a nuisance. It is evidence.

    The market was trying to describe a product that sat between familiar things. TM/1 looked enough like a spreadsheet to be understood by spreadsheet users. It behaved enough like a database to separate stored data from worksheet manipulation. It supported multidimensional analysis before multidimensional analysis had become a stable business-software category. The language wobbled because the product crossed boundaries the market had not yet learned to name cleanly.

    Why “Early OLAP” Is Not Enough

    Calling TM/1 “early OLAP” can be useful shorthand. It should not be the whole story.

    The phrase explains the product from the future backward. It tells the reader where TM/1 eventually fits in the history of analytical software. It does not tell the reader how the product was understood in its own moment.

    That distinction matters because the real historical problem sits earlier. The question is not only whether TM/1 anticipated OLAP. The better question is why business software in the early 1980s needed a tool that existing categories could not describe cleanly in the first place.

    Spreadsheets gave users direct manipulation. Databases gave organizations more structure for storing information. Decision support systems promised analytical assistance. TM/1 lived in the space where those traditions overlapped. The vocabulary problem was therefore also an organizational problem. Managers wanted to analyze changing business assumptions without giving up the flexibility they had learned from spreadsheets.

    The Vocabulary Shift Was the Product Story

    The sequence of labels matters because it tracks how the market slowly changed its interpretation of the software.

    The earliest descriptions lean on tables, decision-management, and spreadsheet language because that was the available vocabulary in 1984. By 1986 and 1987, TM/1 is increasingly pulled into the multidimensional spreadsheet conversation. By 1988, Sinper is openly trying to win a category battle with the phrase relational spreadsheet. The language then shifts again in the early 1990s toward spreadsheet connector, client/server spreadsheet engine, and database engine for spreadsheets. Each step is an attempt to solve the same problem: how do you explain software that is still close to spreadsheets at the surface but increasingly farther from them underneath?

    That is why the terminology history is more than a list of names. It captures the market learning, failing, adjusting, and trying again. A later label such as OLAP can make the path look neat. The contemporary language shows that it was anything but neat.

    Trade Press Was Not Neutral, but It Was Revealing

    Trade press is especially useful here because it records the category confusion in real time.

    Reviews and notices were not neutral technical documents. They were written under deadline, often close to vendor language, and sometimes with incomplete technical access. But that is precisely why they matter. They show what could be said publicly about TM/1 at a given moment, what analogies seemed necessary, and which parts of the product the market thought were easiest to grasp.

    When Rothfeder’s 1986 PC Magazine article calls TM/1 a multidimensional, multiuser spreadsheet and table manager, that does not prove the product was only a spreadsheet. When Sinper’s 1988 Byte advertisement calls it “The Relational Spreadsheet,” that does not settle its architecture either. But both expressions show how TM/1 was being positioned and understood before OLAP became the cleaner retrospective label.

    The historian’s task is not to force those descriptions into premature agreement. It is to preserve what they reveal about a market still searching for the right category.

    A Better Historical Frame

    The most useful frame may be this: TM/1 belonged to the pre-OLAP vocabulary of enterprise analysis.

    It belonged to a world of table managers, three-dimensional spreadsheets, decision support tools, spreadsheet connectors, analytical databases, and spreadsheet-database hybrids. Those labels are not interchangeable, and they should not be collapsed into one another. But together they show the market circling around a problem that would later become central to enterprise planning and analytics.

    How could business users analyze numbers across products, periods, regions, scenarios, and assumptions without rebuilding the model every time?

    That question is bigger than any single label. It is also why TM/1 remains historically interesting. The software did not simply arrive before OLAP had a name. It helps explain why such a name eventually became necessary.

  • Hyperion OLAP: When Consolidation Closed a TM1 Route into Finance

    Hyperion OLAP: When Consolidation Closed a TM1 Route into Finance

    In the mid-1990s, TM1 did something important. It moved out of the world of admired specialist software and into a larger finance-software channel.

    That move ran through Hyperion OLAP. TM1 did not simply appear inside another vendor’s product catalog. It entered a company with reach, customer access, and credibility in enterprise finance. For a moment, that looked like the beginning of a bigger commercial future. Then the story turned. After the Arbor-Hyperion merger, the route appears to have been closed in favor of Essbase.

    That is what makes the Hyperion episode historically useful. It shows how a product can become more visible, more legible, and more commercially plausible, then still lose its path when the market consolidates around a different portfolio.

    There is also a suggestive prehistory behind the public record. Various retrospective accounts imply that TM1 may have been known inside parts of the broader Hyperion orbit before the later Hyperion OLAP announcement. That possibility is historically useful because it suggests the relationship may have deeper roots than the public launch material shows. But the chronology remains too soft to treat as a dated public milestone. For the firmer sequence, the record begins in 1995.

    1995: Hyperion Turns TM1 into a Product-Line Component

    The first hard anchor is the formal 1995 launch material. A Hyperion release dated November 13, 1995 and later reposted to Google Groups said Hyperion planned to enter the OLAP market in Q2 1996 with Hyperion OLAP, using an underlying engine licensed from Sinper. The same release also described the transaction as a $1.5 million purchase of research and development. Ilan Greenberg’s December 11, 1995 InfoWorld report then used acquisition language for the same move.

    That mixed wording matters because it explains why later summaries drift between license, acquisition, and OEM-style shorthand. The exact legal structure still deserves cleaner documentary confirmation. But the business meaning is clear enough. Hyperion was not treating Sinper’s technology as a minor add-on. It was building it into a finance-oriented product line.

    That changes the historical reading of TM1’s mid-1990s position. Once Hyperion adopted the engine, TM1 was no longer visible only through Sinper’s own scale or through small specialist channels. It was being packaged by a vendor that already mattered to finance buyers.

    That kind of arrangement does more than add revenue. It changes the story buyers tell themselves about the product. A technology that once looked niche begins to look established once it appears inside a familiar commercial frame. Hyperion’s own launch language also tied the engine to recognizable TM/1 customer references. That helped place the product inside an existing enterprise planning conversation rather than leaving it as a component story.

    1997: The TM1 Engine Is Still There

    The second anchor matters because it shows continuity rather than a short-lived announcement.

    On May 26, 1997, Computerworld was still describing Hyperion OLAP 2.8 as using the latest Applix TM1 engine. The same notice framed the offer as combining Hyperion financial intelligence with that engine. That detail matters because it confirms that the relationship survived the initial 1995 deal and remained visible after Applix had acquired Sinper. The engine was still publicly identified with the Hyperion product line.

    That is enough to make a firm historical point without leaning on speculative revenue numbers. The contemporary record already shows two things that matter: Hyperion adopted the engine in 1995, and trade press was still identifying Hyperion OLAP with the TM1 engine in 1997. This was not a brief experiment. It was a real route to market.

    Why That Changed the Applix Story

    This does not prove that Hyperion alone caused Applix to buy Sinper in 1996. The evidence should not be stretched that far.

    It does support a narrower and more defensible point. By the mid-1990s, Sinper’s technology no longer looked like an isolated technical achievement waiting to be discovered. Hyperion had demonstrated that the engine could travel through a larger enterprise-finance channel and sit inside a recognizable product line. That changed how the technology could be seen, valued, and understood.

    That is the more useful historical reading of the period around the Applix acquisition. The acquisition was not just a transfer of ownership around an interesting niche engine. It happened after the engine had already proven that it could operate inside a larger software company’s commercial structure.

    1998: The Break Looks Strategic, Not Technical

    The turning point is the merger itself.

    The Los Angeles Times reported on May 27, 1998 that Arbor and Hyperion had agreed to merge in a $798 million deal. That article is not a product-history document, but it gives us the decisive market event: the Hyperion route now sat inside a merged company that also owned Essbase.

    Later retrospective accounts from people around the Hyperion side describe that merger as the moment when Essbase became the strategic winner and Hyperion OLAP lost its future inside the combined company. Those recollections should be treated as retrospective interpretation, not as a substitute for contemporary product-strategy documents. Even so, they fit the public sequence unusually well. Once the merged company had both Essbase and Hyperion OLAP, the portfolio logic becomes hard to miss.

    The available record does not show a clear technical collapse of the TM1 route inside Hyperion. It shows ownership change, product overlap, and the likely strategic preference for a different engine. In other words, the path seems to have closed because consolidation changed the portfolio, not because the route had failed in the market.

    The Migration Paper Shows What Survived the Break

    The clearest public afterimage appears in Applix’s circa-2000 paper “Hyperion OLAP Users Upgrading to iTM1 Server 7.”

    That paper matters because it looks backward and forward at the same time. It states that Hyperion OLAP and Hyperion MBA had used iTM1 version 6.0 as their OLAP engine, and it argues that those customers should move to iTM1 Server 7 rather than Essbase. The paper is obviously promotional, so it should be read as a migration pitch rather than a neutral history. But that is also what makes it useful. Applix believed there was still a recognizable installed base worth pursuing after the Hyperion route had lost its future inside the merged portfolio.

    By that stage, the meaning of the channel had changed. What had once been a growth route for TM1 inside Hyperion had become a recovery path for customers displaced by consolidation.

    Why This Episode Matters

    The Hyperion episode is useful because it reveals a broader pattern in finance and enterprise planning software.

    Smaller specialist technologies often become strategically important when a larger company turns them into a route to market. That wider visibility can alter how the technology is perceived, valued, and positioned. But the same arrangement also makes the product vulnerable to a later round of consolidation. Once portfolio logic takes over, a viable route can disappear for reasons that have less to do with product quality than with ownership structure.

    That is the stronger way to read Hyperion OLAP in TM1 history. Hyperion did not merely license the engine. It gave TM1 a visible route into finance. The later merger seems to have shut that route in favor of Essbase.

    The lasting point is larger than one product line. Enterprise software is shaped not only by what works, but by who carries it into the market, how it fits a broader portfolio, and what happens when consolidation redraws the map.

  • Why TM1 Matters

    Why TM1 Matters

    TM1 matters because it survived when most business software did not, and that survival turns it into more than a product history.

    It makes TM1 a way of studying how organizations have tried to improve decision-making across four decades of technological change. A system born in the early personal-computing era is still present in enterprise planning, still visible after the age of client-server, still legible after business-intelligence consolidation, and still alive in the current language around AI. That kind of continuity is historically unusual. It deserves explanation.

    Most Software Disappears

    The normal fate of software is not endurance. It is replacement, irrelevance, and then disappearance.

    That is what makes TM1 historically interesting before any technical explanation begins. Byte’s October 1984 notice presented Tables Manager/1 as a decision-oriented business tool. InfoWorld’s January 28, 1985 article “New Analytical Tools Break The Mold” placed TM/1 beside Reflex and Helix in a market for manager-oriented analytical software. Jeffrey Rothfeder’s July 1986 PC Magazine article “Breaking the Mold” showed Exxon International using TM/1 in a networked planning environment. William J. Lynott’s August 1987 Online Today review still treated TM/1 as a distinctive and unusual product.

    Those sources belong to a business-software world that has mostly vanished. TM1 did not vanish with it.

    That fact alone raises a better question than the usual product-history questions. Before asking what TM1 is, or how it works, the more revealing question is why it remained useful while so many neighboring systems disappeared.

    TM1 Was Born Early and Stayed Legible

    TM1 matters partly because of when it appeared.

    It did not arrive late in the history of planning software. It emerged in the early 1980s, close to the beginning of the personal-computing shift that put analytical tools onto the desks of business users. That timing matters because it means TM1 was exposed to nearly every major transition that followed.

    The early sources already show that TM1 was not trapped inside a single-machine spreadsheet story. Rothfeder’s 1986 Exxon case showed TM/1 inside a LAN-supported planning environment. By October 1990, Sinper’s InfoWorld advertising for Spreadsheet Connector was explicitly addressing the problem of networked spreadsheet users working against shared data. Vance McCarthy’s September 7, 1992 InfoWorld report on TM/1 Spreadsheet Connector Release 2.0 then described Lotus 1-2-3 and Microsoft Excel users connecting to a central database.

    That sequence matters because it shows continuity across changing computing environments. TM1 was born in the PC era, but it did not remain conceptually trapped there.

    Survival Is the Real Historical Problem

    This is the central claim of the publication: TM1 matters not because it was fashionable, but because it kept crossing historical boundaries that killed other products.

    It lived through the spreadsheet era, the move to networked business computing, the rise of enterprise planning, the consolidation of business intelligence, the reorganization of software into broader suites, and the later shift into cloud-era packaging. It now sits inside a market newly dominated by AI language about planning, forecasting, and decision support.

    Most software products do not survive even one major transformation cleanly. TM1 survived a chain of them.

    That makes its history useful well beyond the product itself. If a system remains embedded in planning and finance through multiple technological eras, then tracing that system also reveals changes in organizational practice. It shows how companies moved from local spreadsheets to shared models, from periodic budgeting to more continuous planning, and from isolated analysis toward larger decision systems.

    TM1 Is a Lens on Enterprise Decision-Making

    That is why TM1 belongs inside a broader history of enterprise decision-making rather than a narrow product chronicle.

    TM1 sits at an unusually revealing intersection: spreadsheets, models, organizational assumptions, finance routines, and computational speed. A long-lived planning system preserves the record of what organizations repeatedly wanted from technology. They wanted faster recalculation, more structured assumptions, shared versions of the business, and greater confidence in the numbers used for decisions.

    Those desires did not disappear when the platform names changed. They reappeared in new forms.

    Seen that way, TM1 is not just a durable software artifact. It is a witness to a recurring organizational ambition: the belief that better systems can produce better decisions. That ambition connects decision support, enterprise planning, business intelligence, data culture, and AI much more tightly than the usual product categories suggest.

    Why This Publication Starts Here

    This is why TM1 Fanboy does not begin with a tutorial, a feature tour, or a vendor chronology.

    The more interesting starting point is the survival problem itself. Why did this historically specific system remain useful while so many neighbors disappeared? What did it solve early that later generations of software still had to solve again? And what does that continuity reveal about the persistent limits of spreadsheets, the recurring demands of finance, and the longer history of enterprise planning?

    Those are the questions that make TM1 worth studying.

    They are also the questions that let TM1 point beyond itself. The history of one planning system becomes a way to study how organizations have repeatedly tried to use technology to make judgment more structured, faster, and more reliable.

    That is why TM1 matters. Not because it is beloved, and not because it is old, but because its survival makes a larger history visible.