In enterprise software marketplaces, each participant vendor contributes specialized expertise, functionality, and scale that are essential to building a complete solution for end users—assuming of course, that no single monolithic vendor would as efficiently meet customer needs.

Before software marketplaces, end users would buy software built specifically for their own vertical, such as ‘healthcare clinic management’ or ‘point of sale terminal system’ — or hire a consultant to customize a bespoke solution, since most enterprises didn’t have a deep enough development bench to do it themselves.

Development partners are precious

Consumer software marketplaces are well known, because they live on our smartphones: Apple App Store and Google Play have the markets cornered for their OS users.

These closed economies hit app developers with a 30 percent commission on each transaction, whether for purchasing the app, or even in-app transactions such as game tokens and add-ons. Developers who don’t want to pay the toll simply won’t have their apps listed.

Needless to say, publishers don’t like the arrangement. Epic Games vs. Apple are still in court today after the popular Fortnite game got kicked off the App Store for having its own internal payment system. European Union regulators are now looking at breaking up such monopolies.

In an enterprise software marketplace, application partners are highly valued, because no vendor’s system is an island unto itself. Encouraging a developer ecosystem creates more choices for end customers, who need to add new functionality that integrates with existing systems.

Vendors now get exposure to the world’s largest cloud services market at a low cost ranging from 1.5% to 3% depending on average sales volume. Even if vendors on the AWS marketplace offer functionality that overlaps with AWS alternatives, that’s fine, because AWS still sells more cloud infrastructure either way.

Across the pond, the Atlassian Marketplace generated more than $500M in annual sales by 2022 for their partner developers. Because Atlassian didn’t impose an extreme tax, they were able to bring together a strong set of vendors building add-on software specifically customized for their suite of tools such as Jira, Confluence and Bitbucket.

The wall of modules and integrations

Most enterprise software marketplaces started out as gadget collections. They are not well-planned, arising out of a necessity to provide adapters to the most likely external systems and core systems in play within the end user’s IT environment.

Back in the turn of the century, I designed B2B marketplaces, most of which failed alongside companies like Pets.com in the dot-bomb implosion. Enterprises with tight IT budgets started to expect vendors to include SDKs and integration modules so they could hook up their existing software packages for free.

Salesforce led the way with a marketplace of add-on services to its core CRM platform. Later, we saw the rise of major business process automation, analytics and low-code app design vendors all offering a gadget wall of partner integrations in their own marketplaces.

Even citizen developers were starting to get in on the game, building solutions from a storefront of LEGO-like vendor pieces with snap-to-fit integration ease.

The rise of API, open source and AI

The widespread adoption of SaaS software and cloud services led us to an API-driven consumption model, which changes the game. Instead of building custom integration models for each platform, vendors publish an API spec, allowing developers to build services that connect to it.

Soon, walls of custom integration widgets gave way to API marketplaces, and a surrounding host of related devtest, management, identity and orchestration apps to govern their use.

Open source software underwent its own revolution, with downloadable packages on npm and API integration code in SwaggerHub and git repositories. Open source marketplaces allow developers to contribute innovative efforts to the community in order to benefit development practices as a whole.

GenAI chatbots and image generators are all the rage today, but AI models are even better at speaking the language of API connections than mastering the complex subtleties of human conversation. AIs can act as integration platforms, allowing even non-technical workers to call on a vast array of services, including other AI models behind their own APIs, with natural language queries.

The Intellyx Take

I could go on forever about the subtleties of software marketplace design and economics, which would be outside the scope of this column. 

For instance, I could talk about intra-enterprise marketplaces that allow IT departments to provision employees and provide platform engineering services to developers, with interdepartmental accounting of the value delivered against budget allocations. But enough of that.

As software marketplaces expand to meet future enterprise needs, the most successful ones will hold their vendor communities close, rather than abandon developers or suddenly game the rules against end customers.

The post Analyst View: Do we need enterprise software marketplaces? appeared first on SD Times.

Even if we were aware that generative AIs like ChatGPT can ultimately generate bullshit, as my colleague Jason Bloomberg says, and we know they are getting overhyped across social networks and overvalued by vulture capitalists, nobody could have predicted the excitement the public and press would feel once they glimpsed the future.

We’re seeing AI work its way into everything—almost every platform or software product has put some form of generative AI magic into the mix. No vendor wants to be late to the party.

Governing AI in development

IT executives are wrestling with how to safely govern the use of AI in their development groups. Maybe they don’t realize it’s technically already being used by most developers in their IDEs, for starters, in the form of autocomplete and code co-piloting. 

Then further, we are seeing natural language chatbots being used as ‘no-code wizards’ that can automatically generate the ‘best usual’ code for many component aspects of an application and its infrastructure-as-code specifications from a starting prompt. 

After all, no developer is interested in coding their own permissions or horizontal autoscaling, if there’s already something ready to go – they would much rather focus on the differentiated application functionality they are incentivized to build.

Even Stack Overflow is incorporating a ChatGPT natural language prompt feature for generating code based on code that was contributed by other developers. What could go wrong with this recursive loop?

If there are bugs, or security flaws in the generated code, we’d expect human developers to thoroughly check for them. But we all know that’s easier said than done when teams just want to move faster.

The IP proprietary cliff

The entertainment and publishing industries are already launching lawsuits and even worker strikes to buck against the use of ChatGPT as a virtual writer and visual AIs like Midjourney, which are trained on bodies of existing copyrighted works.

Early proponents of AI-generated writing attempt to handwave this concern away, saying something about a new job description for ‘prompt writer’ being a new role that is simply the human using the AI as another creative tool.

So if a company has AI-generated code in their codebase, who should be credited as the author? Do they have the rights to use that IP in their product or business? I would say the future here looks murky. Automated routines have been thoroughly scanning codebases for patent infringements ever since MS-DOS was a thing. Now imagine them armed with the latest AI patent trolls, which can automate this job a thousand times faster than the old search tools, uprooting even more hidden liabilities, and filing threatening settlement letters.

Even if partially generated code doesn’t contain a clear patent violation, a vendor would have a very hard time defending generated code as proprietary work – and it is likely that the code they actually authored could be used for machine learning in someone else’s AI model.

Will AI displace developers?

It’s the most frequent question we are asked by developers in 2023. My answer right now is that AI will settle in and mostly replace the kinds of development work that no developers want to do.

For instance, an AI makes quick work of helping data scientists become productive without having to massage and meta tag data. For software training, an AI can act as an infinitely patient tutor and pair programming assistant for bringing junior devs up to speed.

The quality of documentation many tools can instantly create from almost any application, or even a stack of paper, is mind-blowing. Still, that doesn’t mean we’ll stop needing technical writers and educators – they’ll just continue to move their value upstream to the newer aspects of making better decisions about using our application estates.

Because of the known factual hallucinations and IP issues of an AI model trained on codebases scraped off internet repositories, I don’t think AI will ever fully displace development work in most sectors of the economy. In fact, it is likely to bring even more of a new class of low-code developers into the market who have less technical skill but more business acumen.

The Intellyx Take

Even I’m starting to wonder, as our most miserly clients tell us: “Why don’t I just get ChatGPT to write your analysis for free instead?”

Sure, maybe you should use a chatbot to replace me—if you aren’t afraid of the reputational risk that might occur when your audience realizes they are reading auto-generated content, filled with silicon dreams.

No chatbots were used to write this content, as the editor told me he could tell if I did. At the time of writing, none of the vendors mentioned here are Intellyx clients. 

The post Analyst View: Is AI coming for software development? appeared first on SD Times.

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.

Until recently, analysts would lump low-code in with no-code and a host of tools offering some form of drag-and-drop ease that enables ‘citizen developers’ (meaning: non-developers) the means to deliver apps. But where should you start in thinking about your own enterprise’s journey to low-code?

Looking at the rate of investment and vendor acquisition in the low-code solution space, it seems like this arena has never been hotter. But in another sense, it’s always been with us.

Ever since the first desktop applications appeared, software companies have sought a way to endow professionals who didn’t have the time or inclination to learn C with the ability to build and design functionality.

Before RAD and 4GLs appeared on the scene, there was Visio and some VB tools on Windows, and Hypercard on the Mac. Even Excel started a revolution among skilled spreadsheet wizards armed with a few macros. These early forms of low-code were pretty localized in orientation, predating the explosion of content yet to come via internet services.

Low code is on a continuum 

According to my colleague Jason Bloomberg, low code is on a continuum between no code (tools requiring no coding at all) and pro code (tools that ease developers in reusing code or leveraging development skills).

There are parallels between the low-code spectrum of ‘assisted development’ solutions and the closely related business process automation and testing spaces, which share several commonalities, including a business user-centric or ‘no-code’ point-and-click simplicity on one end, and an engineering-centric ‘pro-code’ side.

In fact, we have seen several assisted development players arise from testing or automation tools that found their stride in low-code.

What will drive further low-code adoption?

Low-code solutions arose from the natural desire of every business to get ‘all hands on deck’ and become productive in delivering on the needs of customers, given constrained IT resources and budgets.

Beyond that desire, there are several major challenges that call for a low-code approach:

Maintainability. By far, technical debt is the granddaddy of low-code challenges. The need to maintain existing systems and retire or refactor obsolete or malfunctioning application code takes up the bulk of most established companies’ IT resources.

Low-code tools must add features that are modular, interoperable and especially maintainable, so developers aren’t left trying to pick up the pieces within a muddled, object-disoriented code dump.

Integration. Many low-code tools started out from an integration perspective: allowing teams to stitch together and move data between multiple tools or services to provide new functionality that wasn’t readily available before. 

Low-code solutions should include both internal core systems and external services into workflows, without requiring users to understand how to construct their own APIs. Always try digging past the ‘wall of logos’ and make sure the CRM or OMS you already own can be effectively supported for end customers.

Security. SecOps teams are extremely resource constrained, and have difficulties figuring out exactly how to authorize conventional development teams for environment access, much less giving low-code citizen developers appropriate access.

Ideally, modern low-code solutions can ease this security management burden, with role-based access controls assigned for team and functional responsibility levels. Fail to do security right, and you will either get hacked, or get Rogue IT as teams run off to do-it-anyway without draconian oversight.

Functional integrity. Manually coded processes and rote processes hidden within monolithic silos need to be rebuilt by business domain experts inside the prospective low-code platform.

Whether the new functionality is vertical or horizontal the low-code platform should provide adequate ‘safety bumpers’ in the form of pre-flight testing and early monitoring and feedback, so owners can be alerted if any application is going off track.

The Intellyx Take

If low code was just about reducing labor costs or IT resource constraints, the space would gradually be consumed by adjacent development tools becoming easier to use, or automation tools becoming robust enough to define applications. 

Bringing the intellectual capital of business expertise to bear within our application estates might just be the biggest game-changer for the future of low code. Wherever the code road ends, a new opportunity arises.

Hey, thanks for reading! Why not watch my archive of the latest 2022 LC/NC Developer Day session now?

The post Hopping on the low-code locomotive 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.

The post Analyst View: Shift testing left, but bank right appeared first on SD Times.