The Compton Scatter

Jim Compton’s blog on things language, technology, business and culture.

Tag: Computer Science

  • Is it time to kiss the digital file goodbye?

    Is it time to kiss the digital file goodbye?

    The following “Compton Classic” article was published May 2017 on the now defunct Moravia Blog and is being re-published here for posterity. Minor edits may have been made to support relevance and clarity.

    Digital files have served us well, having helped bring us the digital age. But now that we’re older and wiser, do we still need them? And should they be allowed in our content programs? In this post I propose that the digital file—with its inherent limitations—may now be more burden than boon.

    It all starts with metaphors

    Metaphor is a constant force in the history of innovation, and is a powerful thing. Not only can it trigger innovation (Where else can this technology be applied?), but it profoundly influences the design process (Where has this problem been solved already?).

    Metaphors serve as gateway concepts that enable us to leave the old world for the new without suffering too much cognitive dissonance. When something is too foreign for our brains to comprehend, metaphors anchor the unknown to that which is already known, allowing us to focus on classifying the novelty in a way that is generally consistent with our world view.

    “Is this something that I can eat, or is it something that will try to eat me?”

    It’s the concept behind the design technique skeuomorphism, which attempts to make software look and feel like its real-world counterparts so that it feels more natural. You may have used e-readers with “page curl” effects or digital watches that have hands. Or, if you’ve made electronic music, used virtual instruments with chrome-plated rotary knobs and wood grain.

    These are all applied metaphors. They have a purpose, a time, and a place. But as the unfamiliar becomes mundane and their comforting quality becomes unnecessary, they also have a shelf life.

    The rise of physical office metaphors

    Electronic computing is by all measures a revolutionary concept, so it isn’t surprising that as computers were sold and marketed to a wider audience, that this process leveraged lots of metaphors, especially physical office metaphors, including the desktop, mail, folders, trash cans/recycle bins, and of course the ubiquitous document, otherwise known as the file.

    In the physical world, files are quite useful. They represent a clearly-scoped, unambiguous container for content and information. They can be opened any number of times, duplicated, stored, marked-up, moved-around, organized, shared with others, and if necessary, destroyed.

    These are all things that we’d like to do with content in the electronic world too. And since digital files can be processed far faster and at greater volumes than what is possible in the physical world, what’s not to love, right?

    The dark side of metaphors

    In Edsger Dijkstra’s paper, “On the Cruelty of Really Teaching Computing Science,” he discusses the problem of applying metaphors from the physical world to concepts in computer science:

    “…though we may glorify it with the name ‘common sense’, our past experience is no longer relevant, the analogies become too shallow, and the metaphors become more misleading than illuminating.”

    He argues that analogies not only project characteristics upon the “radical novelty” that aren’t true, but they can deny the thing its true potential.

    Looking at the world through Dijkstra’s lens, it is easy to find examples of metaphors that have broken down, imposed unnecessary limitations in the space they’re supposed to empower, or have turned the tables by requiring the user be in service to it.

    Look no further than your smartphone—which opted-out of many of the office metaphors previously taken for granted. Would your phone be more useful if it had a virtual desktop and trash can? Would it save you time if you could put virtual pieces of paper into virtual stacks and organize them into virtual folders?

    Files’ strengths become their weaknesses

    Digital files, as an applied metaphor used to manage information, impose unnecessary limits on information management. In the context of new information technologies, those characteristics which were strengths in the physical world become weaknesses in the digital world.

    The “clearly scoped unambiguous container” problem

    The information that lives in a file is static in a world where the demand for information is dynamic.

    If I have a report, for example, and I want additional information that isn’t in the report, a new report needs to be generated. And since the file is a snapshot of the data, by the time it makes it to my eyes it’s already old news.

    By comparison, systems that forgo the file container and use more database-like techniques can serve us by creating on-demand renderings of the real-time data based on whatever criteria we’re interested in.

    The portability problem

    In a world where systems can talk to each other directly, the flexible portability of files invites trouble. If data must go on a road-trip—riding in a file—it risks being subject to corruption, obsolescence, hijacking, and getting lost along the way.

    If it’s a human who is playing host to the file, he must make a home for it so that he can find it later (which is also known as the “thing that needs to be physically put away into a folder” problem).

    In the context of sophisticated search algorithms which can find and retrieve information regardless of where it lives, this requirement to organize files—inherited from the metaphor of the physical files—has become an example of “the tail wagging the dog.”

    Process waste

    In certain business-to-business traditions, localization included, files have been used as an interchange format as way to exchange information between otherwise independent systems or independent steps within a process.

    But from the standpoint of overall process efficiency, using files in this way represents several classes of muda (waste, inefficiency), including entire steps dedicated to:

    • changing the file format
    • running quality control to make sure something didn’t break when the file format was changed
    • hand-offs and hand-backs, version control, file-splitting, etc.

    The non-value-add costs add up quickly.

    Alternatives to the file

    In the world of building globalization solutions, the practice of processing content through files has been universal. And measurably costly. But things are changing.

    When designing solutions today, if there is a file in the mix, we’re asking, “Is this necessary? How much will it cost to create and manage this file?”

    Instead of bringing the content to the process (in the form of files), we’re looking at ways to bring the process to the content using web services, browser extensions, and other techniques that don’t force the content to go on long, expensive, and unnecessary road trips.

    And this seems to be a trend.

    The XLIFF-OMOS project is an attempt to make the XLIFF format (which aims to standardize the way localizable data is handled by localization systems) useful in a world without files.

    “A top priority [of the project is to] unleash XLIFF 2, make it usable outside XML pipelines, and ready it for real time cloud services”

    XLIFF-OMOS, you’ve got my attention!

    Your Opinion?

    What do you think? Are files a boon or a burden for your program? Something else entirely?

    Let’s start a conversation!

    ###

  • The Composability Revolution

    The Composability Revolution

    The following “Compton Classic” article was published in 2018 on the now defunct Moravia Blog and is being re-published here for posterity. Minor edits may have been made to support relevance and clarity.

    The term “composability” has largely remained exclusive to the IT domain, but it’s a concept that has broad relevance, including to the GILT (globalization, internationalization, localization, and translation) industries. 

    Compos-a-what-a-bee?

    If you don’t have at least one foot in IT, you may never have heard the term “composability” before, which Wikipedia describes as a system design principle. I’ve mostly seen it used in the context of designing IT infrastructures.

    Its key principles are modularity and reusability, but the heart of the concept can be found in the word itself. To compose something is to give it form through the assembly of components, and the extent to which something supports the creation of new things through these components is its level of composability.

    When you start to look at the world through this lens of creation through the assembly of components, you see examples of composable systems all over the place.

    The go-to analogy out there is LEGO, and it’s easy to understand why. Anyone who has ever played with Legos has a good sense of the concept already. Through a set of different-but-interoperable pieces, you can create any permutation of object—or scenario—you can imagine. 

    Two side-by-side pictures comparing toys. The left picture is a pile of toy vehicles and plastic animals and is captioned "somewhat composable." The right picture is a pile of LEGO bricks and is captioned, "highly composable."

    It’s an idea explored in the movie “Big Hero 6” through the plot device of the Microbots, a set of “neurotransmitter controlled,” magnetically connectable pieces that can create dynamic, architecturally complex structures (which ultimately get stolen by the villain and used as his superpower).

    Composability is also central to the IKEA business model that sells modular pieces of furniture that can be bought and arranged together to form comprehensive groupings.

    And it’s an underlying principle (although not by name) in Adam Smith’s The Wealth of Nations, which asserts that economic growth is driven by increased division of labor in both manufacturing systems and economic systems. At the manufacturing level, the components are the tasks required to produce something. Within economic systems, the components are the individual specialized industries that can be traded and combined to create new value. Our modern economy is a living example of this principle in action.

    The (r)evolution

    Not all systems are equally composable, however. In the world of IT, the opposite of a composable system is described as a monolith.

    If monolithic systems can even be described as having components, their components are bound together. Nothing takes place outside the monolith; everything is built-in. They’re big, standalone, all-in-one, indivisible entities. There are arguments in defense of monoliths, but the case against them is that they’re inherently inflexible, slow to evolve, and difficult to scale. They’re tailor-made to a problem until the landscape changes completely—at which point their all-in-one-ness becomes an impediment. The worst examples are disparaged as “balls of mud.”

    The reaction against monoliths has influenced several notable technology movements:

    The Service-Oriented Architecture (SOA) movement – SOA sees the natural component within a modular system as being the service: a discrete, specific piece of specialized functionality that can serve a variety of systems and contexts, including other services. There are parallels with the Unix philosophy, which advocates small, modular, interoperable applications.

    The SOA movement has been highly influential over the way companies are designing or re-designing their technology stacks, and to the adoption of enterprise service buses. Related, but not identical, is the microservices architecture movement, which has additional notions about how modularity should be implemented. 

    The “Programmable Web” movement – I see this as the SOA movement applied inter-organizationally. The programmable web philosophy sees all the APIs available across the internet—from separate hosts—as part of a holistic programmable system from which new capabilities can be composed.

    It’s a movement that’s spawned the practice of “mashups”: the creation of useful applications through the combination of APIs (for example, combining Craigslist apartment listings with Google Maps to create a visual map of available apartments).

    The painting The Wealth of the Nation, by Seymour Fogel. Five men are engaging in different forms of different labor. One man looks through a microscope. Another is inspecting a blueprint. A shirtless man is pulling a lever connected to gears and two others are walking toward a factory carrying a hammer and toolbox, respectively.
    “The Wealth of the Nation” by Seymour Fogel is in the public domain. What new value can be created by leveraging the wide world of API-accessible capabilities? 

    Moravia’s response

    At Moravia, we’re excited about these movements, since they’re compatible with our worldview: we define a “solution” as a composition of strategy, process, technology, and human involvement, and we employ solutions to meet our customers’ needs, solve their business challenges, and provide value.

    The efficacy of our solutions has always been relative to their composability—the extent to which components need to be developed from scratch, capabilities can be reused as-is, and pieces can be replaced or updated by better ones. As our customers’ workflows evolve (sometimes radically), the ability of our solutions to quickly conform to the shape of the problem (not unlike a cloud of Microbots) is incredibly valuable.

    And we’ve embraced the pro-composability revolution in several ways:

    • We’ve been migrating to a service-oriented architecture within our own tech stack. We recently developed and deployed the Moravia Service Layer through which all our internal tools can communicate, and have been generally migrating from a products-orientation to a services-orientation. Through the Service Layer, we remove the functions that are common across tools and make them available as shared services.
    • For a while now we’ve been “API-ifying” our tool stack, making sure that our tools’ core capabilities can be flexibly invoked from anywhere.
    • We’re leveraging the programmable web and API economy ourselves, utilizing third-party APIs where they can add relevant capabilities to a solution.

    We’re doing these things because we see advantages for us and for our customers, both big and small. Any time we can reuse a capability that’s already available as a component—as opposed to having to create it from scratch—we save time and money. 

    More broadly, having a rich, highly-composable capability stack with components that we’ve either created ourselves or have leveraged from others is a liberating force for creative problem-solving. The more specialized components we have in our stack, the more we can assemble them to create new solutions to increasingly complex globalization problems.

    The more we can focus on solving our customers’ big-picture globalization challenges, the more relevant and valuable we are to them. Everybody wins.

    What are your thoughts on composability and its relevance to solving globalization problems? Are you making changes in the context of the composability revolution too? Let’s start a dialog!

    ###