Successful data-driven operations follow the business intelligence lifecycle, define BI competency, and implement a well-understood and governed architecture.
The process starts with the premise that you must incrementally build BI competency and a corresponding architecture one project at a time. In an iterative approach, you don't need to design and deploy the architecture upfront. It continually matures to deliver sets of BI capabilities. With each new capability, the architecture evolves and expands in a coordinated, business-driven manner.
A business intelligence lifecycle is a methodology for developing architecture that increases the probability of success. Use the following steps to build a successful BI architecture. Temper all decisions with the goal of delivering incremental business value while minimizing cost, redundancy and complexity.
Steps of the business intelligence lifecycle
1. Build a business case
A business case justifies architecture investment. Given that BI is a business initiative, not a technical exercise, business cases focus on BI capabilities and how they enable your business strategy. The architecture is a necessary investment to realize benefits and value.
The first step is to meet with senior business leaders, including the business sponsor, to understand strategic business goals, success metrics and the benefits of improved access to information. Even if meetings happen at a program level, it is advisable to reaffirm along the way because businesses evolve and priorities change. An executive view can provide macro-level, value-based priorities that drive the selection of a discrete business process with a defined scope.
After selecting a project, build a business case demonstrating clear business value and a favorable ROI. Value metrics justify the need for BI capabilities and architecture.
The five steps of the business intelligence lifecycle.
2. Gather requirements
BI is a partnership between a variety of stakeholders. The collective functional and non-functional requirements should define the project scope at a detailed level and set the foundation for the architecture. You must start with an understanding of your business processes and which KPIs you want to track. Also consider who will use the BI tools; what insights they need; and the frequency, quality and format of information they need.
Technology can translate functional requirements into non-functional technical requirements and perform preliminary assessments. A preliminary technology assessment should determine the feasibility of the foreseeable architecture. A data assessment should determine if data is available and of sufficient quality to support business requirements.
Compliance, security and privacy guidelines dictate the requirements for regulatory data access and sharing.
3. Create the architecture
BI requires an architecture that serves as a blueprint for delivering analytics. The architecture provides an efficient reference framework for transforming data into actionable insights by improving information access. Spend time to sufficiently document the architecture with traceability back to business requirements.
Align the technology design to your desired business capabilities by mapping business requirements to technology components. Break the architecture into three parallel tracks -- technology, data and applications -- and use previously built, shared and reusable architecture components.
The technology track includes platforms, products, services, standards, patterns and best practices for data management and information delivery. It should cover the processes for preparing and presenting raw, refined and aggregated data for end-user consumption.
The data track includes data profiling, modeling and metadata. Profiling involves determining the quality of business data using the dimensions of data quality. Modeling involves organizing data with respect to the business process for intuitive consumption. Metadata involves information relating to architecture assets and operations.
The application track includes tactical and strategic intelligence capabilities for all users. Tactical applications are primarily day-to-day, operationally focused and business-process-oriented. Strategic applications are primarily long-term, big-picture analytics that cover a broad spectrum of past, present and future insights. Discovery is another aspect of applications, which is exploratory in nature and uses investigative inquiries to uncover insights.
Developing an architecture in phases risks the creation of fractured BI silos. Silos can increase costs, redundancy and complexity. Instead, you should build on a unified architecture with an enterprise mindset.
4. Communicate the architecture
Communication is often a standard project management function that is not given proper attention. Poorly communicated architecture introduces risk, jeopardizing the project. Architecture stands a better chance of acceptance and adherence if everyone shares it, understands it and uses it.
Develop a communication plan tailored to cross-functional stakeholders. Identify different audiences, and schedule regular meetings to target messaging as well as manage scope and value. Socializing the effect of BI and the role of the architecture reinforces the project need and justification.
Communication is often a standard project management function that is not given proper attention. A poorly communicated architecture introduces risk, jeopardizing the project.
For senior management, focus communication on the "why" of the project. The message should be clear: BI is a business imperative and requires a strong architecture. Highlight the effect of analytics on optimizing business processes as well as how a viable architecture is the backbone to improve operational efficiency and generate value.
For business practitioners, focus communication on the "what" of the project. The messaging should communicate BI capabilities throughout the business process and corresponding architecture. Highlight the architecture components users will interact with on a day-to-day basis.
For technology implementers, focus communication on the "how" of the project. The messaging should focus on designing and deploying a supporting architecture at a product level. Highlight the standards, patterns and best practices that deliver the architecture.
For all stakeholders, communicate clear service-level agreements and quality metrics to measure the architecture's role in delivering timely, consumable and actionable analytic capabilities.
Communication is not a one-and-done activity. It's an ongoing process to keep all parties informed of project activities.
5. Govern the architecture
Your business intelligence architecture will change because of many different factors:
Innovation.
Data accessibility.
New data sources.
New data ingestion patterns.
Increased user autonomy.
Technology advancements.
Data explosion.
Process optimization.
Cost reduction.
Automation opportunities.
Data distribution.
Multi-platform cloud and on-premises environments.
AI for augmented data management and analytics.
Overseeing a dynamic environment requires strong governance. Governance is a process that oversees the architecture across all aspects of a business process. Proper governance ensures the architecture is effective, consistent, compliant and aligned with BI strategy. A governance framework based on policies, procedures, standards and best practices defines the rules that govern the architecture across your organization, including people, processes and technologies.
It is essential to establish clear ownership of the architecture with defined roles and responsibilities. Stewardship responsibilities include accountability and continuous improvement to manage, monitor, measure and mature the architecture. You could establish a BI competency center to support and promote BI and architecture.
Understanding the business intelligence lifecycle ensures incremental business value by evolving architecture with each iteration of a business case. A good mantra is, "Think strategically and deliver tactically." The architecture, driven by business requirements, serves as a blueprint for delivering BI capabilities. Communicating and governing the architecture ensures stakeholders stay informed. Ultimately, improving your decision-makers' access to analytical insights determines the success of your architecture by increasing business value.
Jeff McCormick is an enterprise data architecture director and IT principal who has extensive experience in data-related IT roles. He is also an inventor, patent holder, freelance writer and industry presenter.
