From Business Intelligence to Enterprise IT Architecture, Part 7

Originally published 5 October 2010

This ongoing series of articles describes a new enterprise IT architecture that emerges from a reevaluation of modern business intelligence needs and technologies. The second article introduced the Business Integrated Insight (BI2) architecture as an evolution of data warehousing/business intelligence, while parts 3, 4 and 5 drilled into the information layer, the Business Information Resource (BIR). This article concludes our look at the process layer of the architecture—the Business Function Assembly—begun in part 6.

The Business Function Assembly (BFA)

Part 6 of this series set out to bust three current myths about process in the business and proposed three modern realities on which to base new thinking about what is required today:
  1. Myth: Decision making is a “no process zone.”
    Reality: Everything a business needs to do today, whether operational or informational in nature, has a process or workflow of varying flexibility underlying it.

  2. Myth: Decision makers are always seeking information, and the more the better.
    Reality: Business users are focused on results and the actions they need to take to get them; process trumps information—always.

  3. Myth: Business and IT processes are fundamentally separate in nature.
    Reality: Business and IT processes are all part of the same process environment; they all exist to serve business ends and need to be fully interlinked and interchangeable.
While these myth/reality pairs have still to gain wide recognition, there is another important change in the way business function is delivered that is widely accepted—the move from monolithic applications to plug-and-play assemblies of piece parts.

Traditionally, applications were written with a single, well-integrated purpose in mind. The thinking originates in the batch world. An application is loaded into memory, it reads input, writes output and (hopefully) completes with a zero return code. Without user interaction during runtime, applications were designed to handle as many functional steps as possible within the context of the information they read and the logic contained therein. With the move to interactive computing, the same application model was largely carried over to the new environment. Over time, monolithic applications moved to a more structured approach where functions and sub-functions were designed and programmed with well-defined boundaries and information-passing interfaces. But they still remained largely monolithic. By the late 1990s, it was becoming increasingly clear that these black-box applications, however well-structured internally, were too inflexible for rapidly changing business needs and too costly to maintain and upgrade. What to do?

Enter service orientation and, by 2001, the formalization of a service-oriented architecture (SOA). I've described SOA in some detail in my 2007 article. Of course, by now there are many different vendor-dependent flavors of SOA. Beyond that, Web 2.0 has introduced further variations on the concept. Regardless, the principle is the same—software components of sufficient granularity to be recognized and used by business users are instantiated as services that have independent existence, published interfaces and can be searched and embedded, removed and replaced in larger components with minimal effort. While I have been engaged in many debates about the viability and practicality of SOA and similar architectures, in my view software developers have little choice today but to adopt one of these approaches if they are to satisfy modern business demands for flexibility, reuse and user empowerment.

This modern drive toward complete service orientation of business function enables the key concept of assembling and disassembling process flows in today's business. It is for this reason that the process layer is called the Business Function Assembly (BFA).

The Process Space

Figure 1:
The Two Axes of the BFA Process Space

In line with the information layer (BIR) of the architecture we've already seen (and the people layer, yet to come), I describe the business function in terms of a process space. As shown in Figure 1, this space is two-dimensional, described by the Business Effect (BE) and Active Scope (AS) axes. Each axis is divided into four broad categories; and, as in the case of the BIR, each axis represents a continuum of characteristics rather than discrete categories. Thus, although the categories are described as if cleanly bounded, in reality they merge and blend one into the next.

Business Function Basics

Each piece of business function is created and exists for one, and only one, reason—to enable the business to achieve some goal or objective. The goal may be to understand and keep ahead of market trends, to keep a supermarket shelf fully stocked, or to build and deliver Airbus A380 airplanes. An objective may be as small as recording a customer's change of address or as large as taking over its principal competitor. Goals and objectives come from the people layer of the BI2 architecture, the Personal Action Domain (PAD); only humans can decide what a business’ goals should be and set objectives for achieving them.

The role of the process layer is therefore to orchestrate the activities needed to achieve the goals and objectives of the business. Such activities can be performed by people, machines or software; and, of course, automation increasingly shifts the burden from people to machines and software. Recognizing that an activity can, at different times, be performed by any one of these implies that the architecture must include all three within its scope. For example, the task of closing a sale may be performed by a salesperson, a vending machine or website. If the process layer is to accurately and completely represent the business, each of these possibilities must be represented. This representation occurs entirely in the BIR. Whatever its source—person, machine or software—where the fact of the sale comes together is in the information asset. The BFA is, in effect, an intermediary between the human intentions of goals and objectives represented in the PAD and the information that records and measures them in the BIR.

The BE Axis: Business Effect

The BE axis therefore describes how a particular function which supports a goal or objective of the business interacts with the BIR. In traditional programming, this interaction was often described by the acronym CRUD—create, read, update, delete—conceived largely for transactional databases. However, this categorization is both too technology oriented and too directed toward traditional hard information storage. Modern business function must take account of soft information, often with very different consistency and commitment approaches; event data, some of which may never be permanently stored; and far more beyond.

Furthermore, as discussed in Part 4, the BIR also contains metadata, another key aspect of the information asset of the business. The BFA must therefore also act on metadata, which defines and describes the structure and meaning of the information layer. This also follows directly from reality #3 listed above.

As a result of these considerations, we come to the following four categories on the BE axis. Recording function produces new business entities or instances; for example, create a new purchase order (hard information) or create an entirely new type of order (metadata). Such function operates on the leftmost side of the BIR. Recording function must create a permanent record of information for longer term analysis and auditability; current thinking about event data (in-flight information) that suggests some such data is never landed on disk may need to be reconsidered. Conditioning function modifies existing entities or instances; for example, update an order or archive an old order (hard information) or extract begin and end dates from a contract document (soft to hard information conversion). The effect of conditioning extends over the entire BIR, as it is the mechanism by which information is transformed and moved along the various axes of the BIR. Interpreting function uses existing information to monitor and understand what is occurring in and outside the business, allowing hypotheses about causes and effects to be formed. This function does not modify existing information, but can create new information based solely on existing information. Actioning function applies insight to interpretative hypotheses and existing information to take action. Such actions link back directly to invoke recording, conditioning or interpreting functions, thus closing the sense-and-respond loop, both across the full breadth of the axis and between individual categories.

The AS Axis: Active Scope

As previously described, the BFA conforms to SOA principles, and this is reflected directly in the AS axis. In a typical SOA, functionality is structured as well-defined, callable and largely immutable services that perform meaningful activities at a business level. Services may be built upon lower-level services recursively, and linked together into workflows. They can be inserted, replaced or removed with minimal technical expertise from a workflow in a plug-and-play manner. The AS axis reflects these characteristic categories, but extends them in both directions.

Transactions represent the atomic category on the axis and are the fundamental level at which function and information interact. Traditionally, transactions on hard information have strong ACID (atomicity, consistency, isolation and durability) characteristics. In BI2, this generally remains the case for hard information. However, because of the breadth of information types in the BIR—atomic, derived, compound and multiplex—a much broader mix of transaction types must be included with differing ACID characteristics. For example, in the NoSQL paradigm (implemented in Google's BigTable and Amazon's Dynamo, for example), often only weak consistency such as eventual consistency or single data item transactions may be offered. At the other end of the axis, processes describe the highest level of workflows, spanning entire business areas.

Moving along the axis from the transaction end to the process end, definitional control moves from IT to the business. Processes and, increasingly, workflows are fully business defined. Transactions are clearly the province of IT and services mostly so. All functional categories, and their actions and interfaces, are described by metadata in the BIR.


As the middle layer, the BFA plays a key role in the BI2 architecture, bridging users’ needs to and from the information resource of the business. As the ultimate record of the business, the BIR is the storehouse of work-in-progress (operational information, both hard and soft), the record of information and function structure (metadata) as well as the long-term memory (for analysis, audit and archival). However, as previously mentioned, users typically think more in terms of activities and actions than of data and information. The BFA is thus the impedance matching layer from business users’ thinking to the information heart of the business. And in the next article in this series, I’ll move up a layer to discuss the personal action domain and see what makes users tick.

SOURCE: From Business Intelligence to Enterprise IT Architecture, Part 7

  • Barry DevlinBarry Devlin
    Dr. Barry Devlin is among the foremost authorities in the world on business insight and data warehousing. He was responsible for the definition of IBM's data warehouse architecture in the mid '80s and authored the first paper on the topic in the IBM Systems Journal in 1988. He is a widely respected consultant and lecturer on this and related topics, and author of the comprehensive book Data Warehouse: From Architecture to Implementation.

    Barry's interest today covers the wider field of a fully integrated business, covering informational, operational and collaborative environments and, in particular, how to present the end user with an holistic experience of the business through IT. These aims, and a growing conviction that the original data warehouse architecture struggles to meet modern business needs for near real-time business intelligence (BI) and support for big data, drove Barry’s latest book, Business unIntelligence: Insight and Innovation Beyond Analytics, now available in print and eBook editions.

    Barry has worked in the IT industry for more than 30 years, mainly as a Distinguished Engineer for IBM in Dublin, Ireland. He is now founder and principal of 9sight Consulting, specializing in the human, organizational and IT implications and design of deep business insight solutions.

    Editor's Note: Find more articles and resources in Barry's BeyeNETWORK Expert Channel and blog. Be sure to visit today!

Recent articles by Barry Devlin



Want to post a comment? Login or become a member today!

Be the first to comment!