David
 James
 Brunner

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.