Tag Archives: Highly-evolvable enterprise software

Applying industrial engineering to information technology

This post is part of my collaborative research with Shinsei Bank on highly-evolvable enterprise software. It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. I am indebted to Shinsei Bank for supporting this research and to Jay Dvivedi for mentoring me in the art of enterprise systems. All errors are my own.

The fourth edition of Herbert Simon’s Administrative Behavior contains a brief section titled “Applying information technology to organization design”. In the industrial age, Simon says, organization theory was concerned mainly with how to organize for the efficient production of tangible goods. Now, in our post-industrial society, problems of physical production have diminished in importance; the new challenge is how to organize for effective decision-making. Simon characterizes the challenge as follows:

The major problems of organization today are not problems of departmentalization and coordination of operating units. Instead, they are problems of organizing information storage and information processing–not division of labor, but factorization of decision-making. These organizational problems are best attacked, at least to a first approximation, by examining the information system and the system of decisions it supports in abstraction from agency and department structure. (1997, 248-9)

In essence, Simon proposes that we view the organization as a system for storing and processing information–a sort of computer. Extending the computer metaphor, organizations execute software in the form of routines (March and Simon call them performance programs). Department structure, like the configuration of hardware components in a computer, has some relevance to the implementation of decision-making software, but software architects can generally develop algorithms without much concern for the underlying hardware.

Continue reading →

The Fable of the Robot, or Why Enterprise Systems are like Baobabs

This post is part of my collaborative research with Shinsei Bank on highly-evolvable enterprise software. It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. I am indebted to Jay Dvivedi and his team at Shinsei Bank for supporting this research. All errors are my own.

This blog approaches enterprise software architecture from a relatively theoretical perspective, so the implications for C-level strategic management may not be immediately obvious. I’d like to take a step back and explain why the concepts that I’m trying to develop are of real and pressing importance for large organizations.

Even in the most stable industries, the business environment changes constantly. Technology, customer needs, macro-economic trends, strategy and tactics of existing and emerging competitors, regulations, shareholder and union demands–all change constantly. Change may be gradual or violent, predictable or unexpected, but it never stops. To sustain performance in a changing environment, businesses must adapt.

In practice, adaptation almost always requires modification of business processes. For example, incorporating new media into advertising strategies necessitates changing the processes that plan, implement, and evaluate marketing campaigns. Similarly, to comply with new regulations, processes may need to incorporate different decision rules or generate new reports. It follows that the ability to modify business processes efficiently and rapidly is an important driver of organizational performance and a potential source of competitive advantage¹.

Imagine, for a moment, that you, the CEO of a major enterprise, are approached by a mysterious man in a blue suit who offers to sell you a remarkable robot. This robot, he says, will perform much of the repetitive, time-consuming, routine work that absorbs the time and energy of your managers and staff, freeing them up to work on more interesting problems such as acquiring competitors, developing new products, or expanding into new markets. Although this robot is very, very expensive and takes several years to train, the man promises that the robot works so efficiently that it will save you a huge sum of money and pay for itself within a few years. Although somewhat skeptical, you agree to purchase the robot.

Once the robot is finally ready for use, about a year behind schedule, you flip the switch. The robot is a wonder to behold, continually dashing off in all directions to monitor inventories and account balances, manage employee salaries and vacation allowances, keep track of customer orders, and prepare financial reports. The robot has some problems, such as calculating taxes incorrectly for a few states and occasionally losing orders, but the man in the blue suit assures you that the problems can be fixed in a few months–at some cost, of course. On the whole, you are satisfied: training the robot took longer than you expected (and the man in the blue suit charged a princely fee), and even now the robot misbehaves from time to time, but it does work very efficiently.

After about a year, your firm decides to introduce a new service. Instead of simply selling widgets outright, you will also lease them, enabling you to optimize maintenance over the widget life cycle. Of course, you must adjust your accounting processes to handle the leased widgets, and create new processes for coordinating the maintenance of leased widgets. Aha!, you think, another task for our marvelous robot. You call the robot into your office and ask it to take on these new tasks. The robot stares at you blankly. It doesn’t seem to understand. So you consult with the kindly man in the blue suit. Of course the robot can do this, he tells you, but we will have to retrain it. And we will have to make sure that the new training doesn’t interfere with the robot’s current work. This will take a year or two, he says, and it will be very, very expensive.

Couldn’t you just buy another robot, you ask, that would handle these new tasks? That would be very difficult, the man says, because you will end up with two separate accounting statements and two separate maintenance schedules that will conflict with each other. That may be so, you say, but can’t the robots be trained to talk with each other and solve these problems by themselves? Yes, says the man, with a twinkle in his eye, but it will take several years and it will be very, very expensive.

In the end, you do as the man in the blue suit suggests. And as the years go by, you find with increasing frequency that you face unpleasant choices between passing up business opportunities, or paying the man in the blue suit astronomical sums of money to retrain your robot to help you to capture the new opportunities (after seemingly interminable delays). You find it increasingly difficult to compete with smaller, younger companies with newer robots. You begin to wonder if you should have bought the robot in the first place.

The robot, of course, is the traditional enterprise software system. Installed at great expense, it works (perhaps) for a while. Over time, it becomes increasingly inflexible and increasingly costly to maintain. It promises a Faustian bargain: improved efficiency in the short term, at the expense of adaptability in the long term. The cost and time required to modify business processes rise higher and higher, to the point where they may nullify the benefits of otherwise profitable adaptations. Organizations may find that stagnation and gradual decline are, unattractive as they may be, nevertheless preferable to costly, risky, and time-consuming system modifications. Moreover, organizations become increasingly dependent on the firms that maintain the systems. Since many organizations struggle to achieve even short term efficiency improvements, traditional enterprise systems are dubious bargains indeed.

Baobabs

Jay uses the metaphor of a tree to describe this process. The enterprise system takes root in the organization’s processes and extends ever more deeply into them. Over time, the organization becomes so tightly bound up by these roots that it loses the freedom to move. Enterprise systems are like the baobabs described by the Little Prince:

A baobab is something you will never, never be able to get rid of if you attend to it too late. It spreads over the entire planet. It bores clear through it with its roots. And if the planet is to small, and the baobabs are too many, they split it in pieces… (Antoine de Saint Exupéry, 1971, 22)

Pulling up the baobabs

Though the preceding exposition may be a bit whimsical, the threat posed by inflexible enterprise software is not. Fortunately, just as the Little Prince found that he could solve his baobab problem by uprooting the baobabs as soon as they became distinguishable from rosebushes, the solution in the case of enterprise software may be similarly simple, if not nearly so obvious.

Judging from Jay’s experience “pulling up the baobabs” (i.e., getting rid of inflexible enterprise systems) and replacing them with more congenial species, the problem can be solved by architecting systems according to a relatively small set of design rules. These rules make systems far more modular, and hence smaller and more manageable–more like rosebushes than baobabs. Some of these rules, such as defining system components in terms of their inputs and outputs, are relatively familiar. Others, such as extreme decomposition, mutually-verifying dualism, component-level interoperation, context-awareness, and reversibility, are less familiar or, in some cases, entirely novel.

Applying these design rules appears to yield systems that are less costly, less risky, and less time-consuming to build, easier to manage and maintain, and far more malleable. Moreover, the systems can be characterized in terms of machines and assembly lines that build data objects–that is, in terms accessible to CEOs and line of business managers–while banishing arcane software engineering jargon to the domain of implementors where it belongs.

Although I am optimistic about the potential of these design rules (otherwise, I would not bother to research them), much work remains to be done in order to articulate them precisely and evaluate them accurately. Thus, readers will probably encounter logical gaps, questionable assertions, and as yet unexplored byways. Please do not hesitate to chime in with constructive ideas, suggestions, or criticisms.

¹For a theoretical treatment of this argument, see the literature on dynamic capabilities (e.g., Winter 2003, Teece, Pisano & Shuen 1998).

Computer-orchestrated work

This post is part of my collaborative research with Shinsei Bank on highly-evolvable enterprise software. It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. I am indebted to Jay Dvivedi and his team at Shinsei Bank for supporting this research. All errors are my own.

In my research on computer-assisted organizing, I set out to understand how computers alter the fabric of organizations. Here’s how I framed the problem in my dissertation:

In the computer age, complex information processing tasks are divided between humans and computers. Though designed and developed by humans, computers are autonomous agents that function as independent decision-makers. The dynamics of electronic information processing influence the dynamics of organizing and organizations in ways that cannot be understood in purely human terms. (Brunner, 2009)

My dissertation focused primarily on two aspects of this transformation: how computers drive further specialization in information processing work, and how computer-assisted work increases business scalability. A third aspect of the transformation had been on my mind ever since my days as a management consultant: it seems that computers and people are trading places within organizations.

In the past, humans created organizational structure through their patterns of interaction, while computers were plugged in to this structure to perform specific tasks. Increasingly, these roles are reversed: computers create organizational structure, while humans plug in to the computer system to perform specific tasks. Shinsei Bank’s mortgage loan operations provide an elegant example of the phenomenon. Rather than human credit approvers managing the loan application process from beginning to end and using computers to perform calculations or look up policies, a loan application system manages the process, calling on human appraisers, data entry clerks, analysts, or supervisors to provide input as necessary.

In Jay’s words, the computers orchestrate the work. The Oxford English Dictionary defines orchestrate as follows:

To combine harmoniously, like instruments in an orchestra; to arrange or direct (now often surreptitiously) to produce a desired effect.

The word seems apt. In computer-orchestrated work, computers arrange and direct business processes in order to “combine harmoniously” the work of individuals. Much like an assembly line, computer-orchestrated work enables individuals to focus on simple, well-defined tasks, while computers handle the coordination and integration of these fragmentary outputs. As bureaucracy¹ eliminated the reliance of organizations on specific individuals by defining roles, so computer-orchestrated work enables organizations to survive without the patterns of human interaction that define and sustain the structure of traditional organizations.

Computer-orchestrated work may greatly increase organizational performance. By lowering to nearly zero the marginal cost of coordination and integration, computer-orchestrated work makes possible greater specialization, which accelerates learning and increase efficiency. Moreover, computer-orchestrated work lowers the costs of monitoring and metering, potentially reducing agency costs. Computer-orchestrated work is easier to analyze and modify, which facilitates innovation and increases the returns to highly-skilled human labor (c.f. Zuboff, 1989). Although the design challenges are significant, computer-orchestrated work may be an essential tool for creating more intelligent organizations.

¹In the Weberian sense, as a highly effective organizing technology.

Design metaphors: zoo, house, railway and city

This post is part of my collaborative research with Shinsei Bank on highly-evolvable enterprise architectures. It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. I am indebted to Jay Dvivedi and his team at Shinsei Bank for sharing with me the ideas developed here. All errors are my own.

How to deal with the extreme complexity of enterprise software? The traditional approach relies on a set of abstractions related to data models and databases, interfaces, processes, and state machines. These conceptual tools are rooted in the theory of computer science. Jay takes a different approach: he attempts to mimic physical systems that solve analogous problems in the real world. Much as modern operating systems mimic the file and folder model that people use to organize paper documents, Jay’s software architectures mimic zoos, houses, railways and cities.

Enterprise software is filled with virtual things that come into existence, experience a variety of transformations, and finally disappear or solidify into permanent log records. These things may be users, customers, transactions, and so forth. To Jay, these things are the animals in a virtual zoo. They have each have their own life cycles and their own needs. Cages must be used to separate different kinds of animals in order to care for them and prevent them from interfering with each other. Processes specific to each kind of animal must be implemented for rearing, feeding, healing, disposing. The first step in designing a system is to identify the animals that will inhabit the system, separate them, and cage them.

The house metaphor complements and overlaps the zoo metaphor. Just as people live in houses in the physical world, representations of users and customers live in virtual houses. Users store their virtual belongings–records, certifications, etc.–in their houses, which they access using virtual keys. Houses have different rooms which are used for different tasks, and each room has equipment appropriate for the tasks to be performed there. Users, as represented in the system, must be aware of their context so that they perform the appropriate tasks in the appropriate places. Jay emphatically forbids “cooking in the toilet.” Users must also be aware of their roles: a guest in the house behaves differently from a plumber, and a plumber differently from the owner of the house.

When users are needed outside their houses to perform tasks, they travel on virtual trains to stations where operations are performed. They are aware of their destination from the outset, so they take with them only those belongings required to complete the task. After completing the task, they return to their houses. All of this happens transparently to the actual user: the architecture of the system does not dictate the structure of the user interface.

Together, the houses, trains, and stations make up a virtual city that models the work of the bank. This metaphor seems rather distant from the mechanics of an enterprise software application, at least compared to the familiar desktop metaphor, and I’m still putting together the pieces–so please consider this post a tentative first step toward articulating the idea. I’ll revisit the topic and add more detail in future posts. In any case, the key takeaway seems to be that the intricate and highly modular division of labor in the real world may be a useful metaphor to guide the design of modular systems in virtual worlds.

Enterprise software coevolution

This post is part of my collaborative research with Shinsei Bank on highly-evolvable enterprise software. It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. I am indebted to Jay Dvivedi and his team at Shinsei Bank for supporting this research. All errors are my own.

In an earlier post, I attempted to identify distinguishing characteristics of enterprise software. Jay pointed out to me another: the coevolution of enterprise software with the business of its host companies. Companies must adapt to continuously changing environmental conditions. Since enterprise software reaches deep into the operations of the business, the software must change, too. To achieve high performance, changes in the business and changes in the software must fit with each other; through this mechanism, each influences the evolution of the other.

This suggests a possible reason why standardization of enterprise software has proved so difficult. Companies often respond to competition by seeking to develop differentiated capabilities. If enterprise software and organizational capabilities coevolve, then companies may experience constant pressure to customize their enterprise software systems.

Mutually verifying dualism

For more than a year, Jay and I have been carrying on a dialogue about his methodology for developing enterprise software. This methodology appears to depart in many ways, sometimes radically, from traditional approaches. As a first step toward characterizing this methodology, I’m going to begin by writing a series of blog posts about the guiding principles that Jay has described in our conversations.

These principles are not necessarily mutually exclusive or collectively exhaustive, but they capture the essence of the methodology. At this point, I don’t fully understand how these principles fit together, and Jay has encouraged me to focus on thoroughly understanding each of principle in isolation before attempting to assemble the principles. Consequently, these blog entries may seem fragmentary or disconnected. As the research progresses, I hope to integrate and synthesize these principles into a coherent set of theoretically grounded design rules. Let’s dive into a principle.

Mutually verifying dualism: Model all operations as pairs of reciprocal actions between two agents in autonomous, reciprocal roles.

In this context, the term autonomous means that neither agent can dictate the behavior of the other; the two agents belong to separate control hierarchies and maintain their own records. Transactions provide a simple example, since they naturally lend themselves to dualism. Without dualism, we might model a transfer of a security from Alfred to Bernard as a unitary transfer operation recorded in a centralized transfer log. Such centralization may be convenient from a design perspective, but it has several drawbacks. First, an agent that controls the transfer functionality can perform transfers without consulting Alfred, Bernard, or any other user. Second, fraudulent or erroneous transactions may be impossible to detect, because the centralized transfer log is the sole source of transfer information and cannot be cross-checked. Third, transfer records are lumped together in a single log, so retrieving transfers performed by a particular user requires extracting them from a large database that may contain billions of records for millions of users. (The magic of modern databases makes this extraction of needles from a haystack possible and even straightforward, but it seems like a lot of infrastructure for an essentially simple task. As I’ll discuss in a future post, Shinsei’s philosophy is not to drop the needles into the haystack in the first place.)

Alternatively, following the principle of mutually verifying dualism, we can break the transfer into a pair of reciprocal operations between Alfred, in the role of provider, and Bernard, in the role of recipient. The transfer occurs only if both Alfred and Bernard cooperate, and the transfer can be verified by comparing Alfred’s record of the transfer with Bernard’s and ensuring that the records match.

Mutually verifying dualism requires that all operations be modeled in this way, entailing a shift in the way we conceptualize many operations. For example, consider Carl logging in to a savings account online. This operation would traditionally be modeled by the system as a unitary login event and recorded in a centralized log. To apply the mutually verifying dualism principle, we break the login operation into a pair of reciprocal operations between Carl and Carl’s Savings Account (assuming, for the moment, that he is logging in to his own account). Carl, modeled in the system as a user with its own identity and records, requests access to Carl’s Savings Account and records the result. Inversely, Carl’s Savings Account, similarly modeled as an independent entity with its own identity and records, grants (or denies) access to Carl and records the result. Using this approach, fraudulent or erroneous logins can be detected (sometimes) by reconciling the user and account records.

Image by Theon from Wikimedia Commons, used under Creative Commons license

Shinsei visualizes its network of mutually verifying operations as a geodesic sphere. Image by Theon via Wikimedia Commons, used under Creative Commons license.

In principle, mutually verifying dualism resembles double-entry bookkeeping, which helps detect errors by breaking unitary financial flows into dual credit/debit operations. As in double-entry bookkeeping, mutually verifying dualism breaks down if a saboteur takes control of the systems on both sides of the interaction (e.g., the user system and the savings account system), or symmetric errors occur in both systems. The probability of these relatively unlikely events can be further reduced by designing a network of mutually verifying dualisms. The imagery used by Shinsei to describe the approach is a geodesic sphere, where the location of every vertice can be verified from multiple, independent perspectives.

Perhaps the most important implication of mutually verifying dualism is that records of past events can be reconstructed if any system component breaks irreparably.

Mutually verifying dualism creates some complications for system design. Since interacting agents must belong to separate control hierarchies, centralized designs are infeasible a priori. Duality implies redundancy, so changes need to be propagated to all concerned agents. Modularity probably precludes the possibility of unified or universal data models.

What is enterprise software?

This post is part of my collaborative research with Shinsei Bank on highly-evolvable enterprise software. It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. I am indebted to Jay Dvivedi and his team at Shinsei Bank for supporting this research. All errors are my own.

Since this research project focuses on improving the architecture of enterprise software, it seems like a good idea to explain what I mean by the term “enterprise software” and why I think that enterprise software architecture represents such a challenging problem. I’m on the lookout for a well-developed software typology to leverage here, but I haven’t found one yet. The Wikipedia entry on enterprise software is pretty much devoid of insight. So, what follows is my own take on the issue. Definitions always need a fair amount of batting around to get them into shape, so consider this “iteration zero”. Please feel free to suggest ideas, complications, or references.

Enterprise software refers to programs for which organizational considerations fundamentally influence both design and function. This influence has several dimensions, not all of which are unique to enterprise software:

Many users: In contrast to single-user applications such as word processors or spreadsheets, enterprise software is used simultaneously by tens, hundreds, or thousands of users.

Many, diverse and interrelated roles: Enterprise software allows users to be associated with roles that determine the ways in which they can interact with the system and with each other. This contrasts with many multi-user applications such as social networking, online collaboration, or communications applications that support only one or a small number of roles. In principle, the role dimension of enterprise software resembles the groups and permissions functionalities in multi-user operating systems, but the universe of roles in enterprise software is often far more elaborate. As I’ll describe in a subsequent post, roles play a central role in Shinsei’s software design principles.

Conflicting interests: Organizations are riven with conflicting interests, from inter-departmental battles to team-level skirmishes to individual rent-seeking. Enterprise software becomes another means for pursuing these conflicting interests. Thus users routinely and strategically misuse or attempt to misuse the system (“misuse”, of course, being in the eyes of the beholder). In our conversations at Shinsei, Jay often emphasizes the importance of assuming that users will hijack the systems and use them to pursue their own goals at the expense of the organization. This reality differs from the assumption of many collaborative multi-user systems such as shared spreadsheets or social networking services which generally operate on the assumption that users will only invite or “friend” others who share their interests, at least within the domain of the program’s activity. If these interests are found to diverge, the offending party will be uninvited or “unfriended”.

Modeling many, diverse and interdependent phenomena as they unfold over time, often spanning months or years: The purpose of an enterprise software application is to track the state of the business. Generally this means modeling contracts, perquisites, and transactions; stocks and flows of money, people, and materials; and budgets and forecasts, among other phenomena. These phenomena often span hundreds or thousands of classes, depend on each other in complex ways, and persist for many years. The complexity of this modeling task is probably several orders of magnitude greater than that of more narrowly focused applications that handle a small class of largely independent tasks, often relatively stateless and completed in a few minutes, hours, or days.

Highly politicized: Enterprise software directly influences the dynamics of power and decision-making in its host organization. For example, the design of a system may constrain or relocate decision-making authority by forbidding certain actions (e.g., price discounts over a certain level) or requiring additional approvals to complete a task. Consequently, the design and modification of enterprise software is highly politicized and often requires the involvement of senior managers. As a result, design of enterprise software often becomes a political rather than a technocratic endeavor. This contrasts with the design of systems further down the technology stack (e.g., operating systems or databases) or function-specific systems that do not span group boundaries.

Regulatory interdependencies: Since enterprise software directly influences organizational decision-making and records the consequences of organizational activity, its design depends on regulatory constraints in these domains, and use or misuse of the software may have regulatory implications.

It seems to me that these characteristics clearly distinguish enterprise software from other application types, while also highlighting the difficulty of the design challenge faced by enterprise software architects. The goal of this research, then, is to develop some design rules to render this challenge more tractable.