This is the last in a series of blogs where I have focused on how services may be utilized in different architectures. This last blog focuses on Business Intelligent (BI). Business Intelligence is a term used to describe the collection and analysis of information that helps businesses with decision making. Infrastructure supports BI initiatives by providing capabilities to manage, query, process, report, and display information in ways that decision makers can analyze and act upon.
A BI solution is one that provides information that enables users to make informed decisions. In its simplest form a BI solution might offer the ability to query records from an operational data store. This provides access to data but requires the end user to know what data to query, where the data are located, and how to interpret the results.
A more complete solution would abstract the user from the physical data sources, offer a logical unified view of data, provide powerful multidimensional query capabilities, alert users of events taking place, monitor key performance indicators, generate reports, and present information via multiple delivery channels. This not only adds value to the solution but makes it possible for users to acquire the greatest business intelligence with little or no understanding of all the complex technical underpinnings.
At a very high level, the BI solution breaks down into: systems where operational data are found, BI processing capabilities, desktop tools, and various forms of information presentation.
There are many links to SOA such as:
- Operational systems and data can be classified as existing IT assets, e.g. existing prior to the BI and SOA initiatives. Some of these assets may be service-enabled, offering the ability to access operational data as a SOA Service.
- The BI processing engine may access data through a variety of means including direct access to operational systems and data warehouses as well as SOA Services exposed via SOA infrastructure.
- BI capabilities may be accessed by business solutions that are service consumers. For example, BI portlets can be developed as presentation services and leveraged by multiple portal and dashboard applications. BI capabilities may also be accessed directly, without using a service-based interface.
The illustration does not draw a reference between SOA and the data warehouse. This is because data warehouses are generally populated via ETL processes, which are not a natural fit for SOA due to high data throughputs and low potential for reuse. Likewise data warehouses are not often exposed via services since the BI processing engines they are designed for can access them using means that are more efficient than typical service interfaces.
OK, that is it for this series. I had a reader ask me how do I identify services and how large or small should these services be. So I think my next series of blogs will focus on this.
Good Luck, Now Go Architect…
An Enterprise Architect's Musings 