Tuesday, January 27, 2015

Who Owns DevOps???

An agile development team is humming along, maturing its practice, putting out regularly scheduled application releases, improving quality, and making business users happy. Then, something happens. Maybe the infrastructure needs an upgrade or needs to scale. Maybe there is a difficult to diagnose performance issue. Or maybe, the business and development teams are looking to deploy a new enterprise application to support a new capability.

The Development and Operations Clash

When any of these scenarios occur, the question is whether or nor the Operations teams are ready to partner with Dev on the timing, complexity, or scale of the task at hand. When there is a mismatch in culture, values, methodology, timing, skills, or operational practices, a classic Dev Ops clash arises. Finger pointing, bottlenecks, anger, or isolation may form between the IT Development and Operational teams.

It's not just business or development driven needs and issues that can drive this rift. Perhaps Dev is pushing changes and breaking operational procedures. Maybe there is a mismatch between an application and a required systems upgrade that's holding back Ops from maintaining an environment. Or maybe Dev isn't as good as they think they are in releasing defect free, secure, high reliability, applications that perform well and Ops is left holding the bag.

DevOps to the Rescue

In my last post, I covered the What, Why and How of implementing DevOps. The basic technical concept is that as you automate more of the interactions with the infrastructure from building, testing, deploying and monitoring you can remove many operational defects and better align Dev and Ops processes. From a practice point of you, the big questions are what tools and to what degree to invest developing any single DevOps practice area.

Who Implements DevOps

When I've discussed DevOps with colleagues, other CIOs, DevOps experienced practitioners, developers and with system engineers the big divide around it is who "owns" DevOps.
  • Does the DevOps starting spark come from Dev encroaching into Ops responsibilities? 
  • Is it Ops who standardizes configurations and pushes Dev to align their development and release practices? 
  • Or is it better to reorganize into a single DevOps team that collectively owns this practice and its maturity?

I'm not sure if there is a consensus best practice on this question but it certainly is one of the more heated topics around DevOps.

While all will acknowledge that DevOps requires a culture change there is some debate on who should take ownership and how to align the IT organization to achieve business and operational benefits.

I feel very strongly on this subject and will provide my perspective over the next 2-3 posts. Sorry for the cliffhanger folks. But here's a hint. Like all practices, how you go about changing to a DevOps practice depends on the goals, the issues, the opportunities, the availability of talent, and what resources are needed on other business priorities. This transformation has to fit the organization and I suspect most would benefit by documenting current processes and capturing metrics before jumping into the who, and how of DevOps. 

So before I get to some answers, start by collecting some metrics.
continue reading "Who Owns DevOps???"

Tuesday, January 20, 2015

The What, Why, and How of DevOps

I learned much about what I know today about systems operations from Bill, a head of network engineering that I hired for my SaaS company about fifteen years ago. We already built separate systems for managing dev and test from production, matured source code controls, and implemented some automation around testing and deployment. What Bill taught me is that we needed to separate developers from production environments because it required a different mindset, tools, and practices in order to keep production environments stable and scalable.

He was right. After removing access, instrumenting some basic change control practices, and improving monitoring of our systems we saw better stability and performance. We also saw better developer productivity largely because they were now more focused on development tasks and less on operations. There was some grumbling about procedures and some finger pointing when things went wrong, but as the CTO I accepted most of it since the teams behaved well most of the time and there was measurable improvements in both Dev and Ops.

Today's DevOps

Flash forward to today, and many of the tools and practices Bill instituted have matured and are core elements of a "DevOps" practice. Since many production environments are now in the cloud or virtual hosts and can grow to thousands and tens of thousands of servers, the operational focus of the practice is on automation. Specifically:

  • Configuration management tools store infrastructure configurations in a database and also help automate setup and integration.  New server, install application, add storage are all operations that can be automated.
  • Code deployment tools integrated with configuration management know what environments exist, provide visuals on applications deployed and enable automated mechanisms to deploy new application version or back out ones if there are issues. 
  • Testing tools make it easier to automate tests and configure them to run during application builds or deployments. 
  • Monitoring systems automate data capture from many disparate systems and provide tools to diagnose root cause of complex performance or stability issues. 

DevOps Culture

DevOps is also about the culture of aligning Dev and Ops teams so that they have a single mindset on improving the customer experiences. For Dev teams, that usually means standardizing platforms, following an agile development process, and participating in Ops practices. For Ops teams, it means instrumenting many of the tools identified above and targeting better stability, improved costs, or better responsiveness.

Maturing agile delivery and DevOps over time, will lead teams to support continuous delivery - the ability to push code out to Production frequently. For companies in highly competitive industries and where technology provides differentiation, the ability to make frequent application deployments can be a differentiator.

What's Not to Like?

All this sounds too good, and it might be for many organizations. First, many organizations will debate tool selection especially when operating in heterogeneous system environments. Are these new tools or replacing existing ones? In many situations, it's a mix of both and the complexity of funding, selecting, and instrumenting new tools will paralyze some organizations before they start.

Second, like agile development these practices are a lot easier to instrument at startups and small companies where the infrastructure can be built from the ground up with these tools, and DevOps practices established from the start. In larger or more established organizations,  it takes investment, time, talent and executive backing to make this happen - something I predict will be a major IT transformation in the next year

Finally, like agile development, DevOps has basic principles but it does not have a manifesto the caliber that agile development has and had from its beginnings. This means that there is significant variance to what DevOps means from one company to the next. The debate on what practices to implement, how they should be implemented, and how to manage the DevOps organizational structure will require a strategy and planning.

Aligning DevOps with Business Goals

Like all IT practices, it's important to start with business goals and measures. Perhaps the organization has to improve stability? Maybe there is significant growth and a need to manage costs and complexity while the business scales? Maybe the business is in a technically competitive industry where continuous delivery is important? Perhaps you are working in a regulated industry where quality and repeatability of the deliverable is required? These drivers should lead to an IT strategy that help develop an operational strategy and prioritize  investments.

Second, management has to be very active when considering the organizational structure and cultural aspects of this transformation. In addition to aligning with goals, changes in these areas should be architected to better align IT with the business, and not just help instrument DevOps practices.

Where to Start?

The very best place to start? I suggest taking measurements of current state before instrumenting too many changes. How stable is the production environment? How frequent are application changes being deployed? How often are applications deployed with significant defects? How often are you scaling systems to meet demand? 

Of these metrics, which ones need the most improvement to match business need? Prioritize 1-2. Now you can start thinking about DevOps.

continue reading "The What, Why, and How of DevOps"

Tuesday, January 13, 2015

Best Data Visualization and Dashboard Management Practices in Self Service BI Programs

I've seen many organizations run into difficulty defining governance and best practices managing the lifecycle of BI dashboards. Perhaps you have deployed a self service BI program - data scientists have access to tools, IT has deployed severs to publish completed dashboards, and employees are anxious to leverage visualizations and become more data driven. Job done right?

Not so fast. Flashback 10-20 years ago when business users became proficient with MS Excel, MS Access and more advanced BI solutions. Perhaps too sufficient and you have an organization of spreadsheet jockeys and a data landfill instead of a landscape. Has the organization ended up with an explosion of spreadsheets and reports? Ever have an issue where decisions were made on a report made with buggy calculations? When you open a report, do you have questions on what the columns mean, where are the sources of the data, or what is the logic behind an aggregation?
This is common and occurs because organizations fail to put in some basic governance practices around data, reports, dashboards, visualizations, and analytics. 
I stress the word basic - not overbearing, but recognize that a self-service BI program without basic data governance may provide value but will slow down before achieving its full potential.

Best Practices in Self Service BI Programs

So let me suggest some starting points.

  1. Define a life cycle - I strongly suggest organizations manage dashboards like applications. They are developed, they need to be tested, their needs to be some documentation, users need to be trained, they need to be published, feedback from users needs to be gathered, enhancements should be prioritized. This doesn't need to be as onerous as it sounds, but having these disciplines insures that dashboards developed provide enough value and worth the effort. Testing, documentation, and training insures that dashboards developed are leveraged by a audience wider and hopefully prevents the duplication of effort in creating similar or derivative dashboards.
Implications for IT
    • Data scientists need a central place to store source files; spread sheets, Tableau workbooks, Qlik application, etc. Ideally these should be stored somewhere where files can be versioned and tagged.
    • Servers should be configured to handle the equivalent of dev, test, and production.
    • IT should consult with data scientists to consider tools, templates, and storage of documentation.
  1. Documentation should focus on data flows, data definitions, calculations, aggregations, and known data quality issues. Data scientists joining the organization need to have a strong understanding of their starting points while dashboard consumers need to be able to use them and interpret the results. Organizations need to define documentation standards for these audiences and when in the lifecycle they should be updated.

  2. Define style guides covering layouts, control choices, common components, visualization types, color palettes and other design considerations so that there is consistency between dashboards developed by different data scientists.

  3. Testing should focus on insights, calculations, and usability. Do the results look reasonable? Are calculations providing expected values? Are the dashboards usable and intuitive or complex and clumsy? The lifecycle should be developed for iterative review and feedback. Dare I say agile data practices?

  4. Governance practices should target reviews of the quantity and disparity of dashboards developed. This is really important in order to avoid landfills because if everyone develops their own dashboard versions that largely perform the same analytics, the sheer quantity of them will make it more difficult for users to navigate and possibly provide conflicting results. It will also add complexity when data models or software systems need upgrading.

  5. Measure usage and impact because data visualizations and dashboards not being used should be phased out.

Evolve the Practice

Not all of this needs to be defined up front. Define these and other practices as needed.

continue reading "Best Data Visualization and Dashboard Management Practices in Self Service BI Programs"

Thursday, January 08, 2015

CIO's Five Predictions for 2015

It's that time of year when the analysts and media predict the year to come in technology. If you missed some of these prediction, see Gil Press' recap of Forrester's, Gartner's and IDC's predictions.

This year, I thought I would take a stab at some predictions and what may be important to CIOs in 2015. I'm not talking IoT everywhere, even bigger Big Data, and other big or bold predictions - I hope these are closer to reality and practical for the majority of CIOs.

  My 2015 Predictions

  1. Enterprises will embrace elements of DevOps - Most enterprises adopted agile development over the last 5-8 years, many have starter to embrace cloud infrastructure, but aligning operational practices remains a final frontier for many enterprises. With maturing cloud service providers and increased pressure on CIOs to innovate, expect them to begin implementing continuous delivery and other automation practices to help reduce costs, improve the frequency of application deployments, and reduce human errors in systems management.

  2. Big Data investments may be the Big Bubble for some CIOs - Hadoop and other big data technologies remain complex to configure properly and the skill set is in short supply. Finding Data scientists that understand how to translate smart big data questions into implementations is also difficult. CIOs who don't help close the skill gap and champion winning analytics programs may find their business colleagues becoming fatigued with big data promises and spending. 

  3. Successful CIOs will deploy more business meaningful data services - Big data technologies aside, CIOs will look beyond basic "keep the lights on" DBA services and look to mature data services better aligned with analytics and data science programs. Services such as loading (ETL) new data sources, scaling cloud environments for experimental analytic data processing, or researching performance issues with data visualizations are examples.

  4. Consolidations in Digital Marketing Providers - There are too many choices and too many vendors in this space and while Marketers should have some appetite to experiment, the plethora of choices will frustrate some and mounting failures (or limited success) will hit others. Expect vendor acquisitions and consolidations which will make it easier for Marketers to select capabilities from a more mature playing field.

  5. Boards will require Information Security Roadmaps - 2015 may be the tipping point where the next tier of companies become more active to address information security issues. The appetite to make security investments may still be difficult given other business needs, but Boards are more likely to request their CIOs to formally present security risks, options, and a roadmap.
What do you think? I will follow up at the end of the year.

continue reading "CIO's Five Predictions for 2015"

Thursday, January 01, 2015

Top 2014 Posts - On IoT, Big Data, CIO / CMO Relationships and Agile Data Orgs

Thanks to all my readers, tweeters, and other supporters of Social, Agile and Transformation! 

Here are my top posts of 2014 based on page views. My top posts on the Internet of Things, Big Data, Self Service BI, and CIO/CRM relationships made the list. You can also dive into some of my other posts on 2014 Big Data Posts - Self Service BI, Agile Data Management Practices, and Killing Data Landfills and 2014 - The Year the CIO and CMO Partnership Became Mission Critical.

The List

  1. How Artificial Intelligence Will Solve IoT's Big Data Challenges - How AI and machine learning will apply to IoT's big data challenges

  2. The Best Line of Code is the One You Didn't Have to Write! - on PaaS platforms that enable app development

  3. How to Clean Your Inbox and Drive Marketers Crazy - why Marketers need IT's help

  4. What is the Internet Of Things? The Magic Beyond Bracelets, Gadgets and Home Automation - identifies local, neighborhood and regional data processing that will bring IoT beyond a personal experience

  5. The Database Decision that Will Hurt Your Company's Big Data Opportunities - on applying the appropriate database technologies
I was surprised to see two IoT posts make the list, and none of my posts on Agile practices. So as a bonus, my top agile posts are What Agile Teams Can Learn From 1st Graders and Five Tips on How To Manage Disruptive Projects in an Agile Organization without going Crazy!

Some of my personal favorite posts

Also see my top posts of 2013 and 2012.

Happy New Year!

continue reading "Top 2014 Posts - On IoT, Big Data, CIO / CMO Relationships and Agile Data Orgs"

Friday, December 19, 2014

2014 - The Year the CIO and CMO Partnership Became Mission Critical

I started 2014 with several posts on the CIO / CMO relationship and where IT departments can help with digital marketing initiatives. The main touch point is around data and the technologies that enable CMOs to be more data driven. With so many technology vendors trying to tap into marketing budgets and when most of the key marketing data is is enterprise systems, SaaS products, and other data silos, the CIO has the opportunity to help deliver marketing results in a sustainable way.

Big Data technologies and practices are at the front and center of this collaboration. Every company has CRM(s), financial systems, transaction systems, and now marketing automation platforms that contain information on prospects, customers, and former customers. Big Data platforms can help join this data and be the backbone to cleansing, data mining, and analytics efforts needed for digital marketing efforts.

Click on the image below to learn more. Also, see my related posts on Big Data, Self Service BI, and Agile data practices.

5 Tips On Starting a Killer
CIO - CMO Relationship
CIO CMO Partnership -
The Modernized
Selection Process
How to Clean
Your Inbox
and Drive Marketers
Last Call for Collaborative
CIOs and CMOs -
Winning at
Data Driven Marketing
5 Ways IT Pros Can Help Marketing
Dear CIO,
Here's How To Help the CMO
with Marketing Automation
3 Big Data Platforms Needed for Marketing Automation Success

continue reading "2014 - The Year the CIO and CMO Partnership Became Mission Critical"

Monday, December 15, 2014

2014 Big Data Posts - Self Service BI, Agile Data Management Practices, and Killing Data Landfills

In 2014, many of my posts on BigData were actually about "small" data management practices. Specifically, I hope these posts educated readers that tools of "Data Science 1.0" such as Microsoft Excel, PowerPoint and especially Access can disrupt - even kill - efforts to make organizations become more data driven.

In addition to calling out this problem which is something I have been doing for a couple of years now (see my classic posts on Spreadsheet Jockeys and my plea to Stop Creating More Access Databases), this year I offered solutions. Specifically, I think CIOs need to deploy Self Service BI tools and establish more modernized data management programs. I support data scientists that act like disciplined hikers, adopt agile practices, and avoid creating new data landfills.

Click on the images below to read related posts. Good luck everyone in 2015.

The Database Decision that Will Hurt Your Company's Big Data Opportunities
Succeeding in Big Data Transformation - It is a Journey, Not a Destination!
Friend or Foe? How Microsoft Excel 2013 Creates New Data Governance Challenges
Why is Data Sooo Messy and How to Avoid Data Landfills
Killing Bad Data Practices - Acknowledging The Problem is Half The Battle
5 Agile Leadership Practices Where CIOs Can Help Data Scientists
Five Data Management Practices IT Needs to Better Support Data Driven Organizations
What Technologies Work Best for Decentralized Data Scientists?
The Agile Data Organization - Balancing Responsibilities in Data Science Programs
Agile Data Scientist, A Disciplined Hiker or Reckless Hunter?

continue reading "2014 Big Data Posts - Self Service BI, Agile Data Management Practices, and Killing Data Landfills"