Skip to main content
Taking BI beyond the Business Analyst

 

Foreword

 

Dear Architect,

In this, the 22nd issue of The Architecture Journal, you’ll get our coverage on business-intelligence (BI) aspects of which architects like you and me need to be aware today.

As we did in previous issues, so as to guarantee accuracy, relevance, and quality, we set up a board of subject-matter experts to analyze the problem space— harvesting today’s main topic concerns.

The articles that you are about to read were chosen based on those concerns. Let’s take a look at them:

  • Enterprise BI strategyDinesh Kumar (Microsoft) introduces the notion of business infrastructure, which—together with capability models that are described in previous issues of The Architecture Journal—help organizations not only gain business insight, but act upon it, too.
  • Also, Sundararajan PA et al. (Infosys) propose a semantic enterprise data model for interoperability—adaptable for evolution through its life cycle.
  • Embedding business insights into our applications—Traditionally, the final output of BI is considered to be scorecards and reports that are used as strategic decision support. Using implementation examples, Razvan Grigoroiu (Epicor) tells us how to put these outcomes within the reach of line-of-business (LOB) applications.
  • Infrastructure and performanceCharles Fichter (Microsoft) explains the design principles for supporting a global data-warehouse architecture, with effectiveness and performance in mind.
  • End-user and self-service BI—BI projects typically fall short in allowing users who have basic experience to handle how results are exposed, without any dependence on IT specialists. Ken Withee (Hitachi Consulting) shows multiple ways to tackle this issue by using facilities that are already available throughout the Microsoft platform.

As a side topic, outside the cover theme, this issue features an article by MVP Jesus Rodriguez (Tellago) on lightweight SOA implementations, and their patterns and principles.

The reader will also find more valuable BI input in side columns, as well as our second companion series of short videos, which are available at http://msdn.microsoft.com/en-us/architecture/bb380180.aspx.

I’d like to finish by thanking the team of subject matter experts who helped me complete this challenge. First, I want to thank guest editor Matt Valentine for giving me direction in the makeup of this issue. Also, for its guidance and suggestions to give final shape to Matt’s ideas, I’d like to thank the editorial board that we put together this time.

Enjoy the issue! Remember that you may send any feedback to archjrnl@microsoft.com.

 

Diego Dagum
Editor-in-Chief

 

Contents


This issue is also available as a PDF. Download it here.

Rate this content 

Relevant Time-Performance

Management

Usha Venkatasubramanian

 

Organizations need to make informed business decisions at strategic, tactical, and operational levels. Decision-support systems were offline solutions that catered to specific needs. With new trends, there is a need to cover a larger set of people—right from the CEO, who looks at a larger timeframe, up to an operations manager, who needs recent statistics. Therefore, we must build a performance-management system that delivers information at the relevant time: Relevant Time-Performance Management (RTPM).

How can an organization provide self-service capability to the business, while still maintaining the data recency and granularity? We implemented a multilayered data warehouse that is both a sink and a source of information. Data currency was maintained by using a suitable adapter to poll data (for example, SSIS in the Microsoft BI suite).

  • Management Organization-Structure Relevance
    Near-real time data was trickle-fed into the lowest layer and reflected in the output for the operational manager. Data was sourced to higher levels of managers by creating higher layers of aggregation, and at predefined time intervals. Granular data got offline-archived for the future. When data reached the highest level of aggregation, it was retained for comparative reporting for a longer duration of time.
  • Information Relevance
    Current information requirements that are categorized as primary data (information source) resided in all layers. Data that is not required for querying was captured as supplementary data (data sink). Some data from the secondary layer would move to the primary layer, if there is a request for additional data. Likewise, a primary data element would be retired by moving it to the secondary layer.
  • Data-Nature Relevance
    A careful balancing act is needed to control the unwieldy growth of the data volumes in the data-warehouse database, while still providing the relevant information. An offline retention policy–based archive helps maintain the relevant information.
  • Recency Relevance
    Recency of information calls for a proper Change Data Capture mechanism to be in place for different stakeholders to get what they need. This would primarily depend on the nature of the source data itself. Using metadata-driven CDC and normalized CDC, the data is maintained as recently as required.
  • Delivery Relevance
    Information delivery was a mix of push and pull to maintain the time relevance. Standard reports were delivered through the push method and ad-hoc reports through the pull method.

Some of the case studies in which we’ve used these principles effectively can be seen here.


Usha Venkatasubramanian is the deputy head of the Business Analytics Practice at L&T Infotech.