By Mark Torr and Diane Hatcher
Whether you’re using one, two or all five business analytics approaches, the technologies are capable of much more than the delivery of reports.
The focus of most organisations for the last 10 years has been on creating data warehouses to bring together widespread, disparate data so that it can be augmented, cleansed and distributed through reports that use simple, descriptive statistics. Reporting has evolved to allow people to interactively navigate, visualise and find patterns in data. This evolution includes self-service access to information and is driven by a hunger for information that shows no signs of diminishing. Meeting this growing information demand is an ongoing challenge.
Today, there is an additional architectural consideration – the need to enable automated or semi-automated decision making within business processes. In these cases, the architecture must support not just human decision making but also provide information to downstream operational systems or customer touch points. Simply put, the objective of business analytics is to support better decisions in your organisation.
There are essentially five styles of business analytics that are being embraced by organisations in all industries. No matter which style(s) you use today, consider the other styles when planning architectural changes to meet future business and IT needs. For example, an emerging requirement is big data, driving a need for more performant analytics, which in turn leads to the need for more automation and intelligence in decision making. These styles can affect your needs at the business, application, data and technical levels. Assessing your required styles of business analytics will be valuable when making any changes to your architecture.
[ms-protect-content id=”9932″]
1) Classic business analytics
Provisioning a system to support query and reporting is classic business analytics. This basic level of data sourcing can include a data mart, warehouse, or predictive analytics surfaced via reporting interfaces. It provides information via data exploration or predictive analytics techniques and shares generated reports to users at various organisational levels. Traditional report-driven BI processes leave the user to make sense of the situational context and the information’s effect on the business process, meaning execution lies in the hands of the receiver and how he or she interprets the information. Such reporting helps decision making, particularly if it provides backward-looking and forward-looking information, but ultimately 3 different people can make 3 different decisions.
A change is occurring in the traditional information distribution method. Static reports are not enough to support decision making. Now, information must be communicated across more channels. Printed reports are no longer the norm even though they remain important. Business stakeholders need timely information within the context of their day-to-day operations – even when they are on the move – and it should be self-service. Users want to interact with what they see. They want information delivered via e-mail, portals, dashboards and mobile devices. This means providing dynamic access to information with the ability to refine questions, drill into more detail or visualise in a different manner.
The processes for generating the information have stayed the same, but the distribution methods have diversified based on users’ preferences. Now, information must be communicated across more channels (e.g. email, portals dashboards and mobile devices) and should be self-service and interactive. This means providing dynamic access to information with the ability to refine questions, drill into more detail or visualise in a different manner.
Architecturally, this means having architecture building blocks of data management, reporting and analytics that work together when deployed with a broad range of capabilities.
2) Classic business analytics with data quality
This style is similar to classic business analytics except that it recognises the need to cleanse the sourced data. It integrates data quality into the data sourcing or data input process. Driven by the need to increase the trust in information delivered to end users, another motivating factor to adopting this style can be regulatory requirements demanding cleansed and standardised data. Master data management initiatives are also becoming more ingrained into the data sourcing process.
Architecturally, this style still requires the building blocks of data management, analytics and reporting, but you need to embed data quality as part of your data integration capabilities as well.
3) Business analytics with feedback loops
Using business analytics for better decision making can also require the delivery of information to everyday operational applications for use within workflows at specific points in the business process.
The simplest way to embed business analytics into operational system workflows is to create a repeatable process that sources data, analyses it and then feeds the results back into the operational data store. During process development, basic reporting might be needed to check the result, and once the application is performing correctly, specific monitoring reports can be added.
In this closed-loop style, the business analytics engine sends back results to the underlying operational systems and processes them in the normal flow of business operations. It is possible to automate some of the workflow decisions by defining business rules; but in general, business stakeholders will use the information as recommendations to help them with their decision making. A key feature of this style is that information delivery always occurs at a precise point in a business process, and the information does not require a report format.
Business analytics with feedback loops supports cyclical business processes. For example, you might want to provide specific recommendations into a procurement workflow. On a weekly or biweekly basis, depending on the purchasing cycle, you would forecast sales of your inventory to determine what you need to replenish. In this scenario, data is extracted, cleansed, analysed using advanced forecasting techniques and then the business analytics engine feeds specific recommended purchase amounts back to the operational system. Business users can use the recommendations to better guide their procurement decisions. You could also use the recommendations to drive automated procurement processes with business rules to flag potential outliers requiring human attention.
Adding these feedback mechanisms changes the way IT must provide support as the business analytics process needs to be less linear in implementation. A closed-loop system should provide more circular support regarding sourcing, discovery and information sharing. Architecturally, all three must work together as a single composite service without the need for manual intervention or data movement.
4) Real-time business analytics
There are also situations when a specific service might need to be performed quickly to gather information, requiring real-time business analytics.
Real-time business analytics can aid decision making when operational systems support users in customer-facing situations and the customer is looking for a quick response. In this instance, technology does not replace human interaction. It supports the user through automated processes and by providing consistency. That technology can be a point-of-sale system, a customer service application or a kiosk. Each customer touch point represents an opportunity to make a real-time decision to create additional sales or reinforce behavior.
This approach requires triggering analytics or data collection and delivery in real-time from an application. Data is collected, along with existing information when required, and analysed. The results are sent to the original touch point for a decision or are put into an operational workflow driving automated decision making.
The hallmark of this style is that a user or system triggers the service after the collection of some information. The information could be gathered via a batch process or streamed back during the course of operations. In order to implement this style, the solution building blocks can be used individually or together to provide a well-defined service. The business analytics architecture should incorporate data sourcing, analytics and reporting as reusable services that can be integrated into manual human-driven processes or other more automated business processes.
5) Business activity monitoring
Many companies today have a host of operational systems that are critical for day-to-day operations. Automation is the standard, as human monitoring and decision making is impossible given the large number of possible events or transactions. One approach is to improve operational systems by monitoring key information and creating sets of business rules and triggers to send alerts that can drive downstream action. The scenarios supported here are more complex than the previous style and use business analytics in real time in combination with business rules. The triggers might not be based on a single event or request but on a series of events. Based on the nuances of those events, rules could dictate different reactions and different workflows.
Take, for example, the scenario of detecting credit card fraud. Rules exist to determine whether a transaction is approved, rejected or routed to a service agent to follow up with the cardholder. It is not just the single transaction that is considered but the pattern of behavior linked to the transaction that is important.
This style requires a services-oriented architecture to provide capabilities that can be plugged in as needed across various systems. Each element of your business analytics solution – within source, discover and share – should be a standalone service of its own and able to integrate with other services, and with other operational systems. Business rules determine which capability is needed and when. The goal is to deploy business analytics directly into the operational systems.
Considerations for business analytics architecture
Building a business analytics architecture to create a competitive advantage requires supporting multiple styles of deployment as the needs of the organisation change. Increasingly, organisations are realising that there are many opportunities within their business processes to either deliver intelligence that makes sense at specific points or to incorporate business analytics into operational systems and processes. No style is better than another, and your organisation may start with one style and either move to, or add support for, others. There is not a maturity curve because the choice depends on your organisational goals and needs.
It is important to note that each style has two aspects. One aspect is the development of content to support the decision-making process. This includes development and maintenance of master data repositories, data warehouses, data marts, models and reports. These business analytics assets must come first in order to support, test and measure. Across all five styles this development remains fairly constant.
The second aspect is the actual use of content to make decisions. Using these assets to make decisions could include using them in enterprise portals or production-level operational systems and may or may not involve the use of reports to deliver information. Increasingly, business analytics will occur in formats other than reports. Pervasive BI will not occur through the use of reports alone.
Another consideration is governance. Stockholders and regulatory agencies are demanding increasing levels of oversight into how decisions are made and their impact on the organisation’s success. Monitoring the state of your business analytics assets is needed to track the life cycles and effectiveness of your decision rules and models. Analytics Competency Centres are growing in importance to formally address these issues.
Questions you should ask during architecture planning:
• How are sourcing, discovery and sharing supported?
• Are these activities disconnected or integrated with a common purpose?
• Can we address all five styles of business analytics to make the best decisions with the building blocks we have today?
The solution building blocks in your technology framework must stay relevant as your architecture evolves; otherwise, you will be locked into an architecture that renders you unable to respond to the needs of the business. Decision-making processes are accelerating to meet quickly changing market requirements, such as the need to embrace big data.
Architecture building blocks for business analytics
Irrespective of the chosen styles, your business analytics architecture should be built around three core architecture building blocks to support sourcing, discovering and sharing business analytics across your organisation – data management, analytics and reporting.
These building blocks represent the foundational capabilities for your decision support requirements. Sourcing data for decision making, discovering information hidden in the data and sharing the results with the appropriate stakeholders represent distinct activities within the business analytics process, and they are required to work together to deliver the best results.
We are talking about more than just a framework for sourcing, discovering and sharing. You must also consider the robustness of the individual components, the quality of service they provide and their ability to integrate with each other.
Data management
For classic business analytics styles, the data management architecture block provides the capabilities for accessing data in an interactive way. The capabilities go beyond capturing operational data. They also encompass the requirements to surface the data for reporting, interactivity and analysis. The ability to consistently deliver data quickly in a usable format provides flexibility for when and how the data is consumed.
The components of data management could include high-performance capabilities for data connectivity, data quality, master data management, data extraction, transformation and loading, data migration, data synchronisation and data federation.
Your data management architecture should make use of all the data flowing into and through the organisation. Data is generated to support decision making and has an impact on results that need to captured, measured and fed back into the decision support process. Because data is being fed from all parts of the business for decision support, data management must be planned holistically. For example, if you can automatically integrate data profiling and data quality into standard data management processes, you have immediate access to data that fosters confidence and consistency.
For real-time business analytics and business activity monitoring, your data management block should be based on a service-oriented architecture. Data is collected at customer touch points and returned for real-time analysis and scoring, which in turns determines an offer or acceptance of a transaction. Additionally, data from monitoring operational system can be analysed in real time, and abnormal events can be detected to trigger a new flow of activities. Providing data capture and transportation as services provides a consistent method for data movement that can be used today and well into the future.
Analytics
The analytics architecture building block should provide the ability to support a range of business needs, including ad hoc, interactive and predictive analysis. In addition, you must consider the effectiveness of operational applications, based on historical trends and prediction of future outcomes that provide real-time input into the decision process. There are at least eight types of analytics to consider:
• Standard historical reports
• Ad hoc reports requested by the business
• Query drill-down (OLAP) to provide guided exploration of information
• Alerts to notify the business when specific events are detected
• Statistical analysis to determine why things are happening
• Forecasting what will happen if trends continue
• Predictive modeling to determine what will happen next
• Optimisation of business processes to accomplish goals
For simple business problems, the first four types could be all you need. But if you need to ask more complex questions or look for predictive insight, you need to consider the last four. If you use these technologies together and identify what type of analytics you need, then your business analytics architecture will generate true value.
Another important consideration is the analytics development and deployment environment. A disciplined approach for managing the analytics portfolio provides appropriate oversight and operational rigor. This encompasses defining the business problem, developing the appropriate models, deploying the models into production and tracking performance. Each of these steps requires due diligence and standardised methodologies to deliver appropriate results.
As the decision-making process gets pushed out closer to the customer, it is also important to move analytic capabilities closer to the customer. This means being able to deploy business analytics directly into front-line systems. In these scenarios, the elimination of I/O to pass information across systems represents huge performance gains, enabling real-time analytical processing. You can take this even further by embedding analytic processing inside the database engine – further blurring the lines between sourcing, discovery and sharing to the benefit of performance and scalability.
Reporting
Reporting itself has evolved beyond querying data and has moved toward interactivity and more specific visualisations. The capabilities provided by the reporting architecture building block should include business stakeholder requirements for self-sufficient decision making. Stakeholders should be able to ask questions, receive an answer that makes sense to them and be able to act upon that information without IT involvement.
This means that presentation and channels are important as more and more information is shared via electronic means such as portals, RSS feeds and email.
It is not enough to present a library of standard, tabular reports. Quickly sorting the information to get a few key performance indicators in a visual dashboard represents just an example of the latest technologies that users are demanding. Reporting has grown to imply formatted output, usually showing tables and/or graphs; but at its core, a report is really just a statement describing an event or situation. That information can be shared in a formatted report to business users to help put that information into an appropriate context; or it can be shared with operational systems to support decision making on the front lines. It could be part of a customer profile, or a decision in a customer-facing application. It is important to consider all ways that reports are communicated across your organisation.
Discover, source and share
Regardless of the size, industry or goals of your organisation, the architecture required for business analytics is essentially the same. The important activities are sourcing the data, discovering what the data is telling you, and sharing the information to the appropriate decision makers.
Therefore, the architecture building blocks you need are based on providing capabilities for data management, analytics and reporting. Once deployed, your solution building blocks should work together, using a common set of services and clients to provide consistency, re-use and self-sufficiency. The ultimate goal is to support better decisions in your organisation.
About the author
Mark Torr, Director Technology Practice, SAS
As Director of SAS’ Technology Practice, Mark Torr leads business development and sales support in the EMEA region and pre-sales enablement globally, managing a distributed team of domain experts in the fields of data management, Analytics, reporting and architecture.
Torr supports customers in multiple industries across the EMEA region frequently meeting with C-Level, enterprise architects and SAS users at customer sites. He also speaks on a wide variety of topics at SAS and external conferences. In his global role he is responsible for the collecting, creating, packaging and disseminating best practice as well as ensuring that sales and pre-sales have the resources they need to succeed in a variety of industries.
Diane Hatcher, Architecture Design Manager, Global Market and Channel Development, SAS
Diane Hatcher has been at SAS since 2001, where she is currently an Architecture Design Manager in the Global Alliances Division. In this role, she focuses on discussing SAS Business Analytics and architecture with customers and partners, helping them to understand how to best implement SAS software and derive value from it. She has a keen interest in the areas of business analytics, big data, visualisation, cloud computing.
Previously, Diane helped to drive the development of the platform infrastructure for the SAS 9 Business Analytics Framework, as the Product Manager for Metadata, security, Integration Technologies, Query Services, SAS Management Console, and Information Map Studio.
[/ms-protect-content]
