5
analytics Make enterprise BI more responsive to change
analytics
Make enterprise BI more responsive to change
Three scenarios for Agile
Where not to use Agile
2
T he world is evolving swiftly. What was true yesterday may change today. The tremendous rate of business change
demands development processes that keep pace. Agile is a methodology that can help match the pace of change. Therefore, it is not surprising that a recent analyst study showed that over 76% of CIOs are expected to adopt Agile methods[ The Gartner Scenario for IT Service Providers : IT Services in a Digital Future]. Given the trend, can Agile in SAP BI be far behind?
Traditionally, projects in SAP BI have used the Waterfall method. This has led to increasing failure and user dissatisfaction. Reason: Collecting requirements, developing a data model, identifying and uploading data, developing BI objects and rolling out a finished product takes time and the process is unable to adjust to rapidly changing context and user needs. This is why the ‘First Time Right’ metric for BI has been low. BI projects have had time and cost over runs because they require a couple of iterations before they can become acceptable.
Agile, on the other hand, follows an iterative and evolutionary approach, building incrementally in 4 week cycles –or ‘sprints’—by breaking down projects into disparate modules/ functionalities. This means project scope can be modified during development, resulting in a better end product.
The advantages of Agile are clear. Development is adaptive and aligned to current business needs, providing a faster route to real value while eliminating waste (in terms of time, effort and budgets). In a majority of the instances, Agile methodology also means smaller development teams (read: easier to assemble, easier to manage). But, there are limitations too. Two critical issues need to be recognized. First, Agile is unsuitable for complex development that requires integration with multiple systems; and second, it can present frustratingly technical challenges with the need to reload large data volumes.
• New Report Development
• Changes in existing report – by making a copy of it
• SAP BusinessObjects Web Intelligence (BO Webi)/ Visualization/ Dashboard reports
A recent analyst study showed that
over 76% of CIOs are expected to
adopt Agile methods
For the first two scenarios, either existing data models should be used or a new data model can be used so that data load does not impact existing models/reports. While using existing data model, minimal changes can be made in the data model (example: Navigational attribute enablement which does not require data reload).
For the third scenario, build efforts can be comparatively higher than Business Explorer (BEx) reports. SAP BO reports are mostly new for business user and difficult to visualize. This is where Agile methods can step in and help business with visualizing representations and other features while minimizing rebuild efforts.
Agile methodology is not suitable for technical projects (patching/ upgrade) where new business functionality/ reports are not added. It is also not suitable for complex development that needs integration with multiple source system where changes are required in the source system. Neither is it suitable when changes are called for in the existing data model and which require reload of data/re initialization of delta. Such changes have a business impact as existing reports become unavailable during data reloads.
Which brings up a natural question: When is Agile best for SAP BI deployment? We suggest three ideal scenarios:
3
Getting the methodology right
Mitigate risk – build successSome risk mitigation measures are strongly recommended. Ensure that testing as part of the change process is comprehensively followed (including regression and performance testing). No business users should be able to run the report – the report should be accessible only to the project team. The actual report should be run in a controlled manner during periods of low business activity with a time out setting that prevents long running reports from adversely impacting production. Functionality and configuration can be added, not replaced or deleted. This is meant to prevents unintended regressive impact. And finally, report iterations should be capped based on simple, medium or high complexity of the reports being developed. These should be agreed upon with the business team as part of the planning exercise.Following these simple guidelines, an iterative Agile methodology can be used to ensure business and IT work together towards a common goal. The outcome is bound to be business-aligned SAP BI at reduced cost and with improved reliability.
Perform an assessment during Scoping and Planning about utilizing Agile based on the defined scenarios
Use the BAU approach to allow Agile delivery of the BI Reports into production landscape, using iterative BI cycles to refine requirements (iterations should be finite depending on report complexity – simple, medium or high)
All reports to follow BAU rigour such as regression and performance impact analysis with Unit, Informal and Formal Tests before moving into production
scoping & planning
yes
no
assessment for agile
iterative BI cycle
business sign off
alignment to release when part of a project/rollout
detail design
build & unit test
informal test
overall design
Review With
buisness
formal test UAT cutover
to prod
I The Gartner Scenario for IT Service Providers : IT Services in a Digital Future
The key is to get the SAP BI deployment methodology right. Here is a suggested approach (see Figure 1 for details):
Reports in production are not directly available to business user, hence they can only be run by the project team along with business users to validate it. The business verifies the report from an accuracy, look, feel and performance perspective prior to entry into Formal test (see Figure 1). The BI documentation and change control are kept open during the iteration.
Documentation is completed before entry into Formal test. Formal testing for the reports, as part of a release, will align with the formal test phase for the release.
Figure 1 SAP Bi Deployment Methdology-Suggested Approach
Transport to Prod
Report Design
Build
Test
Sangita Kumari A well-rounded SAP
Architect/Consultant with experience in creating
BI/BW/HANA solutions for a range of industries
such as Retail, Manufacturing, Energy and
Utilities, Healthcare and Life Science; Managed
technology and people for both Start-ups and
Fortune 500 companies. Responsible for all
aspects of software-based product’s life cycle
from concept to delivery.
Sangita Kumari SAP Architect/Consultant
About the author
4
IND/BRD/JUL 2017-JUN 2018
Wipro LimitedDoddakannelli, Sarjapur Road,
Bangalore-560 035,
India
Tel: +91 (80) 2844 0011
Fax: +91 (80) 2844 0256
wipro.com
Wipro Limited (NYSE: WIT,
BSE: 507685, NSE: WIPRO) is
a leading global information
technology, consulting and
business process services
company. We harness the
power of cognitive computing,
hyper-automation, robotics,
cloud, analytics and emerging
technologies to help our
clients adapt to the digital
world and make them
successful. A company
recognized globally for its
comprehensive portfolio of
services, strong commitment
to sustainability and good
corporate citizenship, we
have a dedicated workforce of
over 170,000, serving clients
across six continents.
Together, we discover ideas
and connect the dots to
build a better and a bold
new future.
For more information,
please write to us at
