A word on "Agile"

When I was a kid some people called me "agile" because I could sit straddled on the floor, reach forward and put my head on the ground, and stay there comfortably just like it was natural.  In my day, calling me "agile" was mild "hater-speak" for "It hurts me just to look at your contorted body."  But now, agile is an "in" term and with no connotations tied to "haters" unless we consider innovative geeks to be "haters."

In some circles agile is a way of life but amongst skeptics, it can inspire groans and rolled eyes.  Whoops, look who's talking like a "hater" now... but I digress.  

I will confess that I see value in agile methods, and no it's not so I can still be called "agile" though my current physical flexibility level declares victory if I can get on the floor and successfully get back up.  The first premise of agile is to slow down, have fewer works-in-progress so that you actually get more done.  So, what it actually connects with is my practical side.

To slow down and have fewer works-in-progress, you need to do solid strategy and planning to have a prioritized list of projects based upon their impact towards achieving your business goals.  Side note: If you struggle prioritizing your projects based upon their overall impact to business goals, I happen to know someone who writes a CIO blog and has filed for a patent on a methodology to do just that. 

This notion of prioritizing based upon business goals supports another premise of agile which is to start with the end in mind.  Again, it's about being practical.  Let's clear away the politics and emotion and focus on what we're trying to accomplish.

The list of projects forms the "backlog" or input queue that feeds the "scrum" process.  This is a process whereby the projects are subdivided into "sprints" typically tangible accomplishments that can be achieved in about 30 days.  This supports another premise of agile, in that perfection is the enemy of "good."  A series of vignettes released in shorter time spans usually results in more stuff getting done than if you wait to ship or use anything created until it's perfect.  It also tends to do two other things: feed the current "news feed" hunger for almost continuous stream of new things and raise team morale as the team sees tangible things steadily moving from the "to-do" to the "done" pile.

The process is a little like having a holiday cookie baking party.  You have one oven, limited baking utensils, a small team of helpers, many recipes/projects and it can be chaos unless you prioritize which recipes/projects are getting first dibs on mixing bowls and the oven.  You sub-divide your prioritized recipes into batches/"sprints" and each batch/sprint yields something tangible and useful and if it's cookies, probably even delicious. 

The process is very similar when using agile for any project; it's just that an agile development sprint is typically 30 days not 10-12 minutes like with a batch of cookies.

There's another aspect of agile that differs from the holiday cookie baking party in that sprints have daily "stand-ups."  The notion is that the daily status meeting is brief to the point it can be held standing up; hence, the name.  During the daily stand-ups, just ask three questions:

1. What did you do yesterday?
2. What will you do today?
3. What, if anything, is blocking you?

For folks who love hour or longer status meetings, this might shock your system.  But, most people I know eschew status meetings if at all possible.

Periodically the team has retrospective meetings to adapt the process if needed. They can also adapt the prioritization of projects based upon feedback and changing market dynamics.

Successful use of agile requires some foundational values: respect, trust, openness, and courage.  The focus shifts from tools and process to individuals and interactions, from mountains of documentation to living documents, from rigidly following "the plan" to agile adaptability to change.  And, thankfully, it does not require placing your head on the floor whilst doing the splits.  It's much simpler than that.  Give it a try.

What about the API Economy?

Do you find your head spinning at the emergence of the industry term, “API Economy?”   You might wonder what role your organization and company should play…once you figure out exactly what it is…

One definition comes from an IBM RedPiece entitled, “The Power of the API Economy.”

The API Economy is the commercial exchange of business functions, capabilities, or competencies as services using web application programming interfaces (APIs). APIs drive the digital economy and companies that do not embrace the API economy will be left behind.”

The API Economy is key to accelerating value, improving business performance, and extending your business services and goods to the widest possible audience. Making sure your company is easy to do business with and creating paths to new business opportunities is why the API Economy signals a new business reality. Companies that seize this opportunity will differentiate themselves and grow.

The way I explain the API economy is that the web and mobile computing make it very easy for businesses to share valuable components.  Application programming interfaces are somewhat like the doorway to using a component.  The components themselves can be data, logic or full services; they can be very small or large – just something that provides value to others.  Providing other institutions with access to these valuable assets can become a competitive differentiator, or provide a new source of revenue.  Consuming assets made available by other companies can accelerate innovation, again providing competitive differentiation.  Simply put, sometimes it’s better to buy than build.

Playing in the API Economy requires understanding what data, logic and services your company has that provide value to others, and also understanding what data, logic and services other companies have that provide value to your organization.  This determination does not happen effectively in a vacuum.  It must involve business leaders so that APIs offered and consumed align with the overall business strategy.

An analogy is that I make a really good potato salad.  If I offered access to my potato salad, other people could forget about searching for recipes, gathering ingredients and learning to make potato salad.  They would just use the API into my potato salad service, saving time and delivering really good potato salad whenever they needed it.  I would make money from no longer protecting my potato salad as a family exclusive offering but rather give many people access to my valuable potato salad assets.  However, offering my potato salad as an API based service does not make sense because I have no desire to enter the food service business – it doesn’t align with my business strategy.

Sometimes data, logic and services that your company wishes to offer into the API economy are tightly coupled in legacy solutions in a way that makes sharing them difficult.  The IT organization may need to undertake a de-coupling effort to separate user interfaces, data, storage, and business logic so even very granular sized assets can be made available.   This doesn’t mean an IT organization needs to re-engineer every asset.  Rather, any re-engineering efforts should occur aligned with business priorities associated with making the asset available for internal or external consumption.

Continuing the potato salad analogy – maybe someone really likes just my potato salad dressing and would like just that component.  If I wanted to offer my potato salad services, I might serve a larger market if I could de-couple some of the ingredients at a more granular level.  I might make much more money selling my potato salad dressing in addition to selling the fully integrated potato salad service.

This might sound like a daunting task when it’s your IT and business assets versus my potato salad recipe, but there are many software products and gateways that help make business assets accessible.  The place to start is not with the tooling but with understanding the business strategy and objectives as well as having an exploratory discussion regarding internal and external assets that should either be made accessible to others or that your company should start accessing.  Making the wrong assets accessible or accessing the wrong assets just helps accelerate doing the wrong thing for the business.  It’s better to use the agile concept of pausing to understand the highest priority assets to access and to make accessible, and keeping the works in progress to a small number during the re-engineering phase.

For the CIO, understanding what IT assets, business logic and business data exist is critical to entering the API Economy successfully. If your company plans to offer APIs versus just consuming them, then providing an infrastructure that supports unpredictable workload spikes without impacting performance is also extremely important.  The capability to measure and bill for API-based service consumption also needs to be established, unless your company sees value in offering API-based access to assets on a charitable basis. 

Hopefully if your head was spinning it no longer is regarding the definition of the “API Economy.”  Also, hopefully, you don’t see participating in the “API Economy” as a daunting effort.  Part of the “API Economy’s” beauty is the component-based approach, making use of other organizations’ good work versus requiring your organization to shoulder the majority of efforts. 

And if none of this makes sense but all this talk of potato salad is making you hungry, maybe just drop me a note to get my recipe….

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.