Purpose of a Business System Architecture

strict warning: Only variables should be passed by reference in /home/enterpri/public_html/modules/book/book.module on line 560.

A companion article[2] in this issue creates a meta-language of architecture for technology-based information systems.  This meta-language enables architects to communicate with a common set of concepts about how information systems can be designed in a modular way with commonly understood interfaces.  This article extends the idea of a meta-language to consider issues of the business to be supported by IT solutions.  Our concern is to understand how the domain of business can be understood according to some common generic concepts.

A dictionary definition of architecture is, “a unifying or coherent form or structure.”  This definition is appropriate for the kind of architecture that is addressed by the ESS project.  Such an architecture is used for two purposes:  to understand and to build.  In this article we are trying to understand the meaning of business knowledge by using an architecture of key business concepts.

A valid question may be raised as to why we should be concerned with an architecture of business concepts, in the context of building software systems.  After all, IT architects do not create businesses, they create technology-based information systems.  However, the systems that they create do have a fundamental impact on businesses.  In addition to purely technical issues, information systems architects need to be concerned with the content and usage of the systems that are built.

An analogy is often drawn between the architecture of buildings and the architecture of software systems.[3] One lesson from that analogy is that architects of buildings start with a fundamental understanding of the purposes to be served by those buildings.  Architects of suburban homes need to understand something about the behavior patterns of young, growing families.  Architects of manufacturing plants need to understand patterns of configurable assembly lines.  Architects of high-rise office towers and architects of mini-malls need to understand patterns of business behavior in core business districts and outlying areas respectively.  In a similar fashion, architects of enterprise systems need to understand patterns of business behavior and patterns of technology and how they work together to enable businesses to achieve their strategic and tactical goals.

The building analogy only goes so far in understanding business and its IT support.  Another perspective on business enterprises is to think of them as living systems, undergoing an ongoing process of evolution.  This analogy helps us to understand the relationship between businesses and information systems technology.  Evolution is the result of two basic conditions.  One is a source of novelty[4], and the other is an opportunity to expand into unoccupied environments[5].  Today the use of information technology is creating both the necessary source of novelty and the expansive environment that is driving rapid evolution of business.

We are in the midst of technology-driven and technology-enabled business evolution, as networks and information technology create new business eco-niches.  Examples of evolution taking place in this new marketplace ecosystem include:

  • A book store, a bank, and a car dealership that come into your home.
  • Insurance companies that think they're banks, and vice versa.
  • Companies outsourcing necessary functions to other companies, including the most intimate form of outsourcing, customer service.

Figure 2 below shows how this accelerating evolution is being fueled by technology.  Technological innovations give rise to increased opportunities:  new ways to do old things better, and whole new things to do (such as make and sell technology products).  These opportunities give rise to business innovations, and companies move in to take over new niches and sub-niches.  These changes in the way of doing business create new ideas and expectations of even better, more innovative performance on the part of technology.  This in turn puts pressure on technology providers to support still more new and innovative forms of business behavior.  An example of this cycle is that the technology innovation of the Internet has created new opportunities for companies to reach their customers (not to mention all the opportunities to provide Internet hardware and software).  The increased reach provided by the Internet has enabled business innovations such as on-line automobile shopping.  This increases the expectations that to be in business means to be able to provide Internet sales capability.  This, in turn, drives the need for increased security and payment processing, which drives technology providers to support increased expectations.

Figure 2

This mutually evolving relationship between business organizations and IT systems requires the ability to capture and portray business and technical information in a way that makes the two sets of information easy to interrelate.  The meta-language proposed here provides a semantic framework for speaking about common business concepts, and relate them clearly to concepts that describe IT systems.

The semantic framework must support two key architectural motivations that arise from the effort of building information systems.  One of these motivations is the need to clearly articulate the issues that most strongly drive requirements.  Our framework needs to zero in quickly on the most important things to be studied to get an effective understanding of the business, or type of business, to be supported by the IT solution.

The other key architectural motivations for our framework is that it needs to provide clear guidance as to how to organize work.  The work of building information systems is most effective if it is organized as a value-chain.  This means that teams of people work on building things that become part of, or support, other things being built by other teams.  We want our business architecture to help the partitioning and relationships of work effort.

In order to support the architectural objectives noted above, there are several principles that inform the creation of this business system architectural framework.  These principles are key to assuring the business system architecture effectively addresses the architectural objectives noted above.

  • Orthogonal - We want the set of chosen concepts to divide business information in a way that is non-overlapping.  This is aiming at two results: one is that we can divide the analysis space cleanly for purposes of understanding requirements and partitioning work.  The other result is that we can see interesting intersections of disjoint concepts.
  • Complete - We want a set of concepts that taken together cover the totality of business concerns, albeit at a necessarily very high level.
  • Memorable - We want a set of concepts that can easily be remembered as teams and individuals discuss the business opportunities being considered.  This means that they need to be small in number, and of a structure that makes them memorable.
  • Rich - We want the set of concepts to be able to produce interesting further classifications, thereby carving the business domain at its joints.  Ideally we should be able to create multiple levels of types, even, so that we can divide the generic business domain space, and then further analyze actual businesses.  This implies that our concepts should be semantically interesting in their own right, and not some overly abstract meta-meta construct, such as “thing-relationship-thing.”
  • Generic - Even though we want some richness and memorability in this framework, it will not do for it to be specific to any single business, or even any particular industry.
  • Appropriate - Finally, we want our concepts to be truly business concepts, and not information technology constructs in disguise.  This means that it should not be a database design or software model, as might be the case if we force-fit an entity-relationship paradigm or object modeling paradigm into this arena.