Capturing was never my problem. I was good at capturing. The problem came later, when I wanted the idea back and had no idea where I had put it. Was it an email? A note? Which app, which folder, which device? By the time I gave up looking, the thought had gone cold. The small insight that felt valuable on Tuesday was just gone by Friday!

It took me long time to name what was really happening. I did not have a note-taking problem. I had a trust problem. I never trusted any of those systems to give me back what I put into them, so I never fully committed to one. And a tool you do not commit to is a tool you quietly abandon.

That single realization is the reason I eventually built my own. It is also, I think, the reason most AI inside companies never gets used.

What I actually wanted

I wanted one place to throw anything, a stray idea, a quote, a half-formed plan, a useful link, a photo with a caption, without stopping to decide where it should live. Then, weeks later, I wanted to ask a plain question and get a real answer, not a list of search results I had to dig through myself. In addition, I want a quick access from my mobile.

So I built it. I call it SPECTER: a personal Second Brain that captures whatever I give it during the day and lets me ask for it back in plain language. I have been running it daily for months. I add 5-10 entries a day, and I pull things back out three different ways: a clean web app, a quick message to a bot on Telegram, or a search that understands meaning rather than just matching keywords (Semantic Search).

The Specter web app: everything captured, sorted by itself, one question away

But the interesting part is not what it does. It is why I trust it enough to keep using it, when a decade of other tools failed that test.

Trust is the thing, not the model

Everyone talking about AI right now is talking about the model. Which one is smartest? which one is fastest? In practice, the model was the easy part. The hard part was earning enough trust that I would actually rely on the thing every single day.

When I look back at what made the difference, it comes down to four layers. I think of them as the AI Foundation Trust Stack, and I have started using the same lens when I look at AI projects inside larger organizations.

The AI Foundation Trust Stack

Truthful. Specter only answers from my own notes, and when the answer is not there, it says so instead of inventing one. A confident wrong answer would have ended my trust on day one.

Owned. It is my data, in my own store, behind my own login. I am not quietly handing my thinking to something I cannot see.

Effortless. It meets me where I already am. Capture takes seconds, on whatever device is in my hand, and the system sorts and labels everything itself. I never file anything.

Predictable. It runs for the price of a coffee or two a month. No surprise bills, no runaway cost as I use it more.

Truth sits at the bottom because nothing else matters if the system lies to you. Everything above it builds on that. And when all four hold, the rest takes care of itself. I trust it, so I use it. Because I use it every day, it gets more useful. Trust becomes a habit, and the habit compounds.

A day in the life of a thought

Here is what actually happens when I catch an idea now.

How a thought moves through Specter

I message it to a Telegram bot on my phone, the same way I would text a colleague. The system reads it, decides what kind of thing it is, and tags it on its own. It stores not just the words but their meaning, so later I do not have to remember the exact phrase I used. When I want it back, I ask a normal question, and it pulls the right memories and writes me a direct answer grounded only in what I actually saved.

No folders. No filing. No trying to recall which app I used three weeks ago. The thought goes in once and comes back when I need it.

The decisions that earned the trust

None of this came from a clever model. It came from a handful of deliberate design choices, each one aimed at one of those four layers.

*That third row is the one most people underestimate. Adoption does not die because a tool lacks features. It dies the moment the tool asks you to change a habit. The easiest system usually wins, even when it is not the smartest one in the room.

Under the hood

For the technically curious: capture arrives through two surfaces: a Telegram bot I message the same way I would text a colleague, and a web form in the browser when I am already at a desk. Either way, the request hits an AWS Lambda function that calls Voyage AI to generate a 1024-dimensional semantic embedding of the text, then passes it to Claude Haiku to classify it into a category and assign up to five tags automatically. The entry, its embedding, and its metadata land in a Postgres table on Supabase with the pgvector enabled. When I ask a question, a second Lambda embeds the query the same way, runs a cosine similarity search against the vector index to surface the most relevant entries, then hands those to Claude Sonnet to synthesize a grounded answer; one that draws only from what was actually retrieved. The web app is a React SPA served from S3 behind CloudFront. Total infrastructure cost at my usage level: roughly $2 a month. That is not a rounding error; that is what “predictable” actually looks like in practice.

Specter architecture: two serverless paths, one shared vector store

Why this is your problem too

If you lead a team or a company, you have almost certainly seen this exact pattern. A promising AI tool gets bought, demoed to applause, and six months later nobody opens it. The post-mortem usually blames the technology. It is rarely the technology.

Trust turns into adoption turns into value

People don’t adopt what they do not trust, and they don’t trust what lies to them, hides their data, slows them down, or surprises them with cost. Capability gets the pilot approved. Trust is what gets the thing used after the excitement fades. Most AI initiatives stall at exactly that gap, and the four layers above are a fair checklist for closing it.

To be clear, I am not suggesting you go build your own. I built Specter because I wanted to understand this problem down to the bone, not because every business should write its own software. In most cases you can buy, not build. But whether you buy or build, the same question decides whether it sticks: has it earned enough trust to become a habit?

A small invitation

If any of this sounds like a problem you recognize, in your own week or across your organization, I would like to hear how you are thinking about it. And if it is useful, I am always happy to talk through it informally. Most of what I have learned about AI that actually gets used, I learned by trying to earn my own trust first.

The question dominating most boardrooms right now is: where should we apply AI?

It sounds strategic. It isn’t.

It treats AI as a capability to bolt onto existing processes — a smarter search here, a faster report there. And while those pilots generate demos that impress in presentations, they rarely change how the enterprise makes decisions at speed. They rarely move the revenue line. And they almost never survive contact with the operating model they were supposed to transform.

The CIOs gaining ground have moved past that question entirely. They’re asking something harder: what kind of enterprise do we need to become for AI to actually work?

That reframe changes everything.

The three questions your organisation hasn’t asked yet

I’ve found that most organisations are blocked at the same three pressure points — and none of them are technology problems.

1. Is your data architecture a platform for the future, or a record of the past?

Most enterprises have invested heavily in storing data. Far fewer have invested in making that data usable — in real time, at scale, across organizational boundaries. AI models are only as good as the data foundation beneath them. If your data is siloed, inconsistent, or governed for compliance rather than for insight, your AI initiative will underdeliver regardless of which model you choose or which platform you run it on.

The question for your next board discussion isn’t “which AI tool should we buy?” It’s “do we have the data architecture that makes any AI investment defensible?”

2. Does your organisation have the operating model to act on AI outputs at speed?

Automation without decision velocity is one of the most expensive mistakes an enterprise can make. It accelerates the wrong things.

AI can surface an insight in seconds. But if that insight travels through five approval layers before anyone acts on it, the competitive advantage evaporates. The organizations seeing real returns from AI are not necessarily the ones with the most sophisticated models — they are the ones that restructured how decisions get made so that humans and AI can operate in genuine partnership.

That is an organizational design question. It belongs on the CEO’s agenda. And the CIO is the right person to put it there.

3. Has your board defined AI governance before a failure — not after?

Most boards define their risk appetite for AI in response to an incident. A biased output. A hallucinated recommendation that reached a customer. A model that performed well in the pilot and failed at scale.

That is the wrong order.

Governance frameworks built under pressure are reactive by definition. They optimize for damage control, not for confident acceleration. The CIOs I’ve seen lead this conversation well have taken AI governance to the board as a strategic instrument — not a compliance checkbox. They’ve reframed it as the thing that gives the organization permission to move fast with confidence.

The CIO’s unique position

There is no other role at the executive table that sits at the intersection of the CEO’s growth ambition, the CFO’s capital discipline, and the COO’s operational reality. That position is not a burden — it is leverage.

The AI readiness conversation — grounded in data architecture, operating model design, and governance — is the instrument that turns technology leadership into enterprise leadership. It is how the CIO moves from being the person who explains the technology to being the person who shapes the strategy.

That shift doesn’t happen by delivering more successful pilots. It happens by owning the questions that the rest of the C-suite doesn’t yet know how to frame.

The metric that actually matters

Most organizations are measuring AI success by the number of pilots running.

I’d argue the more important metric is how many of those pilots have changed a business decision at the executive level — shifted a resource allocation, altered a market entry plan, changed how the enterprise prices or serves.

What’s your ratio?

I write on technology leadership, digital transformation, and the decisions that shape enterprise strategy. If this resonated, follow for the next piece in the series.

Multicloud Isn’t a Strategy Anymore. It’s an Operating Discipline Most Enterprises Are Not Ready For.

For years, Multicloud was treated as a choice.

• A strategic position.
• A hedge.
• An architectural preference.

Today, that framing is outdated.

In most large enterprises I engage with, Multicloud is no longer a decision waiting to be made. It’s already a reality — often an accidental one.

The real question has shifted from “Should we do Multicloud?” to something far more difficult:

“Do we actually know how to run it well?”

How We Got Here

When Multicloud conversations started gaining momentum around 2018–2019, the primary driver was clear: Vendor lock-in avoidance.

Enterprises wanted leverage, flexibility, and optionality. That rationale made sense at the time.

Fast forward to today, and the motivations are far more pragmatic:

• Regional availability and resilience
• Data sovereignty and regulatory requirements
• Different cloud providers’ strengths in specific domains
• Mergers, acquisitions, and inherited platforms
• Line-of-business decisions happening faster than central IT can control

In many organizations, Multicloud wasn’t designed — it emerged. And now leaders are left to operate it.

Multicloud Is emerging to be the Default, Not the Exception

Look at any large enterprise environment today and you’ll usually find:

• Multiple hyperscalers
• At least one major SaaS ecosystem
• One or more legacy on-prem platforms
• A mix of old and new operating models

This isn’t ideological Multicloud. It’s enterprise reality.

Yet many organizations are still managing this reality with:

• Fragmented tooling
• Inconsistent security models
• Ad-hoc networking decisions
• Cloud-specific operating silos
• Cost visibility only after the bill arrives

This is where Multicloud stops being a strategy and becomes an operational stress test.

The Myth of “Cloud Neutrality”

One of the most damaging ideas in enterprise cloud conversations is the pursuit of full cloud neutrality.

On paper, it sounds attractive:

• Abstract everything
• Make workloads portable
• Treat all clouds the same

In practice, it often leads to:

• Lowest-common-denominator architectures
• Missed platform advantages
• Higher cost and complexity
• Slower innovation
• Decision paralysis

Cloud platforms are not interchangeable commodities. They have different primitives, strengths, and trade-offs.

Trying to pretend otherwise doesn’t simplify Multicloud — it makes it more expensive and fragile.

The most successful organizations I see are not neutral. They are deliberately opinionated.

Where Multicloud Gets Hard (And Honest)

Running workloads in a single cloud is already complex. Running them across two or three — often with on-prem in the mix — multiplies that complexity across every layer:

Networking

• Latency expectations break
• Traffic patterns become unpredictable
• Connectivity becomes mission-critical

Security & Identity

• Policy consistency becomes harder
• Identity sprawl increases
• Shared responsibility models diverge

Data

• Data gravity becomes real
• Governance policies fragment
• Movement and replication costs are underestimated

Applications

• Placement decisions become strategic
• Portability vs specialization trade-offs become unavoidable
• “Build once, run anywhere” rarely holds up

Cost

• Visibility lags reality
• Unit economics differ across platforms
• FinOps becomes a Multicloud capability, not a reporting exercise

This is why Multicloud failures rarely look like outages.

They look like:

• Slow delivery
• Ballooning cost
• Security exceptions
• Operational fatigue

Multicloud Requires an Operating Model, Not Just Architecture

What separates organizations that cope from those that struggle is not tooling — it’s operating discipline.

Effective Multicloud environments share common traits:

• Clear workload placement principles
• Explicit governance (not guidelines)
• Standardized identity and security controls
• Intentional data architecture decisions
• Central cost accountability with local ownership
• Teams trained to understand trade-offs, not just services

This is not about centralizing everything. It’s about clarity:

• Who decides where workloads run
• Who owns cost, risk, and reliability
• Where standardization is mandatory — and where flexibility is allowed

Without this, Multicloud becomes a collection of disconnected clouds rather than a coherent platform.

Why This Matters to Business Leaders

Multicloud complexity doesn’t stay in IT. It shows up as:

• Slower time to market
• Higher operational cost
• Reduced ability to scale AI and data initiatives
• Increased risk exposure
• Leadership confusion about where value is actually being created

In other words, poorly run Multicloud becomes a business drag. The organizations that get ahead are not the ones with the most clouds. They’re the ones with the clearest rules of engagement.

A Clear Point of View

Here’s my perspective:

• Multicloud is no longer optional for most enterprises
• Treating it as a loose strategy leads to chaos
• Treating it as an operating discipline creates leverage

The winners won’t be those who standardize everything or abstract everything. They’ll be the ones who:

• Accept platform differences
• Make deliberate choices
• Invest in operational maturity
• And stop pretending Multicloud is simple

A Question for Leaders

If you asked today:

“Do we know why each of our major workloads runs where it does — and who owns the consequences?”

Would you get a clear answer? If not, the challenge isn’t Multicloud itself. It’s that the operating model hasn’t caught up with reality.

Yet behind the enthusiasm, I hear a quieter, more uncomfortable question:

“We’ve invested in AI… but where is the real business value?”

In my view, AI is not failing because the technology isn’t ready.

AI is failing because most organizations tried to shortcut the hardest part of the journey: fixing their data foundations. Same situation like Big Data platforms 10 years ago.

The AI Conversation Is Too Model-Centric

Most enterprise AI discussions start in the same place:

• Should we build our own models or use foundation models?
• Which model is more powerful?
• How fast can we deploy something that looks impressive?

These are not bad questions — but they are secondary questions.

What’s often missing from the conversation is far more fundamental:

• Do we trust our data?
• Do we know where it lives?
• Do we control who can access it?
• Do we understand how it flows across systems?
• Do we have a shared definition of “truth” across the business?

Without clear answers, AI initiatives become disconnected experiments rather than scalable capabilities.

The “Clean Slate” Fallacy

A pattern I see repeatedly is what I call the clean slate fallacy.

Organizations assume they can:

• Start AI pilots in isolation
• Avoid dealing with legacy data quality issues
• Bypass governance “for now”
• Prove value first, then fix the foundations later

This almost never works.

Why? Because the real value of AI does not sit in generic models. It sits in organizational data and institutional knowledge:

• Customer interactions
• Operational signals
• Process data
• Historical decisions
• Domain-specific context

That data is rarely clean, centralized, or well-governed by default.

When AI is trained or prompted on fragmented, poorly governed data, the outputs may look impressive — but they lack depth, trustworthiness, and differentiation.

That’s why so many pilots stall after the demo stage.

AI Magnifies Organisation Problems — It Doesn’t Hide Them.

Traditional analytics can sometimes tolerate messy data. AI cannot.

AI systems:

• Expose inconsistencies faster
• Amplify data quality issues
• Raise governance and security risks
• Increase the blast radius of bad assumptions

This is why AI adoption feels harder than expected in large enterprises.

It’s not because the models aren’t powerful enough. It’s because AI forces organizations to confront data reality — often earlier than they planned. And that confrontation is uncomfortable.

Cloud Is Necessary — But Not Sufficient

Cloud platforms play a critical role in making AI possible at enterprise scale.

They provide:

• Scalable data platforms
• Managed AI and ML services
• On-demand infrastructure for training and inference
• The ability to experiment and iterate quickly

But cloud does not magically fix data problems.

If governance is unclear on-prem, it will be unclear in the cloud. If data ownership is ambiguous today, AI will surface that ambiguity faster. If integration is fragile, AI pipelines will inherit that fragility. This is why “AI-first” strategies often struggle.

In reality, AI must sit on top of a deliberate data strategy, not replace it.

Why Monetization Lags the Hype

Many executives are surprised by how difficult it is to monetize AI. The reason is simple:

• AI value compounds over time
• It depends on trust, adoption, and integration
• It requires organizational change, not just technical deployment

AI that is not deeply embedded into workflows becomes:

• A side tool
• A novelty
• Or an experiment that never scales

The organizations that see real value do something unglamorous first: They invest heavily in data platforms, governance, and operating models. Only then does AI become transformative rather than cosmetic.

A Longer-Term Perspective Matters

This is where I often think about Bill Gates’ observation:

“Most people overestimate what they can do in one year and underestimate what they can do in ten years.” – Bill Gates

AI will absolutely reshape how enterprises operate. But expecting near-instant, enterprise-wide impact ignores the realities of data, governance, and change.

Those who rush will be disappointed. Those who build patiently will compound advantage over time.

A Clear Point of View

If I had to summarize my perspective simply:

• AI is not primarily a technology challenge
• It is a data, governance, and operating model challenge
• Skipping those foundations leads to shallow results
• Fixing them unlocks durable, defensible value

The real AI leaders in the enterprise won’t be the ones with the flashiest demos. They’ll be the ones who quietly did the hard data work first.

A Question for Leaders

Before approving the next AI initiative, it’s worth asking:

“Do we trust the data this system depends on — and would we bet a business decision on it?”

If the answer is unclear, the model choice won’t save you.

Most large enterprises today run workloads in the cloud. Many have migrated dozens, sometimes hundreds, of applications. Yet when I speak with CIOs and CTOs, there’s a common frustration beneath the surface:

“We’ve moved a lot… but the things that really matter haven’t changed.”

The reason is uncomfortable, but simple.

The real blockers to cloud progress are legacy code and technical debt — and we still don’t talk about them honestly enough.

“The Applications Everyone Is Afraid to Touch”

In almost every large organization, there is a category of applications that quietly controls the pace of change.

They tend to have familiar characteristics:

• Very old codebases, sometimes written decades ago
• Little or no documentation
• No clear application owner
• Tight coupling to legacy databases, middleware, or operating systems
• Vendor support models that assume on-prem environments
• And a business narrative that sounds like: “It’s working. We cannot risk breaking it.”

These systems are not edge cases. They often sit at the heart of revenue, operations, finance, or customer experience.

So, while enterprises talk about cloud-native architectures and modernization, these applications remain frozen in time.

Not because leaders lack ambition — but because the risk feels asymmetric:

• The downside of touching them feels immediate and catastrophic
• The upside of modernizing them feels uncertain and long-term

In that equation, inertia always wins.

Why This Isn’t a Skills or Budget Problem

It’s tempting to frame this as a skills gap, a funding issue, or a change-management challenge.

In my experience, that misses the point.

Most large enterprises today:

• Have access to capable engineers
• Have budgets approved for transformation
• Have strong executive sponsorship for cloud initiatives

What they don’t have is confidence.

Confidence that:

• They truly understand what will break
• The modernization path won’t introduce existential risk
• The organization won’t be left unsupported mid-journey
• The business disruption is manageable and reversible

This is why so many cloud programs gravitate toward:

• New digital applications
• Peripheral workloads
• Greenfield initiatives

Those are safer.

But they also avoid the systems that define enterprise gravity — and that’s why transformation plateaus.

We’ve Framed Legacy as a Customer Problem for Too Long

Here’s the uncomfortable part of my point of view:

We’ve treated legacy modernization as something customers need to “figure out”, with cloud providers standing on the sidelines.

Yes, there are tools. Yes, there are partners. Yes, there are frameworks and methodologies.

But for the most critical legacy systems, the message often boils down to:

“Refactor it, replace it, or retire it — good luck.”

That’s not realistic for systems that:

• Run core business processes
• Lack source code or domain knowledge
• Are bound by regulatory or vendor constraints
• Cannot tolerate extended downtime

If cloud platforms want to unlock the next phase of enterprise adoption, this problem must be owned — not outsourced.

What “Owning the Legacy Problem” Actually Means

Owning this problem doesn’t mean promising magic rewrites or forcing modernization for its own sake.

It means changing the contract with enterprises.

In practical terms, that looks like:

• Deep, automated discovery of application dependencies and risk
• Clear visibility into what can move safely — and what cannot
• Supported paths for running workloads tied to older operating systems or runtimes
• Commercial and operational models that reduce one-way risk
• Modernization approaches that are incremental, reversible, and boring

Boring is a must here. Because enterprises don’t need heroics — they need predictability.

The cloud platforms that succeed long-term will be the ones that make modernization feel less like a leap of faith and more like a controlled sequence of steps. Cloud hyperscalers need to own this problem.

Why This Matters to Business Leaders (Not Just IT)

This is not a technical debate.

When legacy systems block progress, the impact shows up as:

• Slower product innovation
• Higher operating costs
• Limited data accessibility
• Fragile integrations
• Reduced ability to adopt AI and automation meaningfully

In other words, technical debt becomes business debt.

Boards and executive teams increasingly sense this — even if they don’t use the same language.

The organizations that break through are not the ones that migrate the most workloads. They are the ones that systematically reduce fear around their most critical systems.

A Clear Point of View

If I had to summarize my position, simply:

• Cloud adoption does not stall because technology is immature
• It stalls because enterprises are afraid to touch the systems that matter most
• And that fear will not disappear without shared ownership of risk

The next wave of enterprise cloud value will not come from more services or faster regions.

It will come from finally confronting legacy — pragmatically, patiently, and honestly.

A Question for Leaders

If you paused today and asked:

“Which applications are truly holding us back — and why are we afraid to touch them?”

Would you have a clear answer?

That answer — more than any roadmap — will determine how far your cloud journey really goes.

Here are my thoughts for 2022!

Multi-cloud for the wrong reasons

I mentioned multi-cloud in my post in 2019. This time I am looking at the reasons driving multi-cloud strategy. Multi-cloud is mentioned in many conversations, conferences, presentation and IT strategies. Multi-cloud strategy is considered for many reasons. However, I see that multi-cloud strategies are considered some times for ill-constructed reasons or the wrong reasons. Let me address two of the common reasons I hear.

Vendor Lock-in

Enterprises decide to follow a multi-cloud strategy to avoid “vendor lock-in” i.e. to avoid being locked-in to a cloud provider. Going through a cloud migration and transformation journey is a huge undertaking, and a long-term commitment. Hence, selecting the right vendor is important because most probably you are going to spend years working with that vendor and may be decades (I don’t know how cloud will look like in 20 years!). After all, Cloud is the platform for your enterprise IT so entertaining the idea that overnight you can give notice and hire a moving company to package and move to a new house is far from reality.

Also, vendor lock-in is a one type of lock-in. Gregor Hohpe discussed other types in his article Don’t get locked up into avoiding lock-in like Product Lock-in, Version Lock-in, Legal Lock-in…etc.

Architecture Lock-in is a famous example we are facing in IT, when you decide a certain architecture pattern for a new application and you get locked-in for years!

I encourage CIOs and CTOs to reconsider their definition for vendor lock-in and how they perceive “vendor lock-in” within the other types of lock-ins and embrace the long-term relationship.

Availability

I have seen conversations online that cite cloud outages as a reason for multi-cloud strategy. I don’t agree with this because any architecture must be ready for platform failures. Werner Vogels, Amazon CTO, said “Everything fails all the time”. You need to think about your architecture resiliency, high availability. AWS offers services over multiple availability zones or regions. The AWS Well-Architected helps cloud architects build secure, high-performing, resilient, and efficient infrastructure for a variety of applications and workloads.

If you spread your workloads across multiple cloud platforms, you are increasing the architecture and operations complexity and not directly addressing availability challenges.

Things to consider when you are thinking of multi-cloud

Skills and talent:

Architects, developers and engineers need to be fluent in more than one cloud platform. It is difficult to get your head around a single platform, what about two or three platforms. When I was a developer, it was not easy to be fluent in many development languages!

Operating model:

You need to think about your operating model, operation processes, and the choices for observability, management, security, and governance cross the multi-cloud operations. This will stretch your team and adds complexity to your operation producers. Do you agree?

Value realisation:

Enterprises think of multi-cloud as an exit strategy so when the business wants to move from a cloud vendor the other, it can be done. In order for this strategy to work, Architects will always have to consider “cloud portability” in the architecture. Portability will push you towards decisions like avoiding cloud native services or avoiding capabilities that don’t exist in the other provider. These decisions push the architects to settle for the lowest common denominator among the selected cloud providers, and the architectures will not benefit from the new innovations.

Connectivity

Enterprises are investing in cloud adoption. Connectivity is a key consideration. What is the latency, what if the available region is far, bandwidth requirements…etc.

Investments in connectivity is an important factor in increasing cloud adoption and unlocking new workloads and use cases. Werner Vogels included ubiquitous connectivity in his 2022 predictions citing Amazon’s Project Kuiper of delivering fast, affordable broadband to unserved and underserved communities around the world. Telco providers are investing in 5G infrastructure, and AWS announced its new Private 5G service.

Unlocking connectivity constraints will unleash another level of cloud value and increase adoptions.

Data mobility and Open Data APIs

Data is the centre of gravity of any workload and it is a value creation for business. Businesses start with a business model, and using the data they collected, they are capable of offering new services, and value added to their clients. Data in cloud platforms takes many shapes and formats, and with the virtually unlimited compute and storage in public cloud, Data is more valuable.

I predict the growth in investments in offering services to smoothly move data between cloud platforms, creation of virtual data mesh across platforms, which will offer data to consumers through Open data APIs. This will be offered as a service for Enterprises to unleash the power of the data and enables new business models.

Definitely data privacy and security will be a key topic for this!

Continuous abstraction of cloud services

In 2006, AWS started with EC2 instances and continued the innovation and abstractions of services for builders. For example, the introduction of Lambda services removed the worry about any infrastructure to execute code. Moving up the application stack will continue and becomes faster. In re:Invent 2021, AWS introduced Amazon Redshift Serverless to run analytics at any scale without having to manage data warehouse infrastructure. I expect abstraction will continue across services and abstraction will go up in the platforms stack, where we see services are integrated and abstracted from builders then they can focus on the business problems rather than the plumbing.

I would love to hear your opinions. Do you agree or disagree with these predictions or do you have other observations to share?

“Opinions expressed are solely my own and do not express the views or opinions of my employer.”

I liked the talk because it was not typical sales pitch about a product (i.e. Snowflake) but Frank shared his experience as a CEO on what his expectations for CIOs and he doesn’t want them to do. The talk provides a first-hand experience and advice.

I thought of summarizing in a different way, rather than writing an article about it, I drew simple handwritten mind maps to capture the key points of the talk.

Following the mind maps. I would love to get your feedback if you find it useful and easy to follow on the key message from the talk.

Excuse me for any typos or brevity in the drawings.

Originally posted in Linkedin profile here

Last year I shared my predictions for Cloud platforms on 2019. They were focused on three points Multicloud, cross workloads integration and development of cloud governance models.

In 2019, Multicloud becomes a recognised term and #multicloud is commonly used hashtag on twitter, with many conferences and events running all over the world to discuss how multicloud can help businesses (IDC MultiCloud Summit 2019, VMWare and Pivotal committed to multicloud)

In my opinion, Multicloud is still at its early stages and on the diffusion on the innovation model, it is still in the innovators phase and getting closer to the early adopters phase!

In a couple of days it is the end of 2019, and the end of a decade of a furious war between cloud providers. We have seen innovation from AWS and Microsoft for around 13 years and 10 years respectively that transformed the shape of the industry and cloud technologies.

I see the next decade is about serverless and portability! My predictions for next year (may be years)

Multicloud will grow and moves to mainstream

CTO and IT Directors will continue exploring Multicloud. Discussions and design patterns around Multicloud will continue to grow in the industry. Many vendors will start developing services, products and solutions around the Multicloud models. These services are required to deliver design patterns, operating models, technical architectures, management tools…etc

Whether we agree or not, the key drivers for Multicloud would be to avoid vendor lock-in and benefit from the strengths of other cloud platforms.

It will be easier to go to Multicloud

Death of “Lift and Shift” and the rise of “Hybrid Cloud” – Less workloads will move as-is to the cloud, more Apps modernisation

Nearly two-thirds of companies report they have not achieved expected cloud benefits (Accenture June 2019). It has been challenging for many enterprises to realise the benefits of the cloud. In my opinion that this is due to two main reasons:

1. The business case of the cloud was always about cost reduction rather than supporting business objectives.
2. The operations and architecture of cloud platforms are different from traditional data centers architectures. Applications design should be different to benefit from the cloud capabilities

Most enterprises started by lift and shift of workloads without any re-architecture to the cloud (let’s scoop them and move ASAP) and they realised that costs could be more expensive especially for mission critical workloads and that requires high availability. Also, they have been hit by different types of challenges on how to secure the cloud environments and dealing with an underlying stack that is owned and managed by the cloud provider.

I see over the next year, the lift and shift will start to fade out. Hybrid Cloud will rise! Enterprises will leave existing workloads on-premise, setup a hybrid architecture, and develop new workloads on the cloud using modern cloud native architecture patterns (Serverless!).

I see a new pattern for moving to the cloud to become more prominent. I call it “Peeling the Onion” pattern :). It is the flow explained above and I will discuss it in a separate article

Hybrid setup -> New workloads go to the cloud -> old workloads stay on premise till decommissioning or modernise on the cloud.

Cloud Portability – the rise of new tools and services to move workloads across cloud platforms

With the growth of Multicloud and increase of the maturity of its architectures and tools, Enterprises will be looking to be easily move workloads between different cloud platforms to benefit from new features, new contract terms…etc.

I understand this may sound outrageous as usually changes in applications and architectures are not that frequent. However, since more enterprises are pushing to be more agile and the modern cloud architecture and based on services (i.e. Lego blocks) that are integrated together, I see that there will be a need to move between cloud providers for different reasons and sometime moving parts of applications to a cloud e.g. move the analytics stack to cloud B and leave operational stack on cloud A.

With these needs on the horizon, and the adoption of new open standards for cloud services like the Open Application Model developed between Microsoft and Alibaba Cloud for developing and operating applications on Kubernetes. it will be easier to cross the river to the other side!

The development of open standards for different types of services (e.g. serverless, bots, containers, storage, data lake…etc) will unlock new opportunities. There will be new services and tools that would allow the workloads to move seamlessly or upgrades based on these standards. May be a new startup idea here!

I use the analogy of changing my gas and electricity provider every year using a comparison website (without a single phone call!). The experience for me is seamless and hassle free which was not achievable years ago.

Conclusion

My predictions may not necessarily be only for 2020! It may take more years to be realised. The winner who is going to pick up on the weak signals of change and adopt their services, operations and business objectives to benefit from the upcoming changes.

It’s Not the Big That Eat the Small…It’s the Fast That Eat the Slow – Jason Jennings

Disclaimer – Opinions expressed are solely my own and do not express the views or opinions of my employer.

images: “Designed by Freepik”, Water photo created by freepik

Last I read 5 books, This far behind my annual target of 12 books. I need to get better in 2020.

The Barcelona Way: Unlocking the DNA of a Winning Culture – by Damian Hughes

In The Barcelona Way, sports psychologist Damian Hughes reveals the key principles that have defined FC Barcelona’s success and shows how the DNA of a winning team can be successfully applied to any working environment, with dramatic results. ‘A powerful book on the important principles of creating a high-performing culture.’Eddie Jones, England RFU Head CoachFC Barcelona are one of the most successful football clubs in the world. What makes FCB unique is the winning culture that has delivered sustained success for much longer than the customary four-year cycle of an elite team. Lying at the very heart of their success is how they deal with people and the care and attention given to the environment in which those people are nurtured: practices which are of equal relevance to all organizations trying to channel the activities of their talented individuals for the corporate good.The key principles are: Big Picture, Arc of Change, Repetition, Cultural Architects, Authentic Leadership. These are the same principles that are adhered to in successful working environments across any industry. Drawing on interviews with key architects of the culture, as well as his own extensive experience as a sports psychologist working with leading sports and business institutions, Damian Hughes provides unique insights into the crucial issues confronting the modern corporate environment, and shows how the lessons learnt at FC Barcelona can also be applied to develop your own winning culture.

The Outward Mindset: Seeing Beyond Ourselves by The Arbinger Institute

The Arbinger Institute has helped millions with their books Leadership and Self-Deception and The Anatomy of Peace. Their newest book, The Outward Mindset, reflects their latest research and experience and offers a new and intuitive way to teach people how to implement mindset change in themselves and scale it across organizations, with incredible effect. One’s mindset governs how one views the world, what one does, and how one does it. One’s mindset can be self-focused, which Arbinger calls an inward mindset, or it can be inclusive of others, which Arbinger calls an outward mindset. It turns out that our own actions, and others responses to those actions, end up being dramatically different depending on which mindset we are operating from. The Outward Mindset teaches readers how to shift more fully to an outward mindset and how to help others, even whole organizations, to make that shift a shift that sparks innovation, increases accountability, and transforms collaboration, engagement, and fulfillment.”

Life 3.0: Being Human in the Age of Artificial Intelligence by Max Tegmark

How will Artificial Intelligence affect crime, war, justice, jobs, society and our very sense of being human? The rise of AI has the potential to transform our future more than any other technology–and there’s nobody better qualified or situated to explore that future than Max Tegmark, an MIT professor who’s helped mainstream research on how to keep AI beneficial. How can we grow our prosperity through automation without leaving people lacking income or purpose? What career advice should we give today’s kids? How can we make future AI systems more robust, so that they do what we want without crashing, malfunctioning or getting hacked? Should we fear an arms race in lethal autonomous weapons? Will machines eventually outsmart us at all tasks, replacing humans on the job market and perhaps altogether? Will AI help life flourish like never before or give us more power than we can handle? What sort of future do you want? This book empowers you to join what may be the most important conversation of our time. It doesn’t shy away from the full range of viewpoints or from the most controversial issues–from super intelligence to meaning, consciousness and the ultimate physical limits on life in the cosmos.

Originals: How Non-Conformists Move the World by Adam M. Grant

In Originals the author addresses the challenge of improving the world from the perspective of becoming original: choosing to champion novel ideas and values that go against the grain, battle conformity, and buck outdated traditions. How can we originate new ideas, policies, and practices without risking it all?  Using surprising studies and stories spanning business, politics, sports, and entertainment, Grant explores how to recognize a good idea, speak up without getting silenced, build a coalition of allies, choose the right time to act, and manage fear and doubt; how parents and teachers can nurture originality in children; and how leaders can build cultures that welcome dissent. Learn from an entrepreneur who pitches his start-ups by highlighting the reasons not to invest, a woman at Apple who challenged Steve Jobs from three levels below, an analyst who overturned the rule of secrecy at the CIA, a billionaire financial wizard who fires employees for failing to criticize him, and a TV executive who didn’t even work in comedy but saved Seinfeld from the cutting-room floor. The payoff is a set of groundbreaking insights about rejecting conformity and improving the status quo.

Bad Blood: Secrets and Lies in a Silicon Valley Startup by John Carreyrou

The full inside story of the breathtaking rise and shocking collapse of a multibillion-dollar startup, by the prize-winning journalist who first broke the story and pursued it to the end in the face of pressure and threats from the CEO and her lawyers. In 2014, Theranos founder and CEO Elizabeth Holmes was widely seen as the female Steve Jobs: a brilliant Stanford dropout whose startup “unicorn” promised to revolutionize the medical industry with a machine that would make blood tests significantly faster and easier. Backed by investors such as Larry Ellison and Tim Draper, Theranos sold shares in a fundraising round that valued the company at $9 billion, putting Holmes’s worth at an estimated $4.7 billion. There was just one problem: The technology didn’t work. For years, Holmes had been misleading investors, FDA officials, and her own employees. When Carreyrou, working at The Wall Street Journal, got a tip from a former Theranos employee and started asking questions, both Carreyrou and the Journal were threatened with lawsuits. Undaunted, the newspaper ran the first of dozens of Theranos articles in late 2015. By early 2017, the company’s value was zero and Holmes faced potential legal action from the government and her investors. Here is the riveting story of the biggest corporate fraud since Enron, a disturbing cautionary tale set amid the bold promises and gold-rush frenzy of Silicon Valley.

My favorites of the year and highly recommended:

• The Barcelona Way: Unlocking the DNA of a Winning Culture – amazing stories on leadership and how Pep managed a team of stars
• The Outward Mindset: Seeing Beyond Ourselves – I love this series including the other Leadership and self deception. It cultivates certain traits and behaviors that are required in all organisations!
• Bad Blood: Secrets and Lies in a Silicon Valley Startup – fascinating true story on the abuse of power and how startups can create monsters due to the lack of governance and strong charisma, Be Aware!

Happy New Year!

Access the article here
https://gdpr.cioapplicationseurope.com/cxoinsights/iot-edge-computing-opportunities-and-challenges-nid-1035.html
or
https://www.cioapplicationseurope.com/magazines/May2019/GDPR/#page=44