Business Insight = Business Infrastructure = BI Platform

Dinesh Kumar
Microsoft Corp.

December 2009

Summary: To do things differently, one must look at things differently. This article introduces the notion of business infrastructure providing the necessary bridge between (contextual) business insight and a (common) business-intelligence (BI) platform. Using the business- infrastructure and business-capability models, the article provides a prescriptive approach to planning and delivering BI services.

Changing Landscape

Currently, the IT industry is transitioning from an era of limited capability of individual/functional reporting and analysis to one that is defined by a connected, collaborative, and contextual world of BI. Insight is gained not only by analyzing the past, but also by anticipating and understanding the future. Insight has value only if people are able to act on it in a timely manner.

As the need for real-time data gathering, analysis, and decision making increases, so, too does, the need to perform actions through transactional systems. Insight is not individual. In a world of collaborative BI, people want to find, share, comment on, and review data quite similarly to how they handle documents. Insight is a core competency only if it comes naturally to people. As a result, cost, capability, and consistency become equally important.

Table 1 provides a list of characteristics for business insight in any organization.

Requirement	Implication
Collaborating across the organization	User experience—Consistent approach to delivering, analyzing, finding and sharing information to make informed decisions Collaboration—Ability to share, annotate, and perform actions as you would with a document
Transacting decisions	Speed and integration—Real-time data gathering, analysis, decision making, and subsequently taking actions through transactional systems
Anticipating unknowns	Service-oriented—Adding, integrating, and delivering additional data as it becomes available or relevant
Reducing cost of change and ongoing operations	Platform—Shared services

Table 1. Business-insight characteristics

Current Practices

Currently, there are two dominant approaches to delivering BI capabilities. Some organizations utilize a “make-to-order” approach to deliver a specific solution for a specific business need. For example, when a sales team wants to target customers for upgrades and new products, the IT group creates a customer data mart or a report, extracting and summarizing data from CRM systems. When manufacturing wants to analyze inventory or supply chain, IT creates a manufacturing data mart, extracting and summarizing information from an ERP system. To address new requirements, these organizations keep adding layers to individual, functional, or unidirectional reporting-and-analysis systems—introducing duplication, delays, complexity, and cost.

Other organizations have adopted a “build it and they will come” approach by building a massive, centralized, enterprise data warehouse with the expectation that different groups might want to access and analyze data someday. It takes significant effort as well as expenditure to build something; then, it takes an equally huge effort and cost to maintain and extend it.

These approaches to planning and building BI capabilities are not sufficient to support new information-driven business processes and organizational models. To gain and capitalize on business insight, we must think differently about how we evaluate, plan, communicate, and implement BI capabilities in the organization.

Next Practice

Understandably, people are driven by their needs. The BI-capability planning and delivery must respect individuality while driving consistent thinking and common capabilities in business and IT. This article introduces the next practice with a capability model and a methodical approach for planning BI capabilities for business insight.

Concept #1: Business Infrastructure

Just like IT, business also has an infrastructure.

Based on the work across a wide variety of industries and solution scenarios, the author has realized that almost every business process or activity is dependent on similar sets of capabilities. For example, when cashing a check in a bank branch, a client asks the bank teller about a new mortgage promotion. The teller calls someone in the mortgage department to inquire about the new promotion. The same client is thinking of rebalancing a financial portfolio and asks a financial advisor in the same bank about treasury bonds. The advisor calls a bond expert for information.

These two business activities are remarkably different and performed in two different departments, yet both rely on a similar capability—that is, access to an expert. Likewise, various business processes and functions need or use similar BI capabilities, which are different only in content and context. For example, the finance department is focused on financial data, whereas manufacturing is focused on production and quality data. However, both need the same BI capability: to report and analyze the information that they value. In other words, improving the common BI capability—such as reporting and analysis in the preceding example—will improve or enable multiple business activities.

Just as with IT infrastructure, business infrastructure represents a set of common, horizontal business capabilities that support multiple specialized, vertical business processes and functions. Just as in IT infrastructure, improvement of the business infrastructure will reduce process complexity, enhance organizational agility, and drive business maturity. Just as IT architecture includes both applications and infrastructure capabilities, business architecture includes both business-process capabilities and business infrastructure.

In the context of BI, we have organized the horizontal business capabilities into three value domains. The value domains represent the type of outcome or impact that is expected in the context of a business process or activity in which the underlying capability is leveraged.

See Table 2 for the list of business capabilities that make up the business infrastructure for business insight.

Value domain	Business capability	Description
Business management		Plan & manage core business functions. Ability to plan & manage:
	Financial management	Cost and revenue across the organization.
	Customer management	Demand generation, sales, service, and customer satisfaction. Product management
	Product management	Product planning, development, manufacturing, and distribution.
Innovation & transformation		Drive growth & competitive advantage. Ability:
	Synergistic work	For a team to work together to perform an activity or deliver on a shared objective. The team might include people from either within or outside the organization.
	Consensus & decisions	To gain necessary consensus among stakeholders and make decisions. Stakeholders might involve people from across organizational boundaries.
	Communication of timely, relevant information	To send and receive required information to the appropriate people, when needed. Communicator or receiver might be from either inside or outside the organization, and communication may be either upstream or downstream.
	Sense & respond	To anticipate, detect, and monitor internal or external events or trends, and to take appropriate actions.
	Authoritative source of Information	To rely upon information in any transaction or decision making.
Planning & delivery excellence		Drive operational performance objectives. Ability to:
	Information orchestration	Consolidate information across business activities or disseminate information to appropriate consumer, when and where needed.
	Governance & compliance	Ensure that various policies and rules are understood and that the organization behaves accordingly.
	Reporting & analysis	Create, analyze, and deliver appropriate information, when and where needed.
	Performance measurement	Measure, monitor, and communicate appropriate cost and performance metrics of a business activity or process.

Table 2. Business-infrastructure capabilities

One could argue that there could be additional business capabilities under the business-management value domain. Financial, customer, and product management are considered core capabilities of every organization, regardless of size and industry, including the public sector. Other areas of business management are either extensions to these core areas or specific to an industry or an organization. For example, in a utility company, logistics management and workload management are added, as they are quite important and distinct areas in the organization. In a financial institution, individual and institutional banking are attributes of customer and product management, but financial-advisor services are added as a core capability for additional focus.

These capabilities are fairly industry-independent or process- independent; therefore, they can be characterized along a value- maturity model. The maturity model helps organizations to assess the current state and articulate the desired state easily and quickly.

Table 3 provides examples of the maturity level of some of the business-infrastructure capabilities. The detailed model enumerates the maturity of each capability in terms of people, process, information, access methods, security and compliance, availability, and performance attributes.

		Value-maturity level
Value domain	Business capability	Level 1	Level 2	Level 3	Level 4
Business management	Customer management	Sales and corporate functions can summarize and report on sales performance.	Any individual or business function can understand and monitor sales and marketing data in their own context.	An extended organization (partners) can access to sales and support data for its own analysis. People can perform trending and develop forecasts.	Access and analysis can be performed with nominal effort anytime, anywhere, and by anyone, including customers.
Innovation & transformation	Sense & respond	Local, functional level. Collect and report on operational data.	Enterprise level; 24/7; customer data.	Include partners and remote locations. Monitor, consolidate, and analyze.	Worldwide level. Information includes industry and market research.
Planning & delivery excellence	Information orchestration	Orchestrate information at functional level— based on internal operational data, and delivered in report form on internal network	Orchestrate information at enterprise level, including customer information— consolidated and available via remote access, team sites, portals, and COTS apps.	Orchestrate information across partners (supply chain)—analyzed and available on multiple device types or networks.	Orchestrate information across the industry—allowing what-if scenarios, and available at point-of- interest on any device or network

Table 3. Sample business capability-maturity model

Concept #2: BI Platform

BI is cross-functional, cross-people, and cross-data.

Just as there are common business capabilities that enable business insight, there is also a collection of BI services that articulate underlying technical BI capabilities. A service-oriented approach to defining BI capabilities minimizes complexity and cost, while it drives consistency and maturity in capabilities.

BI services are organized into four domains, each of which addresses a distinct segment of the information flow. Table 4 lists the four domains and the relevant capabilities that are included in each domain.

BI-service domain	Capabilities
Information delivery	Accessing and delivering information, when needed, on a device or tool through one or more channels
Information analysis	Aggregating, analyzing, visualizing, and presenting information
Data integration	Mapping, sharing, transforming, and consolidating data
Data management	Storing, extracting, loading, replicating, archiving, and monitoring data

Table 4. BI services and capabilities

Figure 1 articulates the collection of BI services under each domain that use interfaces to other inbound, outbound, and dependent services.

Figure 1. BI-service architecture (Click on the picture for a larger image)

The concept of platform or infrastructure services can be applied across the whole IT domain. It is expected that BI services will leverage and integrate with other enterprise services such as security, backup/recovery, and storage. The complete IT-service portfolio with capability models is covered in a patent pending on IT Service Architecture Planning and Management.

Just as there is a capability-maturity model for business infrastructure, BI services are also characterized by using a capability- maturity model. The BI-service maturity model leverages and extends the Microsoft Infrastructure Optimization (IO) Model.

Table 5 provides an example of BI-service maturity levels. The model includes a range of attributes, addressing the 360-degree view of the service.

Attribute	Description	Level 1	Level 2	Level 3	Level 4
Analytics	Provide ability to analyze data from any source
Information	What types and formats of information are provided?	Functional or departmental data	Business-process data	Summary and details across business entities	Historical, forecast, trends, KPIs, scorecards; multi- dimensional; XML formats
Transactions	What actions can be performed?	Import, create	Slice and dice	Trend, drilldown and across	Predictive analysis, data mining
Access	Who can access the capability, and how?	Desktop applications	Web browser and analytical tools; remote access	Integrated productivity suite, Web-based interactive tools; Internet access	Embedded LOB applications, mobile devices; available both offline and on mobile devices
Integration	How is information consolidated, disseminated, or integrated?	E-mail attachments; file- based; batch	Web sites, database APIs; scheduled	Workspaces, XML-based interface; on-demand	Subscription and notification; Web services; real-time
Infrastructure	How is this capability implemented?	Individual files	Functional portals	IT-provisioned and -managed	Hosting, shared services
Security	How is information secured or access controlled?	None	Access user-managed	Role-based access	Rights management; compliance management
Performance	What are the service levels?	Response time acceptable at major sites; availability unpredictable or not monitored	Response time acceptable at branch location; unplanned down time	Response time acceptable at all user locations; 24/7 availability	Anytime, anywhere; scalable
Operations	How is this capability provisioned, monitored, or managed for business continuity?	No formal backup/recovery procedures	User-managed backup/ recovery; manual monitoring and provisioning	Centrally managed backup/recovery; automated monitoring, reporting and provisioning	Automated backup/ recovery; monitoring exceptions; self- provisioning
Technologies	How is the technology life cycle managed?	No standard or guidelines	Multiple technologies and versions	Standard across one or more business units	Enterprise-wide standard

Table 5. BI-service capability maturity—Analytics service

Concept #3: Relationships and Road Map

Don’t reinvent what we already know.

As the common business and technical capabilities are industry-, organization-, or technology-independent, the relationships or dependencies between business and technical capabilities are predefined. This allows organizations to answer quickly such questions as, “What technical capabilities do we need to enable a level of maturity in a business-infrastructure capability?” and “What business capability can be enabled by using a technical capability?”

Relationships help in rapidly defining the scope, identifying the dependencies, and communicating value to various stakeholders. Figure 2 provides a framework for leveraging known relationships and maturity models for developing the overall vision and architecture road map.

Figure 2. Relationships and planning framework (Click on the picture for a larger image)

Case Study: Assessment and Road-Map Planning

With the information model in hand, the process of aligning and anticipating business needs, evaluating the current state, articulating the vision, developing the road map, and leveraging every opportunity to advance the journey becomes simpler, more predictable, and repeatable.

Using a real case study and the previously described information model, let us walk through the process and develop an assessment and road map for BI.

Situation

Smart grids and smart appliances are changing the landscape in the utility industry. Depending upon the fluctuation in prices, customers might want to control their use of energy. This requires real-time pricing and usage analysis. Based on the customers’ thresholds, they control the appliances in real time. The business model of the utility industry is also evolving. Within a few years, utility customers could become suppliers by establishing their own solar power–generation facilities. The utility company in this study wanted to ensure that its BI efforts were designed to meet future challenges and plan the BI architecture for the expected change in the industry.

Process and Deliverable

A simple five-step process and the information model produced the desired output:

Understand the strategic objectives—what is or could be driving the need for change. Through interviews, 10 significant initiatives or objectives were identified that addressed business, regulatory, and operational goals. These objectives required improvement in people, process, and information capabilities; as such, the case study will focus on BI-related capabilities.
Identify the required business infrastructure.Evaluating an individual business process can be very time- consuming. Also, the overall scope and objective of each strategic initiative is not always clear. Therefore, instead of analyzing various business processes, the focus is to understand the maturity of business-infrastructure capabilities in support of the strategic initiatives. Figure 3 shows the number of strategic initiatives or objectives that are enabled by each business-infrastructure capability. This mapping identified the top business capabilities that the organization must explore and understand for the current and desired levels of maturity.
Identify and evaluate required business-infrastructure capabilities. Using the capability-maturity model, the current state was assessed, and the desired state of business-infrastructure capabilities that are needed to achieve the stated strategic objectives was articulated. (See Figure 3 for a visual representation of the current and desired maturity levels.) The analysis focused on the capabilities that had the greatest impact on strategic objectives and the largest relative gaps between the current and desired states of capability maturity.

Figure 3. Business-capability alignment and maturity (Click on the picture for a larger image)
Identify and evaluate required technical BI capabilities. Using the predefined relationship map between business infrastructure and technical capabilities, the relevant technical capabilities were identified and evaluated. Using the maturity model and knowing the desired state of the business capabilities, the maturity map for the technical capabilities was developed (see Figure 4)

Figure 4. BI-capability maturity (Click on the picture for a larger image)
Develop the road map for realizing the vision.Based on the business priorities, current and planned projects, and dependencies between various capabilities, a statement of direction was established. The projects and capabilities delivered by these projects were organized along the four BI Services domains in short-term, near-term and long-term time horizons. The road map was not about building future capabilities today. It emphasized beginning with the end in mind by architecting current capabilities such that new capabilities can be introduced cost-effectively when needed.

Using the knowledge of the maturity map of both business and BI capabilities, the current and desired states of these capabilities, and the statement of direction, the organization is also able to plan and execute each new initiative or project—ensuring that every investment results in another step in the right direction.

Access to the Model

Microsoft has embodied the model that is presented in this article, along with a structured approach for developing BI strategy, in a service offering that is called Assessment and Road Map for Business Intelligence. Using this service, an organization can gain access to the model, obtain additional knowledge, and develop its first BI strategy by using the model.

Conclusion

If an IT organization wants to create possibilities or “happy surprises” for the business, it has to change its mindset and execution from “think locally, act locally” to “think locally, act globally.” BI as a platform service will help organizations deliver a consistent BI experience while it maximizes ROI. Business infrastructure will help business stakeholders and users to understand the business commonalities and IT organizations to anticipate the business needs and plan the BI road map. Together with business infrastructure and BI platform, organizations not only can gain business insight, but also can act upon it.

References

Kumar, Dinesh. “IT Service Architecture Planning and Management.” U.S. Patent Pending. December 2007.
Ross, Jeanne W., Peter Weill, and David C. Robertson. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston, MA: Harvard Business School Press, 2006.
Sykes, Martin, and Brad Clayton. “Surviving Turbulent Times: Prioritizing IT Initiatives Using Business Architecture.” The Architecture Journal, June 2009. http://msdn.microsoft.com/en-us/architecture/aa902621.aspx.
Microsoft TechNet. Microsoft Infrastructure Optimization (IO) Model. Available at http://www.microsoft.com/io.
Microsoft Services. Microsoft Assessment and Road Map for Business Intelligence. Available at http://www.microsoft.com/microsoftservices/en/us/bpio_bi.aspx.

Acknowledgements

Special thanks to Tom Freeman, Geoff Brock, and Brant Zwiefel from Microsoft Services for their candid feedback and thorough reviews of the draft.

About the Author

Dinesh Kumar (dineshk@microsoft.com) is a Principal Architect who focuses on enterprise architecture and IT planning. His recent research focuses on understanding business needs, planning, optimizing, and managing IT as a service organization. Dinesh serves as co-chair of the enterprise-architecture working group at Innovation Value Institute. He is also on the CIO advisory board for MISQ Executive, a SIM publication.

Follow up on this topic

MS Business Intelligence: http://www.microsoft.com/bi/

Rate this content

Issue 22 Index

BI Videos

Anatomy of a Failure: 10 “Easy”

Ways to Fail a BI Project

Ciprian Jichici

In the past 10 years, business intelligence (BI) has gone through the typical journey of a “hot” technology. It started with the mystery of the first implementations, fresh out of the academic world; went through the buzzword stage; and ended up in the technological mainstream. Next to this horizontal evolution, there has been a vertical one, in which BI has descended from the top of the organization to the masses and begun addressing a much broader set of business needs.

Regardless of the phases through which it has gone, BI has been—and, some argue, still is—an architectural challenge. In real life, BI architects have to deal with multiple technologies, platforms, and sources of data. Today, we do have some kind of architectural guidance for most of the components that play together in complex BI solutions.

Yet we still lack the proper architectural guidance on the complicated topic of being successful in making them play nicely together. Finally, the success equation of a BI project has one more key element—people—who are tightly connected to processes and culture.

From an architectural point of view, three of the most common reasons for failure are the inability to recognize that BI needs consistent architectural planning; unfortunate selection of technologies; and over-focusing on technological issues (such as performance and data volumes) too early in the process. When it comes to data, failure to reveal relevant information and granularity mismatch (together with poor query response times) are two of the “easy” ways to derail a BI project.

But perhaps the number-one reason for failure that is related to data is assuming that BI is synonymous with having a data warehouse. Finally, from a person’s point of view, failing a BI project is as easy as assuming that end users have the know-how to use the tools; not getting them the appropriate levels of detail; and, of course, going over budget (which, oddly enough, occurs many times as a result of previous success).

It is safe to say that it is quite difficult to get BI right and quite easy to get it wrong. To summarize the preceding, the easiest way to fail your BI project is probably a “first build the plant, then decide what to manufacture” approach.

Ciprian Jichici is participating in the Microsoft Regional Directors Program as a Regional Director for Romania. Since 2003, he has been involved in many BI projects, workshops, and presentations. You can read an extended version of the preceding article at http://www.ciprianjichici.ro.

Advertise Here