Building an Analytics Ecosystem to help the business and change the image of IT...

I recently attended a large family holiday gathering and as per usual, those relegated to the “kids’ table” joked about forever carrying the image of “kids” despite all of them being adults.  It reminded me of something I’ve previously mentioned where some CIOs struggle for a seat at the executive table, seeming to forever carry the image of “techies” rather than business leaders.  I actually think it might be easier to alter the “techie” image than it is to graduate from the kids’ to the adults’ table because despite having my own children, I still sometimes find myself at the kids’ table. Yet, I’ve helped several CIOs move from the “techie” to the business leader table.

In addition to the ideas mentioned in that previous blog article, I think working with business leaders to create an analytics ecosystem and roadmap is an excellent way for CIOs to develop their business leader street creds.  To get started, if you don’t have a working knowledge of the various analytics categories, I recommend reading a book such as, “Big Data Analytics Infrastructure for Dummies.”

There are four basic types of analytics, each appropriate for different business uses and each using different tool sets.  Building an effective ecosystem and realistic roadmap requires understanding these business uses.

Four Basic Types of Analytics

1. Descriptive:

•       Used to provide basic statistics such as averages, totals, frequencies, causal relationship

•       Probably the most commonly used type of analytics done today

2. Predictive:

•       Helps see what the future may bring by using statistical models

•       Helps forecasts future revenue, profits, or operational outcome by modeling relationships between variables

•       Mostly used for planning

3. Prescriptive:

•       Optimizes predictive analytics scenarios for the best future outcome

•       Considers new inputs or constraints specific to a given situation

•       Recommends actions

•       Used for tactical planning

4. Cognitive:

•       Uses techniques and a high-performance infrastructure to identify non-intuitive relationships

•       Typically analyzes diverse sets of data

•       Often used for break-through ideas

Regardless of the type of analysis, the speed to gaining insight from data is the key to business impact.  It can mean the difference between leading and following in an industry.  Therefore, don't underestimate the business value of having systems, storage and databases that work well together as a team.  However, let's not dive into important nuances of technical solutions but return to discussing the business.

Most C-level executives have multiple analytics requirements.  For example Marketing typically wants analytics to help with client segmentation, understanding client sentiment and reducing client churn.  Finance wants help with planning and forecasting, automating financial and management reporting and improving visibility, insight and control.  Meanwhile, Risk needs analytics to improve risk-awareness in decision-making, manage financial and operational risks and reduce compliance costs.  And Operations might use analytics to optimize the supply chain, deploy predictive maintenance processes and improve fraud identification processes.

  

Often those executives will each buy niche solutions to help them answer their specific questions.  The result is a disconnected set of tools, capable of addressing a myriad of pin-point business questions but that yields sub-optimal business insight because the toolset fails to connect insights across business units. For example, analytical insights in risk management can and should improve insights in financial management, marketing and operations and vice versa.  But unless those analytics solutions were architected and designed for integration, chances are low that they will work well together.

The CIO can provide tremendous business value in this area because the CIO sees across all parts of the business and sees potential integration points between different groups.  The CIO probably is in the best position to gather the full spectrum of analytics requirements, help prioritize them and order their implementation schedules according to business impact, and then build an integrated analytics ecosystem to manage, integrate, govern and analyze data in the most effective way for the business.  This feat alone often earns a CIO the right to move from the techie to the business table. 

If you’d like help planning your approach to building an integrated analytics ecosystem, feel free to contact me.  Unfortunately, if you’re looking for help strategizing how to move from the little kids’ to the adults’ table at your next family holiday gathering, I’m probably not going to be much help.  I’m still trying to figure that one out myself.

Parting the clouds: tips for creating your enterprise cloud strategy...

I’ve been helping CIOs with their Cloud Computing strategies for over 5 years.  The least successful strategies seem to position cloud as simply an IT budget slashing mechanism.  The most successful strategies position cloud as an enabler to doing things within the business that otherwise would be impossible. 

An industry statistic says that 65% of cloud investment decisions are being made by C-suite business executives without any IT involvement.  They are making those choices based upon business requirements and the promise of how cloud can help meet them.  These decision-makers are looking at things like collaboration capabilities and business agility that cloud enables, not the intricate technical terminology or functionality.

Yet, I think the IT organization plays an essential role in guiding the cloud strategy.  As technologists and engineers, we are professional problem solvers but we’re also pretty good at problem deterrence.  Cloud provides powerful capabilities but it is not the answer to everything.  As a matter of fact, I usually say that cloud is not the solution to anything; it enables solutions.  Regardless, when deployed in a sub-optimal way, cloud-based solutions can actually introduce risks, exposures or even increase business expenses. 

The technology behind cloud is like the themes from my favorite children’s television shows; it’s about sharing and collaboration – just with a whole lot of automation.  However, all this sharing should occur with a healthy dose of “stranger danger” akin to what we teach our kids.  Not everything should be shared with everyone.

The resources shared in a cloud differ based upon model.  There is Infrastructure as a Service (IaaS) which shares physical assets, Platform as a Service (PaaS) which shares environments, Software as a Service (SaaS) which shares software solutions and Business Process as a Service (BPaaS) which shares the full business process.  Each cloud model can be deployed in private, public or hybrid clouds…on-premises or off-premises.

Yet, somewhere underneath each PaaS, SaaS and BPaaS solution sits IaaS.  It’s just that in some cloud models, somebody else worries about the daily operations associated with the Infrastructure.  But, do not be lulled into indifference... Whether public or private, on-prem or off, the underlying cloud infrastructure is ultimately your concern because of the business implications that can arise from faulty cloud infrastructure.

A single client can and often does deploy multiple cloud models within the enterprise.  You want to avoid scatter-shod situations where business leaders buy something impulsively or in isolation, and then toss it over a fence to you in IT to make it work.  Rather, you want to guide the business to create a comprehensive, integrated, enterprise cloud strategy.

The first step is to assemble the team: 1) visionary business leaders to set direction and overall guidelines, 2) business and technical analysts to help guide the strategy, and 3) financial and operations experts to deal with the practicalities of accounting, procurement and operations.

I recommend using the “Practical Guide to Cloud Computing – v2.0”: published in April 2014 by the Cloud Standards Customer Council.  Here’s a summary of strategic planning steps from that document modified with some of my thoughts:

1.  Educate the team: IT and business people need to understand what cloud is and what it can do as well as the various models.
2. Understand the current business and IT environment: Cloud does not happen in a technology vacuum so it is important to understand the current state of both business and IT so that the integration piece is not overlooked in the strategic planning.  Integration often provides some of the most profound benefits from a cloud-based solution.
3. Understand what the business needs and why: This requires creating the business case for the cloud-based solution.
4. Think long-term and enterprise-wide: Don’t just address one business problem or opportunity; look at several business uses for cloud; create a prioritized roadmap.
5. Crunch numbers: look at all the costs of implementing cloud and migrating the workload to it; model multiple scenarios.
6. Don’t break things: Do an impact analysis to ensure that availability, performance, security, privacy, governmental regulations and internal auditing requirements are addressed.
7. Set goals and milestones: Get executive buy-in on metrics; set metrics keeping in mind this is a long-term, multi-stepped roadmap; don’t set milestones so far apart that the stakeholders lose interest or confidence that this will deliver business benefits.
8. Understand legal and regulatory implications: cloud-based sharing and sourcing often involves multiple companies and/or countries; it’s essential to understand national and supranational regulatory bodies and compliance mechanisms. 
9. Create your skills plan: what skills are needed, what skills can/should be developed in-house versus sourced externally?  What is the skill acquisition and enablement plan? Make it comprehensive including business people.  A lot of technically sound cloud-based solutions struggle to deliver business value because training business people on process changes did not occur.
10. Track results through the execution of the cloud roadmap: use trend information to adjust the roadmap; publish successes to build momentum.
11. Have a migration and exit process: When are the cloud-based solutions considered “deployed?”  What are the responsibilities during and after the migration of workloads into the cloud?  What are the service agreements and divisions of responsibility between the internal or external cloud service providers and the business consumer of the services?

 A few more key things to consider when developing your cloud strategy:

• Workloads: What workloads have an affinity for providing business benefit if deployed in a cloud model?
• Data: Where should the data reside?
• Integration: What else do you have to integrate this with?
• Governance: What are our new decision-making processes regarding the workloads and data?  This involves security considerations too.
• Control: How do we make sure our policies are followed so we don’t have exposures?  This also involves security.

I mentioned in an earlier blog article that many CIOs struggle for a seat at the table with the other C-suite executives.  Often, introducing the idea of creating an enterprise cloud strategy is a great way to earn a seat at the table.

Thoughts on Resilience

Global enterprises are increasingly vulnerable to disruptions of different kinds. Though they can’t stop many of these disruptions, with adequate planning they can make their organizations resilient. For regulated industries such as banking and finance having massive business impact due to disruptions, business resilience capability is of utmost importance.  For this reason, multiple U.S. governmental agencies published an interagency paper on sound practices to strengthen the resilience of the U. S. financial system, http://www.sec.gov/news/studies/34-47638.htm. This paper suggested that an enterprise’s board of directors should review business continuity strategies to ensure that plans support the firm’s overall business objectives and risk management strategies. Regulators also want banks to provide safe, secure, sound, efficient, accessible and resilient services.

Recognizing this significant evolution, IBM created the Resilience Maturity Assessment Framework (RMAF) to help institutions determine their preparedness. This framework is based on quantifying the business resilience as an index to measure and improve it further. The quantification includes key resiliency aspects that are meaningful to businesses. While RMAF provides a strong basis and broad coverage, we are always considering further enhancements to keep it relevant.

Business resilience assessments of some sort should be done proactively and periodically to ensure resiliency capabilities improve and are aligned with changing market dynamics and regulations. I recommend starting with a limited assessment scope, in order to realize rapid improvements.  For example, banks could focus on one or two massive-impact business processes or an associated business unit rather than a bunch of processes or a large organization. Payments, internet banking, ATM, POS, integrated core banking services, card issuance and management, and mobile services are examples of bank business processes.

In IBM’s assessment methodology, we consider six layers:

1)      Business / IT processes

2)      Applications

3)      Data

4)      Technology

5)      Facilities

6)      People

To calculate an organization’s resilience, we develop a resilience model by identifying components. For example, common components of a typical payment process could be payment application, server, storage and data/voice networks, email, Data center (DC), offices, IT service management (ITSM) processes and people. Each component has one or more attributes which describe various capabilities of the component.

IBM’s methodology also considers substitution and dependency relationships amongst components to arrive at a more realistic resiliency model and an improved Resilience Maturity Index (RMI)⁺. For example an email component depends on the network component while the primary data center (DC) can be substituted by the secondary DC during disruptions. Furthermore, substitution is always qualified with the degree of substitution.

Once components, attributes and relationships are identified, the resilience model is complete and attributes are given a score between 1 and 5 based on standard maturity definitions. Raw component scores and rationalized component scores are calculated.  The rationalized score takes into account factors like substitution (increases a component’s raw score) and dependency (decreases the raw score). Eventually, all component scores are mathematically combined to give the organization’s overall RMI score.

The methodology also helps determine a component’s impact.  For example, if the overall score increases when an individual component’s score increases, then that component is said to have a higher impact on the organization’s resilience. This sensitivity analysis helps prioritize components, which is essential for prioritizing improvement actions and associated investments.  

End to end resiliency consideration, followed by resilience index determination, sensitivity analysis, improvement actions and then revising the index calculation form a continuous resilience improvement cycle. In addition to strengthening the enterprise’s resilience, this cycle helps document resilience capabilities in a way that can be reviewed by the board or regulators.

For more information on the Resilience Maturity Index, feel free to contact me at sambath.narayanan@in.ibm.com.

Many thanks to my guest contributor: Dr. Sambath Parthasarathy, an executive consultant in IBM’s Systems and Technology Group Lab Services organization

⁺RMI is a patent pending innovation from IBM Research