Leading Digital Transformation: Finding the right velocity in driving organizational change

I was recently asked, "Isaac, what keeps you up at night?" My answer is simple. In transformation programs, going too slow can lead to your business being disrupted. If your competitors are putting out great experiences, are more competitive winning business by leveraging data, or are demonstrating strategic business impacts with AI, blockchain, or IoT then your business is at risk. Here's a quote from my book Driving Digital: The Leader's Guide to Business Transformation Through Technology

Going too slow can also be very detrimental. It can lead to business failure and disruptions to entire industries. -- Isaac Sacolick

I then go on to tell the story of the newspaper industry that fell off the digital disruption cliff starting after the 2001 internet bubble burst. They simply couldn't adjust their business models fast enough to digital disruptions impacting how they serviced readers and advertisers.

Going too fast cast can burnout and alienate the team


So as a digital transformation leader - which can anyone in the organization leading or participating in a digital transformation initiative from the CEO, the CIO, the CDO, the CMO down to leaders on agile teams - going too fast is also an issue. In a previous post, I shared three signs you have overloaded your digital transformation program. Pressure to take on too many initiatives may bottleneck the overall program and burnout participants.

So what keeps me up at night is striking the right balance. Going fast enough so that the organization is leading digital transformation versus their peers and competitors but going steady enough so that teams don't burnout along the journey.


What it's like leading transformation programs


This leads me to another question that I'm often asked, "What is it like to lead transformation programs." Here is how I answer it

Leading transformation programs is like wearing a huge target on your back with people ready to shoot arrows at you. On one hand, their is pressure from the executives to get more done faster and without making their worlds difficult. On the other, there are detractors to digital transformation in the organizations that want to stand on the sidelines and prefer that old business methods remain intact. There are select members of your team that might want to run in a different direction, or slow down, or speed up, or implement things differently than the strategic direction. Finally, there are colleagues that may be envious and want to be the anointed leader of the transformation program.

It's not an easy task and I share some of the challenges leading transformation programs in Driving Digital. But here are three things that can help leaders avoid getting an oversized target on their backs

  • Communicate early, frequently, and targeted to the audience

  • Champion early adopters who are willing to lead and teach the larger organization

  • Pick the right battles. Consider your values before jumping into every debate

It's a journey. Make sure you lead efforts so that you're there for the whole ride.

continue reading "Leading Digital Transformation: Finding the right velocity in driving organizational change"

5 Recommendations on Implementing DevOps CI/CD Pipelines

CICD Illustrated
CI/CD is one of the key devops practices because it enables teams to align on development practices and ensure there is a consistent, reliable, and automated way to deliver applications to multiple compute environment.

If you're new to CI/CD, consider reading my InfoWorld posts on What is CI/CD and on getting started with CI/CD. What you'll see is that there are many steps to mature this practice with some steps that need alignment of team practices and others that require engineering work. There isn't one way to implement CI/CD and it's easy to get lost on where to start and how much to implement. So with that in mind, here are five of my recommendations on implementing continuous integration and continuous delivery:


1. Identify business and technical objectives


For most organizations, CI/CD pipelines aren't implemented overnight and are more often implemented incrementally. That means most devops teams have to prioritize what practices to develop, what processes to automate, and what platform stacks to focus on.

The best way to do this is to look at short term business priorities and align both devops and CI/CD objectives to them. If there are new applications being developed then that's an optimal time to focus on the CI/CD pipeline for them. If you are undergoing a cloud migration, then standardizing architectures and developing CD pipelines for applications that undergo the most frequent changes is a good starting point.

2. Start CI/CD with Continuous Testing


My friend an colleague said it best

"Organizations needs to focus on the fundamentals first, meaning ensure the source code has programmatic unit tests, passes static code analysis and security scans." -- Thomas J. Sweet
Increasing the speed of delivery only works if you're able to deploy quality code and near defect-free applications. That means implementing automated tests and plugging them into CI/CD to support continuous testing. And not just unit tests. Add in code analysis, security, and performance testing that should all be triggered from CI/CD with every major push to staging and production environments.

3. Standardize the architecture before implementing CD


Automation provides value when it can be repeated reliably. For development teams, that means deployment to multiple types of development and testing environments and one or more production environments. If the architecture of these environments are not standardized, it's hard to get the benefits of automation.

If you have to clean up the architecture, consider automating the infrastructure as code using chef, puppet or ansible and leveraging either docker or kubernetes containers.

4. Align short term business objectives with CI


Some teams get carried away and drive CI/CD toward continuous delivery, but, continuous delivery may not be appropriate for every business or application.

In addition, teams need to think through how they will implement longer running feature development. If the business objective is to launch just a handful of features that are not tightly coupled, then using feature branches may be a good enough solution to separate out feature tracks and merge when ready. However, if there are many features being developed over an extended period of time, then development teams might want to look at feature branches for some and feature flagging for others.

5. Let the system engineers implement CD


CD requires a lot of scripting, knowledge of the computing (cloud) architecture, and knowledge of the application's requirements. Teams might be tempted to let the developers on the team to take on the challenge of learning CI/CD tools and implementing the automation, but I believe the strongest teams will engage the engineers to take on this work.

Why? Because I'd rather see developers implementing business solutions and coding applications. It's better use of their skills. And, I'd rather see the engineers more versed in systems programming including IaC and CI/CD.

CI/CD should also drive platform rationalization


Some final thoughts...

There is an expense to standardize computing architectures and develop CI/CD pipelines for them. So larger organizations with multiple development stacks should consider consolidating to a handful of approaches. It's not easy or cheap to have lots of ways to code applications and automate software delivery.

continue reading "5 Recommendations on Implementing DevOps CI/CD Pipelines"

What is AIops? Collaboration, Practices, and Principles for Delivering AI Solutions

I heard about the term AIops term last week at The AI Conference, presented by O'Reilly and Intel AI. Is this a real practice? My answer is yes and here's why.

Consider that DevOps is the practice to align developers and operations on the agility, speed, and stability of making software releases. DevOps aims to align a multidisciplinary team on conflicting missions and priorities by standarding CI/CD pipelines, increasing monitoring, and other DevOps best practices.

Then consider DataOps, the emerging discipline of align data professionals including data-driven business managers, data scientists, citizen data scientists, data engineers, data stewards, database architects, ETL developers, and DBAs to align on strategies and practices to ingest, cleanse, store, govern, manage, and deliver data and analytics to the organization and its customers.

Both DataOps and DevOps align multi-skilled professionals on mission, values, technologies and practices to achieve short term goals and deliver on longer term competitive value.

So here's my definition of AIops:

AIops defines the mission, principles and practices that drive collaborative AI experimentation that delivers business results

AIops aligns key practices in the AI journey


AI also requires aligning multi-skilled professionals. In addition to AI specialists, it requires support from business managers, subject matter experts, data engineers, and technologists to align on mission, data sources, platforms and desired outcomes.

The team needs direction on experiments that drive business value.  This requires collaboration as defining overly bold experiments may be unachievable while missions that target marginal business value may not justify the investment.

To be successful in AI, the team needs access to a large volume of relatively clean data. The AIOps team then must take steps to tag data for supervised learning AIs or define reward functions for unsupervised problems. The practice of organizing and standardizing data for AI experiments is an AIops practice.

AI requires selecting platforms, tools, and infrastructure that needs to be ramped up and down as experiments are conducted. Teams can consider a multitude of platforms (TensorFlow, Keras, PyTorch, Caffe), cloud provider (AWS, Azure, Bluemix, Google), and a growing number of collaboration platforms (Dataiku, H20.ai, Databricks, Anodot, Clusterone and others) as part of their AI and machine learning environment.

With data ready, the team needs a working process for running experiments. I've suggested that agile experimentation is required for AI and the team needs to establish trackers to capture metadata and results of the trials conducted.

Once experiments are conducted, the results need to be analysed. The team needs to determine the success of the overall experiment and what follow-on experiments to prioritize.

When results yield satisfactory results, the team then needs to determine how to establish a production process to run new data through the AI models.

Why AIOps should be formalized


Organizations dedicating resources to AI experimentation recognize the journey that needs to be led by a collaborative, aligned team:

  • From early stages where people, partners, and platforms are established
  • Middle stages where the team develops its practices, grows data sets, and automates processing steps
  • Later stages where agile AI experimentation begins to show results and production practices are established

Organizations making larger investments and committed to longer term experimentation in AI can define their AIops mission, practices and culture to align teams and deliver results.

continue reading "What is AIops? Collaboration, Practices, and Principles for Delivering AI Solutions"

The basics of Deep Learning and Bayesian Networks in under five minutes

Still confused about deep learning, how it works, what is its shortcomings, and what is its origins? Watch this 4.5 minute keynote snippet by Zoubin Ghahramani, Chief Scientist at Uber, at O'Reilly's Artificial Intelligence Conference going on in NYC this week. He nails it.

Paraphrasing Zoubin: Deep learning is neural networks rebranded. Compute power enables us to run many layers of weighted computational neurons, hence the phrase "deep". They are data hungry, computationally intensive, uninterpretable black boxes that can be easily fooled.

But ...

They can do amazing things and using them is becoming easier. See the video snippet of the keunote below and watch other highlights from the conference.




continue reading "The basics of Deep Learning and Bayesian Networks in under five minutes"

Practical CIO Advice for Managing Change on CXO Talk [Video]

My second appearance on CXO Talk may be better than my first show! Thanks to Michael Krigsman for having me on again!

Some of what we covered -
  • Technology has a huge impact on how we service customers
  • How are organizations become more competitive with data and analytics
  • Transformation is a "people conversation" first. Rely on people to use their innovation and expertise to collaborate on goals and implementation
  • Agile practices is important in transformation programs because it brings business and IT people together to work collaboratively and reset priorities based on feedback. "Come to the demo and see what we're doing!" Agile is Chapter 2 of Driving Digital because it is the vehicle for instrumenting change.
  • Are you going fast enough? Are you going to beat the disruption curve in your industry? 
  • Are you building technology that is truly sustainable? Are you investing in devops practices?

And some questions I answer
  • Why digital transformation is fundamentally different? 
  • What are the implications of technology being implemented outside of IT?
  • What about shadow IT? What should CIOs do about it? 
  • How should CIO partner with the CFO on transformation programs?
  • What should CIO that reports to a non-tech CFO and views IT as a cost center do about it?

Watch the full video below! -  


continue reading "Practical CIO Advice for Managing Change on CXO Talk [Video]"

How devops practices prevent legacy platforms

CIO and DevOps
Do you fully grasp the long-term business problem devops aims to solve?

I'm going beyond the upfront benefits. The alignment of dev and ops teams to build and deploy supportable applications. The ability to release frequently and bring new features to market faster. The monitoring that informs technologists of application issues before end users escalate them. The automation to scale up and down infrastructure based on end user demand.

If that's not good enough reason to invest in devops, then let's consider some longer term benefits.

How and when CIO should invest in devops 


As a CIO, you get the chance to make some choices over how IT funds are spent. Hopefully it’s to improve a customer facing application to drive revenue or improve the end user experience. Maybe it’s a new enterprise platform that will replace several legacy systems. Ideally, it’s an investment in analytics and other data platforms that will foster a data driven organization.

Good times when CIO get to make these investments. Even better when they demonstrate business impact and can justify a second and third investment. Best is when these investments are tied to a digital transformation program and the organization is growing beyond its legacy businesses.

But here’s the issue. It’s easy to build technology than to support it.

And while CIO can often leverage the capital budget to fund investments, ongoing support comes out of the operating budget.

And most (all?) CIO will tell you there just aren’t enough funds in the operating budget to truly maintain all the systems and applications.

This forces CIO to make some tough calls on how to spend operating budgets. In the past, that often meant focusing on the underlying infrastructure and application lifecycle issues. In other words, maintaining the hardware, patching the operating system, supporting platform upgrades, responding to incidents, and supporting a queue of requests. Improvements came only after these other concerns were addressed.

Over time, and as IT people left the organization, these technologies evolved to legacy platforms.

Sponsor devops when applications are being developed


Now let’s consider the CIO that invest in an application’s supporting infrastructure while the application is developed. They start with some best application development practices. Requirements are captured in agile tools, code is checked into version control, and releases are versioned and annotated. Testing is automated. Not just basic unit test, but also end to end functionality tests, performance testing, static code analysis, and security testing. Then, a CI/CD pipeline is engineered so that the steps to push the application to runtime environments is automated.

They don’t not stop there. The application is deployed on container technology so that the entire runtime configuration is captured and documented. An Infrastructure as Code (IAC) platform is then used to automate and standardize the infrastructure.

Finally, a ton of monitoring is set up so that the team can track the CI/CD process, how infrastructure is performing, whether applications are logging issues, whether API endpoints are responding properly and whether user experiences are behaving correctly.

And the devops investment in done as part of developing applications. In other words, the CIO uses part of the capital budget to not only develop the application, but also to create the devops automation.

Will devops make supporting applications easier? 


A recent survey of 549 software professionals provides some insight. Nearly fifty percent of respondents claim their mean time to restore service when there is a production issue is under two hours.

Try hitting that KPI with legacy applications that aren’t cloud native and without CI/CD pipelines.


continue reading "How devops practices prevent legacy platforms"

Are you developing too much code? The rationale for low code alternatives in digital transformation programs

Too much code
I am concerned that some organizations are developing too much custom code as part of their digital transformation programs. The code may be tied to delivering new mobile experiences to customers, integrating new data sources into a data lake, generating dashboards, or providing collaborative tools for a departmental workflow. Writing too much code can be a mistake for organizations when supporting and enhancing the code becomes more difficult than anticipated.

It’s easier to write and deploy code today than ever before. Set up a cloud, select a development language and platform, download an editor, setup one of dozens of data storage services, decide on a basic testing process, commit code to git, develop a rudimentary CI/CD pipeline … There's plenty of "how to" videos and tools to get developers started with the basics, or, organizations can hire a freelancer or service provide to do all the heavy lifting. Two weeks you have an app and in two months you are at MVP.

Developing custom code is NOT that easy!


Sound easy? I promise you that it’s not. I just rattled off a half dozen technologies not including all the open source or third party libraries that are leveraged in the code base.

Watch a developer debug a difficult performance issue, solve a complex user data issue, or resolve a conflict in how a browser version interprets a CSS.

I have deep respect for developers working through these issues. Even with the best code standards, debugging tools, and runtime performance monitoring, it can be difficult and time consuming to research and resolve application defects especially if they only impact a subset of users.

And business leaders need to learn and relearn the patience it takes to build and support a custom application. Something what looks like an easy implementation or a quick fix often takes a lot longer than anticipated. One of the most common questions I get from business managers is, "Why does [fixing it | developing it | resolving it] take so long?"

And therein lies my concern. Most business leaders don’t have this patience. Many businesses don’t allocate the budget to support upgrades and enhancements to applications. Only the best of developers write code that is easily maintainable by other, often more junior developers. Few organizations invest enough in developing automated tests and documenting their code. 

And with many platforms and open source libraries being released more frequently, businesses face a lot more risk if they don’t actively upgrade applications.

Why are you developing so much custom code?


It’s good that organizations are looking to develop more applications. It's GREAT actually. Some of these applications are products that drive revenue or customer facing applications that improve end user experiences. Some are workflow applications that make employees more efficient or enable them to better collaborate on business needs. Other applications may be tied to data integrations or analytics programs. Again, all good stuff!!

But not necessarily good for organizations that elect to develop custom code for all these business needs!

I believe there are four reasons organizations are developing more custom code -

  • Business and technology leaders do not invest sufficient time to research platforms, implement proof of concepts, and promote platform-backed solutions to stakeholders. When investments for new applications are justified, the organization doesn't have the time to research and falls back to developing proprietary applications.  

  • Product owners drive requirements toward solutions that can only be implemented with custom code and they are reluctant to compromise when alternatives are presented.

  • Some CIOs are reluctant to bring in third party platforms, sometimes because they fear experimenting before their is organizational support for platform driven development and sometimes because they are concerned on being locked in to a vendor’s proprietary tools.

  • Many developers prefer writing proprietary code over using technologies like data integration, low code, BPM, and other platforms that require less and sometime no custom coding. 

Identifying low code and no code alternatives


So what should organizations do differently? What enables them to seek out platforms and tools that can enable delivering more capability with less code?

The simple answer is to do more research, review, and POCs of the alternatives. In almost every major category of application development need, you can likely find platforms or tools that enable development with less or no coding required.

Need a content management system? I can list at least four. Need to integrate data from disparate sources then I know of six that can get you started. Need to develop mobile first applications for the enterprise then there is at least another half dozen. BI - yes. Even AI and blockchain has emerging platforms that will enable experimentation with less coding. Contact me if you want to discuss!

It's a cultural issue, not a technology issue. Organizations that have a DIY (do it yourself) or a NIH (not invented here) culture have to tackle these beliefs.

Don't leave a legacy of too much code behind.

Further reading on low code 




continue reading "Are you developing too much code? The rationale for low code alternatives in digital transformation programs"
Share