But wait, how many Kubernetes experts do we have? We’ve got an industry-wide shortage of skilled software development and operations talent—and the complexity of cloud native development is exacerbating the problem. We’re not going to hire our way out of this mess!

Skill shortages stymie cloud native innovation

Even non-technical executives now understand the basic benefits of cloud native software. They know it has something to do with Kubernetes pushing out containers, so the resulting applications are more modular and take advantage of elastic cloud infrastructures.

There’s way more to it than that. The cloud native landscape is a beehive of open-source projects for configuration, networking, security, data handling, service mesh – at various maturity stages. There are also hundreds of vendors offering their development, management and support tools atop this ever-moving CN raft.

A developer’s learning curve is steep and continuous, since this year’s stack might no longer be relevant next year. Outsourcing is tough too, when the few consultants with a real knack for cloud native development are busy and expensive.

The only way to sustainably grow is through building cloud native development talent and capabilities from within, following the introduction and maturation of the space, as well as keeping tabs on the vendor and end user community at large.

While the market demand for digital offerings keeps doubling every couple years, IT budgets often get a budget belt-tightening as a reward for managing and scaling so much technology.

Smaller and leaner teams are expected to deliver twice the output with half the people. The need for specialized skill positions only increases as concepts like event-driven architecture, data lakehouses, real-time analytics, and zero-trust security policies turn into production-grade requirements. 

Why platform engineering matters

No matter what target environment they are contributing to, developers still spend most of their time coding within an IDE. Over the years, vendors have tried everything from low-code tools to process toolkits to lower the skills bar, but the pipelines don’t translate into easy wizards. 

Complex open-source tooling, third party service APIs, and code that is being mixed and matched from GitOps-style repos are driving cloud native development teams toward a new platform engineering approach.

Platform engineering practices seek to create shared resources for development environments–encouraging code, component, and configuration reuse. 

Common platform engineering environments can be represented within a self-service internal development portal or an external partner marketplace, often accompanied by concierge-style support or advisory services from an expert team that curates and reviews all elements in the platform.

It’s critical to govern the platform’s self-service policies for access permissions, code, logic, data, and automation at just the right level of control for the business it supports. 

Too much flexibility ends up creating overhead, as diverse stakeholders fail to distinguish between the relative value or usefulness of so many unvalidated and poorly categorized components of the platform.

Too much rigidity in policy design can create the opposite problem, where centralized governance and approval cycles for every element slow down solution delivery and take away the innovative freedom developers crave.

A modern approach to cloud native platform engineering can finally bring the principles of governance, consistency and reuse to the table.

Speedy innovation through infrastructure abstraction

Refreshingly—or maddeningly—there’s no single right way to ‘do’ cloud native. Even Kubernetes is by itself just an abstraction of container orchestration and only one option for going cloud native.

As an open-source movement, the CNCF purposely leaves the future approach open to interpretation by the community. It doesn’t dictate a particular language, or even a specific piece of infrastructure. 

That’s excellent, but it also leaves short-handed dev teams managing complex plumbing and experimenting with integration options, rather than building better functionality. That’s where platform engineering practices can save the day.

The decision to create a platform is a commitment to help developers of varying skill levels abstract away the complexity of underlying cloud native architectures with interfaces and tools atop readily configured environments.

A platform engineering approach must offer ease of use, elimination of toil, and reduced cognitive load for development teams—helping orgs attract and retain the best talent.

The Intellyx Take

Truly innovative ideas that impact customers represent a core competitive differentiator, and should grow from within the enterprise. That’s difficult when the supply of skilled cloud native development resources is constrained.

Fortunately, platform engineering organizations and technology stacks can automate some of the most difficult work of delivering on the needs of API-driven microservices environments.

The post Patch the cloud native development talent gap with platform engineering appeared first on SD Times.

What was so intriguing to so many about Web3 anyway? Since nobody could really agree on exactly what it was, it could literally be whatever aspiring entrepreneurs imagined it to be.

Common threads appeared. Blockchain. Bitcoin and Ethereum. DeFi. Decentralization of organizations, infrastructure and data. Freedom from tech giants. Self-sovereignty. Privacy. Opportunity.

All the kinds of ideals that generate charismatic personalities. 

Who cares about maturing cloud adoption or better integration standards, when you can explore a whole new economy based on blockchain, cryptocurrency and NFTs? Why wouldn’t tech talent leave standard Silicon Valley-funded confines to live this Web3 dream?

When a space is overhyped and undefined, it encourages the rise of the worst kinds of actors. Web3 never had a chance, with its uncertain crypto-economic roots and the use of blockchain technology, which hasn’t proved adequate for enterprise-class business.

Crypto-Schadenfreude: Sham, bank run & fraud

Nobody enjoyed more of a media darling status in the Web3 world than FTX founder Sam Bankman-Fried, who famously played video games on investor calls and shuffled around the tradeshow circuit in shorts, as he donated millions to “effective altruism” charities and crypto-friendly politicians.

Now Sam’s been arrested and set for extradition from the Bahamas to face charges in the United States, with FTX the most famous failure among several other falling dominoes (Lumen, Celsius, Gemini, on and on) in the crypto rug pull. 

It was fun to mock celebrity shill ads, but it’s not funny to see $2 billion in investor deposits disappear into the ether. A lot of VC whales, other DeFi companies and hapless individuals were also duped and parked their funds there too.

There’s no cash reserve regulation or FDIC account insurance in place for crypto, so when buyer confidence eroded, market makers sold, accelerating the ‘rug pull’ effect. Ripples collapsed as much as $183B or more from the total market cap of cryptocurrencies.

Turned out, there’s nothing new about this Ponzi scheme, a Madoff-like phenomenon my analyst colleague Jason Bloomberg has commented on ad infinitum, even appearing as a gadfly at crypto conferences to say it has little use except for criminal enterprises like money laundering and ransomware, to audience hecklers.

Blockchains looking for solutions

Besides cryptocurrency, the most common term we hear in Web3 discussions is blockchain, which is a distributed ledger technology (or DLT) underpinning Bitcoin, Ether, Dogecoin, and thousands more dogshitcoins.

If cloud was just ‘a computer somewhere else’ then blockchain is more like ‘an append-only database everywhere else’ due to its decentralized consensus mechanism and cryptography. Even the first Bitcoin blockchain proved resilient to hacking unless someone finds a way to steal user account keys through other means.

Though I’m a skeptical analyst, I admit thinking there was some sleeper value in blockchain, if a few properly governed projects came along that could create safer, smoother rails to adoption.

We’ve seen vendors with very nice use cases for distributed ledgers, particularly in multi-party transactions, IP and media rights, legal agreements and audits, and proof of identity, where a blockchain can use a combination of transparency and immutability to provide a decentralized, shared system of record – whether nodes are exposed publicly or among permissioned parties.

That still doesn’t make blockchain a valid replacement for modern databases and data warehouses, which already offer enterprises more scalable back-ends for applications, with better security and governance controls.

The slow, energy-sucking processes of mining, recording and storing parallel blockchains haven’t proven sustainable for business use cases besides tracking a few heads of lettuce with e.coli on them.

The Intellyx Take

The main roots of Web3’s failure weren’t about technology, they were about misaligned incentives and the inevitable association of Web3 with crypto and NFT market madness. 

Unethical players could rise to the top, confidently claiming top-line growth, and attracting continued fundraising investments without mentioning the inevitable crash.

I’ve met early participants in the blockchain space with intentions for a better world with unique computing models and applications particularly well-enabled by decentralization. They weren’t building mansions on islands and taking crypto-bros out on yachts.

Who knows? Once the incentives and risks of easy money are washed out of the market for good, maybe the dream of global access to a new, decentralized internet of applications and value could someday be realized.

The post Web 3: New scams for new kids on the blockchain appeared first on SD Times.

Programming is not a belief system – it’s part of computer science for a reason. There is a systematic approach for improving development expertise, gathering and analyzing data, and proving or disproving that the software works. Logic and data are codified in software and in our processes around creating software.

The human influences of societal norms or religion should have little to do with the quality or performance of the software a group of developers can churn out.

Ideology precedes architecture

A particular ideology for codifying technology sets an organization apart from its peers. When team members share beliefs and behaviors, the resulting products can gain consistency in design and utility that ‘just makes sense’ to customers who resonate with the approach.

The company’s founder, or an executive can set the tone for an organization of course – think Steve Jobs or Andy Grove. But for software development, an ideology is usually more than a cult of personality. 

Development teams with shared ideology can perceive and respond to opportunities and challenges as a group, like flocks of birds that seem to magically change direction.

The codification of the group’s encouraged and discouraged behaviors can take many forms, including a predilection for certain technologies or methodologies. In this sense, an ideology establishes an organizational intent that influences the architecture of delivered software.

A services methodology is not an ideology

A lot of services companies tout an overarching Agile or DevOps methodology, a ‘customer first’ mentality, or ‘proven processes’ for delivering great work. A skeptic sees these as branding exercises to give clients confidence and recruit better developers.

As analysts, we have a hard time evaluating and comparing services offerings as they relate to product value, except when they relate directly to product delivery and training, or operationalization of a SaaS solution for customers.

Open source collaboration magic

Open source projects start out as a kernel of code in a repository, and a code of conduct for founding the community of current and future contributors. 

Open source believes in a shared collaborative ideology and democratizing access to non-proprietary platforms, thereby leveling the playing field for individuals to build solutions atop them. Societies to benefit from the resulting innovation.

Attending an open source conference, the ideology of an agreed-upon code of conduct for treating each other with respect supersedes any actual discussion of code and components. Projects that lose their collaborative energy become toxic and get abandoned, as contributors take their talents elsewhere.

Design-first versus product-first

I covered the quandary of design versus product-led development modalities in my previous column on design-led versus product-led delivery teams. 

Design-led ideologies lean on developer intuition, the healthy competition of ideas, and fast iteration to constantly improve the software customer experience, whereas product-led development focuses on constantly delivering and improving features that meet customer demand. 

These modes of thinking coexist productively within many orgs. Engineering and operations groups may be able to bridge the gap between design and product orientations by crafting shared models that represent their commonalities, giving them a common language to mix the best of both worlds.

Inclusive versus exclusive

An ideology of making ‘software for all’ – users and employees of all skill levels, cultures, and abilities – sets a high premium on user experience and accessibility. The world’s most widely accepted products are practically self-explanatory and built upon this mindset.

Conversely, many software vendors cater unapologetically to expert practitioners only, or for industry specialists who bring deep domain knowledge. There’s value in delivering the right tool for the job after all.

No-code, low-code and pro-code development tools offer a spectrum of these ideologies in action.

Coding for global good

Ever since Google quietly dropped its own ‘don’t be evil’ mantra more than a decade ago, I’ve been skeptical of companies that say they exist to improve the greater good. The recent trend of ESG (environmental, social & governance) has been co-opted as the latest form of ‘greenwashing’ by corporate entities seeking to publicize their environmental concerns. 

Still, if such goals make data centers increase efficiency and run on renewable energy, and cause logistics vendors to reduce overall emissions by optimizing truck routes, that’s inherently good.

An AI company developing healthcare or self-driving cars can set out to save human lives, and the resulting software will be more likely to do so if it matters.

The Intellyx Take

A useful development ideology is not just defined, it is cultivated by a group over time. It is not something that corporate leadership can dictate.

In today’s fast-paced world, merged companies never retain their ideological foundations for long, as principal collaborators move on, engaging their efforts and beliefs in the next startup.

Strong ideologies, like proven methodologies, are built and reinforced from within. If ideologies resonate with customers when codified as code, later teams can inherit them for useful purposes.

The post Codifying software: An ideological perspective appeared first on SD Times.

I once pondered an alternative product-driven strategy for software organizations to behave more like high-growth software vendors, recasting their project managers as product managers. They would spend less time measuring time, and more time measuring the features they deliver.

Ostensibly, this product-oriented approach would cut down on endless initiatives and sprawling scope creep, by getting executives to reconsider the contributions of developers toward finite high-value products.

A finished product implies reusability, and higher potential value for more use cases than the work output of a project. 

But lately we are seeing a second shift – from product-led to design-led strategy. Some of the founders of today’s fastest growing unicorn vendors emerged from design schools and creative industry backgrounds.

Costume, or customer experience?

There’s a lot of technical and business acumen that a design-led team must develop beyond graphic design that goes into a successful customer experience.

Designers get asked to put ‘lipstick on a pig’ – pushing pixels to dress up an application visually without changing the underlying functionality. The cosmetics of tweaking icons, fonts and colors can make the software look nicer, but it seldom improves user experience (or UX) by itself.

Users expect clear controls and instructions within an interface, and on their phones or devices, they also expect sensory data – using cameras, haptics and audio inputs and outputs to maximize productivity.

Performance is also a huge factor in customer experience – an identical competitor that displays results two seconds slower will experience high abandonment rates. Design engineering is about tradeoffs between display aesthetics, and the concise representation of data returned rapidly from low-latency sources.

When it’s incomplete, it’s ready to show

INABIAF. It’s not a bug, it’s a feature, goes the old developer maxim when software users don’t understand what they are seeing on the screen. 

Successful creative agencies never assume that a concept needs to be fully fleshed out before clients can accept it. They iterate rapidly on design and copy comps or sketches, in order to zero in on the client’s preferences, as well as measuring the preferences of end consumers.

Revolutionary SaaS tools and smartphones apps accelerated design-first principles, as the current version of the application gets dynamically updated for the customer in near real-time. This continuous process merges redesigns into the CI/CD product lifecycle by introducing new user functionality and displays – even if they aren’t fully baked yet. 

‘Shift-Right’ practices such as real user monitoring (RUM) and feature flagging are great ways to gauge performance improvements and test functional integrity, but the biggest benefit is getting live customer feedback into the product design loop.

Laziness is the mother of innovation 

If great design takes 50% of the time required to perform a task away from the customer, that’s a winning product that frees up a drastic improvement in productivity.

The low-code space and RPA movements provided hundreds of ways to leapfrog between UI and process-driven design and drag-and-drop easy application development without the technical skill hurdles. 

The COVID crisis showed off the robustness of low-code for design-driven responsiveness to crisis conditions – take for instance the few banks that could step up with PPP relief loan applications using low-code within 3 months. 

Development teams themselves also enjoy design-centric tooling. I’m constantly surprised by new vendors that enter seemingly matured spaces such as CI/CD tools, IT operations, security and software testing with better UX as the lead value proposition.

Designing a diverse team

We are all complex, autonomous beings, operating in different modes as end users of technology. When designing technology for others to use, we must wear a functional engineering hat. A customer service hat. A security hat. A human-centric hat.

Leading creative organizations favor higher levels of diversity within their teams, not just in terms of ethnicity and identity, but in the different intellectual perspectives that variety produces. 

There are many unique ways of solving problems, and therefore there should be different types of thinking within your team’s makeup by design. Embrace these differences and cultivate them for design-driven success.

The Intellyx Take

Companies and industries that are internally project-focused rather than customer-focused are woefully unprepared for digital transformation.

Never settle for dogmatic standards when rapid innovation is called for. 

Don’t let anyone tell you there is one best way to build software when there are always multiple valid design-led approaches. Distinguishing between conceptual possibilities is the very stuff of design-led development.

The post Software development: Product-driven or design-led? appeared first on SD Times.

I have here the seeds of Intellyx’s 2021 retrospectives and 2022 predictions. Unlike most other pundits, we try not to state obvious observations as predictions, and we score ourselves on last year’s crop of conjectures.

Predictions from 2021

Appreciating Sir Issac Newton’s theory of gravity, I collected three apples that fell on Jason Bloomberg’s head for his 2021 Intellyx prediction set. Let’s see if they had gravitas.

First off, a dramatic counter-cyberattack against Russia in response to attacks like the SolarWinds hack. 

This one didn’t bear fruit–If anything, the rate of exploits and breaches in IT continued apace, crowned in December with the revelation of the widespread log4j vulnerability. 

We did see preventative effort and innovation from vendors attempting to ‘shift security left’ in the DevOps lifecycle to make it a developer concern, and open source collaboration toward wiring zero-trust, least privilege fundamentals into the underpinning componentry of microservices-based applications.

Second, the massive Bitcoin-Tether Ponzi collapse didn’t happen yet–but all the conditions needed have intensified tenfold. Times of economic uncertainty and a mistrust of institutions drove celebrity shills and unsuspecting marks to throw down real money for magic blockchain beans.

With over half of crypto exchange activity now circulating through stablecoin shell games, this failure is not a question of if–but when–the rug gets pulled.

Last, the pandemic and recession ending with a bang instead finished with a series of sputters and pops, as an inability to truly shake COVID-19 put a damper on economic relief and constrained global business operations. 

But in terms of IT, the wait-and-see period of 2021 gave way to an explosion of innovation and consolidation, especially in cloud-native, edge, and AI technologies, showing no signs of slowing down. 

Better still, workers in the digital economy made the greatest gains in 2021, as collaborative lessons, work-from-anywhere capabilities and a serious talent shortage meant many IT employees could afford to job-hop and demand better salaries and flexible working conditions from employers.

Predictions for 2022

First, a great weeding out of vendors. Overvaluations in the space will gradually give way to more responsible ways of evaluating the potential success of any vendor. Enterprises will become wiser about ROI metrics and refine their selection criteria to fit their desired architectural goals.

Vendors that can demonstrate value for paying customers will be poised to accelerate, while the fortunes of runners-up in each category will decline, resulting in layoffs and surprise fire sales.

This does not mean startup activity will decrease in 2022. Volatile conditions offer the most fertile ground for sprouting innovation to improve agility at scale and meet customer needs.

Observability will branch out into many forms. This solution category has consumed aspects of software performance, security, testing, development, issue resolution, planning – and all of the data and infrastructure supporting it.

Observability is no longer just for SREs obsessed with production. It must process data feeding ITOps, network analytics and AI learning tools, as well as assisting developers with many aspects of legacy modernization and migration. What specific kind of observability is needed for the work at hand?

Supply chain management will start to enter the IT mainstream discussion. Coordinating the many moving parts of SCM has always been a dark art beyond IT, even for the people running the cogs of supply chains — manufacturers, logistics providers, warehouses and retailers.

Even though software is just a bunch of bytes, responsible orgs will consider software and hardware supply chain dependencies in every architectural aspect of planning and provisioning digital capabilities.

Real global supply chains will also become the #1 growth market for edge computing and IoT. New combinations of device and sensor data will flow into tracking, analytics, AI-based forecasting, production planning and multi-party networks to modernize legacy SCM networks and ERP systems (many haven’t changed much since the nineties).

The Intellyx Take

I could have easily predicted that cloud adoption would grow, or another massive breach – but that would be like opening a fruit stand that sells store-bought fruit.

What will remain constant this year is change, and the determining factor of an organization’s survival will be its reaction speed for applying new technology to meet the chaos that change creates.

To make it in 2022, organizations must value people more than ever to negotiate change, and listen to the experiences of employees, partners and customers – above the preferences of their own executives and shareholders. Success is there for the picking.

The post 3 apples in 2021 vs. 3 oranges in 2022: Predictions appeared first on SD Times.

I’ve spent most of my life working with technology firms where testing was an unassailable virtue, and therefore, the concept of testing was constantly encouraged. Now, it seems like many companies are pushing QA upstream to customers.

The stakes for quality are still high. So why has software testing gotten such short shrift lately?

Test teams have changed

Remember when there used to be a QA team, separate from the development team in any decent-sized IT shop with a software delivery function?

This QA team staffed as many as one tester for every 3 to 10 Dev and Ops people. Test-driven development encouraged earlier unit and regression testing burdens to be shared between teams.

Unfortunately, first-to-market pressures truncated QA teams that faced ever-shortening test windows, and retained little authority to ‘stop the presses’ for quality issues. Many companies abandoned QA teams in favor of mingling testing and development. Who wants to be the buzz-kill that stopped the killer software release customers expected?

Test roles have changed

The sunset of the QA team also means we don’t have a ‘Head of QA’ any more. Titles containing “QA Specialist” or “Tester” became scarce about a decade ago. In a DevOps world, the testing function is increasingly integrated into pair programming or small Agile team exercises.

Some companies encouraged more coding on the part of testers, and more testing on the part of engineers, eventually leading to the rise of the ‘SDET’ (or software development engineer in
test) cross-functional role.

If developers must test their own code, and testers must become developers, who will independently validate that the software meets business requirements? Perhaps a magic testing box?

Test tools have changed

The grand age of automated testing tools has subsided. Richer freemium tools, and then, open-source software took over for the huge enterprise licenses sold by the likes of Mercury and Rational
and Segue from the Y2K testing days.

At this point, software observability became a hot new space, and testing lost its shine. Gartner even discontinued Continuous Testing as a product
category altogether.

Punting responsibility for testing

“There’s a tricky balancing act between QA and development,” Chris Cardinal, principal at CarbonQA, told me. “If you say ‘we’ll just let our customers test the software,’ I hope that it doesn’t come back to bite you royally. An entire brand can turn on bad app store reviews.”

Today, testing must still find a home within your process, or total failure will certainly catch up with your organization. That leaves several options:
Offload it to a new QA team. Why not restart with a tiger team of expert testers?

Offload it back to development. Better make sure they are incentivized for quality, not just speed.

Offload it to a tool. Test automation tools keep getting better, but don’t believe 100% unattended claims.

Offload it to a services firm. Benefit from specialized test vendors with their own expert methodologies and tool stacks that work closely with your team.

Offload it to customer support. Everything’s gonna be alright.

Offload SOME testing to your customers. Establish a beta tester program or try A/B, feature flagging and canary testing to shift-right. It’s not best for all workflows, but it may be the best real-
world test feedback you’ve ever had.

The Intellyx Take

This trend of hidden testing — and thinking we can hide testing — will pass. In the meantime, it’s kind of fascinating to watch how organizations can adapt and survive the change.

The post Why hide testing from development? appeared first on SD Times.