Low-code and no-code tools enable development teams to speed up their time to market by reducing the amount of code that needs to be written, enabling reusable code blocks, and automating things like testing and security.

Though we at SD Times primarily cover the software development industry, low-code cannot be confined to just one department. In fact, Gartner predicts that by 2026, 80% of the user base for low-code tools will be non-IT users. These days, you can find low-code tooling in the hands of accountants, HR professionals, business analysts, and more. 

Clearly, low-code has proven its worth. That’s why, for the third year in a row, we’re hosting Low-Code/No-Code Developer Day, a free virtual event taking place on 4/12 where you will learn all about how you can apply these tools in your own organization.

The event will kick off with a keynote from Jason English, analyst at Intellyx, who will first attempt to break through all the marketing buzz and get down to what functionality you should be looking for in tooling. 

Other sessions will focus on: 

• The specifics of low-code for developers, with Joyce Lin at Postman
• How to correctly set up your low-code environment so that you don’t have to redo things later on, with Kevin Lewis from Directus
• How low-code can be used to abstract away the complexity of cloud native, with Jonas Bonér of Lightbend
• A real world example from the IT director of a manufacturing company which has built 28 apps using low-code tools to automate manual processes, resulting in app maintenance time being reduced from 50% to 10% of time, 4-10x faster development, and $350k/year in savings.  

And you won’t just leave the conference with abstract thoughts to ponder on. We’ve also got two hands-on sessions planned. You’ll have the opportunity to learn how to better master your data with Microsoft Power BI and how to use the open-source low-code programming language Ballerina. 

Join us on April 12 for this free event by registering here. 

The post How to level up your low-code game appeared first on SD Times.

Gartner predicts that by 2027, 75% of enterprises will use SRE practices organization-wide to optimize product design, cost and operations to meet customer expectations, up from 10% in 2022. Today, more than ever, customers are expecting applications to be reliable, fast and available on demand. When organizations present products that do not meet these expectations, customers are quick to seek other alternatives. 

To improve product reliability, IT organizations are starting to adopt SRE principles and practices when designing and operating systems. However, SRE is rarely embedded into every product’s development life cycle. While software engineering leaders are engaging site reliability engineers, they are only performing occasional reliability exercises. 

Foster Collaboration With Site Reliability Engineers

Now is the time for software engineering leaders to be building lasting partnerships with site reliability engineers as a part of their continuous quality strategy by adopting SRE practices and tools. Software engineering leaders will only be able to deliver the business value of their products to customers if they are treating reliability as a differentiating feature. 

Software engineering teams should be addressing reliability issues early on in their product’s life cycle and collaborating with site reliability engineers throughout the entirety of a product’s design and delivery activities. Doing so is more time-efficient and economical than needing to resolve a product’s issue after it has been released. 

Collaboration with site reliability engineers can be fostered by defining service level indicators (SLIs) and service level objectives (SLOs) that capture customer expectations for both product reliability and product performance. SLIs and SLOs will allow teams to clearly evaluate how well a product is meeting customer needs.

Enforce an SLO Action Plan

Failure is an inevitable aspect of service delivery, so it is important that software engineering leaders have a plan of action to effectively manage risk. Design an action plan for each SLO with site reliability engineers. This plan should provide guidance on what needs to be done if an SLO is breached, trending toward breach and/or the breach is imminent.

Optimize Development and Design with SRE Practices

To further a culture of reliability within their teams, software engineering leaders need to incorporate SRE practices and tools that drive lasting improvement. There are several activities software engineers should be performing with site reliability engineers in order to optimize development and design for meeting SLOs and SLIs: blameless postmortems, chaos engineering, toil management, and monitoring and observability. 

Blameless postmortems can be used to identify what is causing triggering events such as failure or SLO breach. This practice allows organizations to learn and avoid repeating the same mistakes, and prevent future ones. Chaos engineering uses experimental failure testing to uncover vulnerabilities. This provides information about system behavior during failures and enhances software engineering teams’ ability to improve product design. Toil management eliminates low-value work and repeatable tasks. Lowering toil allows teams to focus more on meeting SLOs. Monitoring and observability identifies the best methods needed to measure SLIs and SLOs.

These technologies will allow software engineering teams and site reliability teams to work collaboratively to improve their ability and solve reliability issues. Software engineering teams need to work closely with site reliability engineers to help define SLOs, share accountability for meeting SLOs and adopt SRE practices and tools.

The post Software engineering teams must collaborate with site reliability engineers appeared first on SD Times.

The tech industry in particular has been impacted by these volatile conditions in the market and in the workforce. Following The Great Resignation, which saw employees leaving their jobs at heightened rates, there were also a number of highly publicized large layoffs at companies like Amazon, Meta, and Stripe, not to mention half of Twitter being laid off upon being taken over by Elon Musk. 

To help these marketing leaders plan ahead, the research firm Gartner has published three trends that it believes marketing leaders will need to face in 2023. Being aware of the challenges can help leaders understand the best ways to move forward and be successful in meeting their goals. 

“As CMOs enter 2023, the current environment demands a relentless focus on customer value, purposeful evolution of the marketing function, and continual optimization of brand value,” said Ewan McIntyre, chief of research in the Gartner Marketing practice. “In order to meet the enterprise mandate of driving growth amid continued disruption, CMOs must act decisively to prioritize their investments and their strategy for the year ahead.”

The first trend the analyst firm identified is that customer behaviors will shift and drive more uncertainty. 

Inflation has contributed to a lot of changes in consumer behavior, such as 30% of consumers opting for the store brand and a fifth of consumers replacing more in-person shopping visits with online shopping. This was according to a survey Gartner had conducted in September  2022, in which it spoke to over 1,500 consumers. In order to overcome this challenge, companies will need to focus on maintaining brand preference, premiums, and loyalty. 

Consumers and B2B will also withhold more of their personal data, which will make it harder for marketing teams to track demand or offer multichannel engagement. Incoming regulatory and technical changes, such as the removal of browser cookies and new privacy features in iOS and Android, have the potential to make the current marketing strategies obsolete. 

“Marketing leaders should create a digital customer value exchange to provide mutual value on digital channels throughout the full cross-channel journey,” McIntyre said. “Enhance the effectiveness of digital marketing by seeking opportunities for personalized engagements that genuinely help customers throughout their end-to-end customer journeys.”

The second trend is that cross-functional collaboration will actually result in worse outcomes. 

The company did a study in March 2022 and found that companies who describe their approach as “independent” outperform those who identify as “collaborators” by almost a quarter in annual revenue. 

According to Gartner, marketing priorities have become enterprise-wide and now include complex cross-functional execution. One result of this is that having shared priorities across a company can draw funding away from marketing departments. Many of these departments still haven’t recovered to their pre-pandemic budget numbers. Further restrictions will result in lower performance in reaching critical marketing goals. 

“CMOs must adapt team structures and skills to advance new cross-functional operating models. Streamline operations, establish common key performance indicators (KPIs), and orchestrate messaging throughout the customer experience for greater effectiveness of marketing, sales, and other customer-facing teams,” McIntyre said.

The third trend is that traditional sources of brand value are being disrupted by things like new market entrants, heightened audience expectations, and the ease of being able to learn about unfamiliar brands online. 

Over half of the employees and consumers that Gartner surveyed over the summer said that it’s “less important to choose a well-known brand today than it was 3 years ago.” The survey also found that 75% of audiences have searched online for information about a previously unknown brand, and only 15% of audiences report a strong brand commitment. 

Established brands will need to reposition themselves in order to stay competitive in the market. All brands will need to explore emerging channels and innovative strategies in order to stay relevant. 

“CMOs must redefine and quickly demonstrate the value of brand investments in a volatile environment,” McIntyre said. “The strongest driver of brand commitment is a single meaningful brand experience, even with unfamiliar brands.”

The post Three trends marketing teams need to be aware of in 2023 appeared first on SD Times.

Developer experience refers to all aspects of interactions between developers and the tools, platforms, processes and people they work with, to develop and deliver software products and services. In order to create a superior developer experience, software engineering leaders must provide an environment in which developers can do their best work with minimal friction and maximum flow.

Software engineering leaders working towards improving their team’s developer experience should follow these three actions.

 Improve Developer Journeys

Developer experience extends beyond developer tools and technologies. Building and retaining a high-performance development team starts with a positive onboarding experience. A streamlined onboarding process enables developers to make meaningful contributions much faster, which in turn makes the entire team more productive.

Creating a frictionless developer onboarding experience will improve overall developer experience. For software engineering leaders, it is important to ensure that developers are equipped to get started on day one. Be sure to provide a fail-safe environment that is immune to accidental errors. Create a sense of belonging and camaraderie.

Developer self-service can also improve developer journeys by reducing process inefficiencies and, in some cases, eliminating unnecessary processes entirely. Self-service development workflows can be streamlined through the use of internal developer portals. Developers benefit from accelerated feedback loops, as they enable developers to continually improve code quality and understand what is working and what is not. By establishing feedback loops, developers are able to experiment, measure progress and continuously improve. The feedback helps improve their deliverables, as well as their ways of working. This shortens the time to value, thus providing quicker insight on value delivered from the user’s perspective. 

Optimize for Creative Work

To improve developer experience, software engineering leaders must go beyond optimizing development workflows and provide focus time for deep, creative work along with the freedom to fail and experiment.

A collaborative work environment is a crucial ingredient of developer experience, since software engineering is a team sport and involves multiple team members and teams. Teamwork and collaboration amplify original ideas and shorten the cycle time from idea to production. Collaboration between team members lends emergent properties to the team.

Fostering communities of practice can help create an open and collaborative work environment. Practitioner-led communities are fundamental to open, collaborative and effective learning. People own what they help create and work together to address challenges. Software engineering leaders must encourage their teams to create communities of practice through active engagement, regular activities, member focus, collaborative problem solving and a powerful strategic vision.

Be a connector manager who enables cross-pollination of ideas and skills. Connector Managers create a trusting and transparent team environment that supports peer-to-peer coaching. 

Finally, leverage automation for repetitive tasks to free up time for creative work. Automating away the routine and repetitive aspects of software engineering enables developers to focus on applying their creativity to solving problems. Developers should indulge in ideation, build new solutions, collaborate and communicate with their peers, partners and customers rather than maximizing the time available for writing code. 

Make a Meaningful Impact

Although most organizations focus on improving developer journey, developer experience in the long term goes beyond software development workflows. It involves giving developers the opportunity to make a meaningful impact. 

Foster a culture where developers don’t feel embarrassed to admit a mistake, ask a question, or offer a new idea. Psychological safety is the top predictor of high performance in software engineering teams. A number of organizations have reported that psychological safety  is a key characteristic of a high performing team.

The post 3 key actions to improve developer experience appeared first on SD Times.

According to Yishai Beeri, growth technologies lead at LinearB, the best way for organizations to utilize RPA is to implement it with the purpose of eliminating the mundane tasks that would usually fall to developers. 

He also explained how this technology works to ensure consistency across a development team. Beeri said, “Developers have their own skills, they can automate basically whatever they like if they put their time into it, but sometimes, you want a more organized or central solution for automating these things instead of every developer just scripting away,” he said. “Maybe it’s not important enough for a single developer but if you look at 100 developers…the small time wasters are things that you can automate away with a more centralized solution.” 

Carlos Melendez, COO and co-founder of Wovenware, echoed Beeri’s sentiments by explaining that organizations would much rather have their developers working on tasks that bring value to the company rather than spending the majority of their time on duties that could easily be automated with something like RPA. 

Melendez also explained that when implementing RPA, this is the message that can fight off the employee resistance that may come from the fear of losing their jobs to automation technology. “A lot of the time it’s not about replacing employees, it’s about augmenting their capabilities. So, if half of your time is spent kind of preparing a file or preparing an integration or moving data from one point to another or doing data entry, then you want that person to spend more time on their analysis and verifying what is happening instead of the actual data entry part,” he said. 

RPA still new, and evolving

Jon Knisley, principal consultant, automation, and process excellence at FortressIQ, said that RPA and other automation technologies are still relatively new and, therefore, rapidly evolving. He said, “Among companies that have deployed RPA, a majority have less than 10 bots in production and just 10% have launched more than 100 bots, according to a recent report from Automation Anywhere.” With this, he added that he believes that the full breadth of what RPA and automation in general can do is still undiscovered. 

“Only 11% of business executives surveyed by McKinsey believe their current business models will be economically viable through 2023. Given the potential disruption, organizations continue to invest in complex change programs despite dismal success rates of less than 30%. Automation is the new transformation,” Knisley said. He also noted that RPA has been the fastest growing segment for the enterprise software market for three consecutive years beginning in 2019. “Grand View Research estimates the global market for RPA will surpass $2 billion in 2022 and continue to grow annually at 40%,” he said. 

Arthur Villa, an analyst at Gartner, said that his company’s research has yielded the same results, saying that he has seen no evidence that RPA has been slowing down, even in the midst of newer technology. “[As far as] the state of RPA implementation, I would say that it is still in the relatively early days. If we look at it as a four quarter game we’re probably only in the second quarter… I think that there’s still a lot of adaptations that have been made in the last couple of years,” he said.

With this, Villa pointed out that RPA has only been growing in popularity as larger and more well-known organizations introduce this technology. “A lot of these new vendors are coming into the RPA market and shaking things up. There’s a lot happening within the market especially from the customer and buyer perspective… Many companies start small with RPA and then they rapidly expand those programs so I think we’re still early on in new customers buying RPA and beginning to experiment with the technology,” he said. 

Villa believes that the reason RPA has been so widely accepted and implemented is because it offers organizations simplicity and overall convenience. According to Villa, when compared to other AI solutions, RPA is lower in cost, easy to understand, and companies will usually see a quick return on investment. 

Data, change management challenges

In spite of this, though, it is not uncommon for organizations to face some challenges when introducing RPA into their business processes. According to Melendez, these challenges often fall into two categories: data driven and change management. Melendez explained that the data aspect of these challenges has to do with the quality of the data itself as well as overcoming the different types of roadblocks that arise when you try to automate using bad data. The change management sentric challenges have more to do with employees being worried about what RPA is going to do and how it will change their own jobs. 

When working to remediate these challenges, Melendez said, “Technology is moving so fast that you really need a good set of technology partners that you can trust, that you can go to when you need certain technology solutions. You have your AI partner, your RPA partner, and other partners that will help you navigate the complexities and the changes in those technologies.”

From RPA to IPA (not the pale ale)

The conversation around RPA has shifted slightly in recent years in order to cast a wider net, the newer terminology is Intelligent Process Automation (IPA). The low-code automation company Nintex has been championing it, and according to Terry Simpson, senior solutions engineer at Nintex, “IPA is like the grownup and more mature sibling of RPA. When we say sibling, think about IPA being about 20 years older than its younger sibling RPA, on the maturity scale.”

Simpson continued, “IPA is actually the combination of several technologies coming together to create a very mature and flexible automation capability. Intelligent workflows, natural language processing, machine learning, and even RPA are all integral parts of an IPA solution.” He explained that a key difference between RPA and IPA is that while RPA usually runs on a local machine, IPA is a cloud-based virtual environment. “In simple terms, think about IPA sitting right in the middle of all your applications and performing process automation focused on an entire solution, not just tasks. Tasks may make up a piece of the solution, but IPA brings the entire solution or process together,” he said. 

Brett Greenstein, data and analytics partner at PwC said, “RPA is getting less discussion… because automation has expanded well beyond screen scraping and bots, through the use of APIs, Microservices, and AI/ML. Many companies have adapted to this by expanding the term to IPA to include those newer capabilities as well as process mining.”

Greenstein explained that in the current environment the need for automation is only growing. In the midst of the great resignation and a shortage of skilled developers, automating tasks using a smarter solution is quickly becoming a necessity rather than a luxury. This increased demand for automation has led to the expanding of RPA into IPA in order to introduce fresher technologies into an already reliable method of automation. 

RPA as communication tool

Beeri thinks there is a new role that RPA can fill in the face of a more distributed workforce. He said that RPA can be used as a communication tool that can remind developers of when it is time to take the next step. “A lot of the work that software developers do as a team is a lot of back and forth and communication between people… so coordinating that in an environment where it is mostly asynchronous and we’re not in the same room anymore… automation and smart bots can really help in coordinating this ‘dance’ between people so that people are not interrupted,” he said.

Beeri said that even though this is not a task that has been done in the past or a role that used to be filled by a separate employee, it has become important with the trend we’re seeing towards working remotely. He said, “It really helps to minimize interruptions and maximize speed when working together on things.”

According to Villa, only a few organizations are currently experiencing the full benefits of RPA that Beeri is referring to. He believes that the majority of companies utilizing this technology are the ones that are generating high volumes of revenue, meaning that small and mid-market organizations have yet to adopt automation technology. He said, “There’s still a lot of education that has to happen within mid-market companies that need to understand ‘what is RPA? How can it be used? And how can I get the most bang for my buck?’”  

Knisley also pointed out that education around RPA and automation is essential when trying to implement it in the most effective way possible. However, he also placed an emphasis on the importance of fully understanding and optimizing the company itself before introducing automation. He said, “To achieve the magical future state promised by technology, companies first need to understand their current state. Unfortunately, most companies do not understand how they truly operate especially at a gradual user activity level. To be successful and avoid false starts, companies need to discover, re-engineer and automate — in that order.” 

RPA has fallen out of the spotlight over the past few years

Even with RPA’s rapid growth, it is noteworthy that it has fallen out of the spotlight somewhat in recent years. According to Geenstein this is the result of newer technologies being introduced. He said, “First, there is the screen scraping and click automation that allows RPA to execute the same steps a person would execute in any application. Second, there is the scripting for bots that identifies a sequence of actions with basic logic to decide what action to execute next. As APIs and microservices become more and more available, especially as applications modernize on the cloud, the need for screen scraping and click automation goes away.”

Along the same lines, Beeri said that he feels RPA is not as widely talked about because, at its inception, it was overhyped and now it is failing to live up to all of the original promises. “I think when you start to look at how to deploy [RPA], and what tasks need to be removed, you’re finding that you can change the actual task, you don’t stop at just putting a robot in to automate data entry… The solution for the problem at that point might not be RPA, it might just be automating something using no-code or low-code methods,” he said. 

However, Melendez credits this lack of discussion to something different. He said that rather than RPA being at the center of the discussion, people have shifted to speaking more generally about automation. “RPA as well as AI is becoming so prevalent that the conversation is no longer about deploying RPA, it’s about the solution that we are going to deploy [using RPA],” he said. Melendez explained that because these tools and technologies are so advanced, not only is it assumed that they will be in place, but that it is also assumed that, in most cases, they are going to be able to easily automate whatever is necessary. 

Automation and humans need to work together

On an SD Times-led discussion of RPA on the Discord “Dev Interrupted” server, participants had a lot to say. One of the respondents, Dr. Don Wilcox, talked about a robot used at his organization, which they named Marvin. “We have automation that completes a Task (the most-specific sort of ticket) when a PR associated with that Task is completed,” Wilcox explained. “Then Marvin takes over and changes the state of the parent story based on whether the dev tasks, qa tasks, demo tasks, etc, are complete. Marvin has his own row on the board, and you can get him to perform certain automation tasks (such as adding the standard stories and tasks to a new sprint) just by giving him an appropriately named task in that sprint.” 

This is a good example of the way that automation and human employees have to work together. There’s no doubt that the addition of the robot makes things run more smoothly but the robot cannot function without the direction of the human, which was the overall consensus from the discussion. The idea that RPA or another form of automation will be the end of human labor is far from the truth.

In further support of this, Wilcox said, “Once you build a robot, someone needs to maintain, enhance, QA, replace. That robot assumes it’s own product lifecycle, which will likely require humans. For the foreseeable future, it is going to be humans building the robots, even if the robots help.” 

The post RPA: Handling mundane tasks, freeing up developers appeared first on SD Times.

In the meantime, C-level managers are primarily concerned with innovation, creating new products and enhancing old ones. So there is a natural divide when it comes to assessing how productive developers are.

Eric Minick, vice president and head of product at CodeLogic, said, “I think what a lot of our developers would celebrate most is, if someone said, ‘Today, I took 300 lines of code that were a mess, and I consolidated it down to 40 lines of code that are clean. And so my net code for the day was minus 260 lines. And that would be celebrated wildly. And so lines of code is about as toxic a measure as you could come up with, as it encourages bad behavior.”

RELATED CONTENT: How CodeLogic helps make developers more productive

“You know, a development team or an IT shop, looking at that developer who took that 300 lines of mess and turned it into 40 lines of elegant clean code, as being productive,” he continued. “Somebody in a business suite, however, might say, ‘You are not advancing our product, you added no new features, nothing happened. How are you being productive?’ “

Gartner analyst Thomas Murphy explained, “We advise clients that they should not be focused on individual productivity metrics – software is about teams – thus we look at team productivity and things are measured more in agile terms of Story Velocity, but that is useful more to understand a backlog and how long it will take.”

It’s this misalignment between the business and IT that continues to exist — despite the ideals of Agile development and DevOps that should bring the sides closer — that makes defining developer productivity difficult. It is Minick’s opinion that from a measurement point of view, most development teams have yet to make business outcomes their goals. Organizations might be using OKRs or KPIs to say that in the next six months, we’re going to improve conversion rates by 5%. But developers are saying, ‘We’re still closing 100 tickets a week, we are good at our jobs.’ Minick said, “I don’t think most organizations have really tightened up the alignment to bring the business metric into the definition of success for the application team. But we’re starting to see the beginnings of that.”

Gartner’s Murphy said, “From a metrics perspective you should be shifting away from metrics that are ‘output’ driven and to metrics that are ‘outcome’ driven.  Thus are we delivering the business outcomes – which means it isn’t just an engineering thing.”  

One thing that organizations have started to embrace in an attempt to make developers more productive is the notion of the developer experience, with the belief that giving developers the best possible employment experience increases their productivity. That experience can range from things like the chair they sit in, the size of the monitors they use while working, the software tools they are given to do their jobs, and the hours they put in.

“There’s nothing more frustrating than having to close down a bunch of apps just to start running your tests and get your own software to run, and being constrained by a cheap laptop, or a monitor that’s too small or anything like that,” Minick said. “You want loyalty from your developers. Give them a powerful box and a big screen, like step one. Step two … big investment in better chairs, standing desks, all of these things that set up the developer to be comfortable, alert, helping and able to concentrate for a long time on their code and be effective.”

After that, he said, make sure they’ve got the right tools at their disposal. Make sure they’ve got a good development environment, that they’ve got the other software packages they need.

Changing roles for developers

One of the difficulties in assessing developer productivity is the fact that their job is much broader than it was in the days when developers primarily wrote and maintained code. Now, they’re more involved in testing, more involved in security and in compliance and governance.

Minick said measuring things like features delivered by the development team is better than measuring the amount of code generated. And, organizations that take productivity seriously will put in place measurements for ‘good behavior,’ such as how code coverage is changing, and is technical debt increasing or being reduced. Or, he noted, crediting developers for taking something highly complex and streamlining it to something simpler. While there was no feature added by that work, the technical debt score should go down, and that would be the productive activity.

A productive development team, according to Minick, will deliver features, mitigate risk, and fix bugs. “You want to make sure you’re balancing your investment in a development team pretty well across those things,” Minick said. “If you’re delivering no features, you’re probably failing. At the same time, if you’re delivering only features and accumulating a tremendous amount of technical debt and risk, you’re setting yourself up for failure in the future. And it’s really a business decision how to weigh that investment, but that should be done consciously, and too often, it’s not.”

How to make development teams more productive

One of the ways organizations can increase feature flow is through value stream management, with which they can identify the impediments that slow productivity and work to remove them. “So metrically, this is where the DORA metrics come in, or the Flow Framework, and this is what comes into a ‘Value Stream Management’ system,” Murphy said, “but with this you are also looking at what are the bottlenecks. ‘Ahh, it takes two hours to provision a test system, that limits how quickly we can build and test software — how can we make that faster.'”

This is especially true as it pertains to the various tools developers need to be productive. There are communication tools such as Teams and Slack, CI tools, IDEs, test tools, code repositories and security tools. Some of this tool sprawl is necessary, Murphy said. “I have to have an IDE, a compiler and such,” he said. “The hope would be that I don’t have Teams and Slack and email for communications.”

Many organizations have more than one tool for continuous integration, which could be because teams have the freedom to select the tool they feel is best to do their job. Murphy noted that Gartner has seen a shift toward choosing standard solutions and tools that take a more integrated approach. “More clients are buying Jira/Confluence/Bitbucket/Bamboo… than did in the past, where it may have been Jira/Confluence/Git-something/Jenkins/Artifactory,” he said, adding that this will be a slow evolution, because of sunk investments and personal preference, but that organizations want to control their spend, be more efficient and have the ability to move resources between teams.

This is another aspect where the business and IT seem to be at odds, though organizations are recognizing the value of having business knowledge in and with the technology. The way many of them are meeting this challenge is through retraining. CodeLogic’s Minick said that’s the best way to go, as opposed to hiring more developers, “because you have the knowledge of business in those people, and you want to keep that in house.” This approach can keep the deep business understanding of how the business works as close to the developers as possible.

Gartner’s Murphy said organizations do a mixed job of providing time and resources to support learning and upskilling, which is leading to growth in informal training — communities of practice, dojos, use of StackOverflow, and more use of pairing and mentoring. “Entities are having to rethink strategies and tools to support how new people are onboarded, how to get effective knowledge transfer and how to evolve employees,” he said. “But this also means you have to be prepared to train them in the new hot technology, pay them more, or (risk losing them).”

A matter of trust

It’s critical that IT and the business have trust, so that when the business asks IT why something will take six months to complete, the answer is framed in such a way that the business can decide if it wants to proceed down that path or not. According to Minick, you’re starting to see more product management people put into that intersection.

Business talks about how quickly features and bug fixes can be released. But developers talk about velocity. Velocity, as any student of physics would recall, is different than speed. “Velocity is a vector, velocity has direction,” Minick said. “And what we really need is speed in the right direction. That’s why people are pulling in the SME [subject matter expert] knowledge to business, to better make sure that when we write a lot of code … it’s what the business wants — and more specifically, what they need. And that often requires someone who has a good understanding of the business to translate from what the business says, which may not be precise enough or clear enough. There may be very ambiguous language to actual features that development can build that will actually push the application and therefore the business in the right direction.”

The crushing demand for modern apps

The demand by the business for new applications and modern experiences far outstrips the availability of developers to do the work — a labor shortage that has plagued IT in the United States for nearly two decades. Combine that with the growing complexity of modern applications and the near-constant introduction of new platforms, technologies and modes of interaction, and — Gartner’s Murphy said — overloaded engineers “have a  feeling of, ‘Here, let me toss a few more bricks on the hod.’ 

This, he said, is part of the reason that there is such growth in low-code solutions, to ease the burden on “pro-code” developers. The solutions, Murphy said, support “that fusion team where developers create new services and components and citizen developers compose those into business applications.”

Keep it as simple as you can

In the face of all this, Murphy suggests organizations do what they can to simplify things. Among the steps they can take are reducing the number of tools where possible, and being consistent in business direction/objectives so you have a unified set of activities that everyone is actioning toward.

Going forward, organizations are looking to AI-assisted coding to help with productivity, but Murphy noted that will “take a while to perfect.” In the meantime, he said, “toolchains will be a bit messy, and our ‘legacy challenge’ of unforeseen needs of the future will always dog us.”

A guide to developer productivity tools

Developer productivity encompasses the use of many different kinds of tools — a comfortable chair and two big monitors, for example. On the software side, developers need tools for writing code, integrating code changes, testing, putting security around their work, and more. What follows is a sampling of tools in each productivity category.

Code repositories

• Bitbucket
• ClearCase
• Codebase
• Eclipse
• Git
• GitHub
• GitLab
• IntelliJ IDEA
• Java.net
• Netbeans
• Perforce
• SourceForge
• Subversion
• Visual Studio 

DevOps platforms

• Atlassian Bamboo
• AWS Code Pipeline
• Azure Pipelines
• Bitbucket Pipelines
• Broadcom
• CircleCI
• CloudBees
• Codefresh
• Digital.ai
• Harness.io
• Jenkins
• LaunchDarkly
• Optimizely
• Split Software
• TeamCity

Collaboration tools

• CodeLogic
• Codenvy
• Codestream
• Engine Yard
• JetBrains
• SmartBear

Communication tools

• Google Mail
• Google Meet 
• Microsoft Teams
• Slack
• Trello
• Zoom

Testing tools

• Applitools
• Applause
• Eggplant
• HCL Software
• Mabl
• Parasoft
• Progress Software
• Sauce Labs
• Testim
• Tricentis

Security tools

• Aqua Security
• Bridgeview
• Checkmarx
• Contrast Security
• Sonatype

The post Measuring developer productivity isn’t as simple as it sounds appeared first on SD Times.

Recent Gartner research has found that there are a high number of open positions for people with advanced development skills, but relatively few candidates per position. Software development leaders often write into the job description a long list of required skills, making candidates even harder to find. All these factors require organizations to offer higher salaries and delay critical work.

To overcome the developer skills shortage, software engineering leaders need to upskill and reskill their existing employees and new hires. The focus should be on developing each employee’s skills ahead of demand so that they can play a broader range of roles and continue to enhance an organization’s technical capabilities. Software engineering leaders can use a six-step talent development program to upskill and reskill their developer teams.

Step 1: Identify skills needed now and later

The first step to upskilling and reskilling is to identify and segment software developer skills that are essential to your team and organization’s success. For example, lay out core skills relevant to the existing technological landscape and skills that will be required for emerging technologies and architectures.

Identify aging systems or digital services to anticipate future needs and the likely enhancements. Collaborate with business leaders, product managers and solution architects to understand the future set of skills needed to modernize the product. Moreover, software engineering leaders can also ask their HR learning and development department to create a skills matrix for software engineering.

Consider four aspects:

• Competencies — such as business acumen, design thinking
• Working methodologies — such as Agile, Kanban.
• Architectures and design — such as SOA, MASA, cloud-native, data architecture, user experience.
• Technical skills — Such as Specific programming languages, development platforms, tools.

Step 2: Inventory current developer skills

Next, assess the skill sets and aptitudes of existing developers to identify gaps in the current learning and development regime.

Before surveying employees to evaluate their skills and competencies, make sure to communicate the purpose of the exercise is to evaluate the organization’s capabilities, not compare employees. Employees should feel secure so that they don’t give prejudiced or biased responses. 

Also motivate developers to broaden their skills and roles by making reskilling and upskilling a part of the organization’s culture. Software engineering leaders can lead the way by openly showing their liking for on-the-job learning. Employees should recognize the need to upgrade their software developer skills on an ongoing basis and without any hand-holding.

Step 3: Motivate employees to broaden their skills

Software engineering leaders should instill the drive to learn in employees and encourage them to be self-starters. Shift performance discussions from “What have you done?” to “What have you learned?” Employees should learn to identify and target skills (both technical and managerial) that will be game-changers. 

Three elements of motivation (based on Drive: The Surprising Truth About What Motivates Us by Daniel Pink) are key to talent development:

• Autonomy: Avoid excessive interference; let your teams figure out the best way to get the job done and remove the roadblocks to the progress of employees.
• Mastery: Ensure that employees receive recognition on mastering software developer skills — not just from managers, but also from peers.
• Purpose: Make sure employees associate a sense of purpose with their work — does their work positively impact the organization’s growth and technological landscape?

Step 4: Accept a base level of skills but plan for upskilling

Upskill existing developers in tandem with your search for new hires. Finding highly proficient individuals may be challenging, so be willing to hire people with a base level of skills and immediately create learning opportunities to ensure they become valuable assets for the organization. Prioritize qualities like collaborative mindset and adaptability when hiring entry-level employees. Once their core software developer skills are validated in the organization, they can broaden their horizons and develop greater business acumen.

Employees working in technical or customer support can also be considered for software developer roles, as they have a good understanding of products and customers and can learn new skills.

Incorporate agile learning, which encourages iterative short bursts of skill development to achieve adjustable results. Agile learning also instills a growth mindset in employees so that they don’t just gain knowledge but apply it to produce significant business value. It facilitates an environment where people learn and grow together rather than in individual capacities to compound the benefits more widely across the organization.

Step 5: Create on-the-job learning opportunities 

When evaluating different development approaches, consider low-cost, less time-consuming on-the-job learning opportunities for developers. The idea is to put employees into dynamic environments where they can learn and apply new skills quickly. Peer connections and 360-degree feedback, along with group activities like hackathons, innovation labs, and lunch and learns, can build valuable knowledge sharing channels for new hires and old employees. 

Step 6: Dedicate time to learning

Learning and development programs should make the enterprise more productive in the long run, but for that to happen, you need to allocate time for learning amid a massive backlog of work. In a work week, a dedicated time window can be created for learning and cross-functional activities. The window may include master classes, instructor-led online coaching, mentoring programs, proof-of-concept projects on new technologies and communities of practice.

The post 6 steps to upskill developers appeared first on SD Times.

“Technology innovation is a key enabler of competitive differentiation and is the catalyst for transforming many industries. Breakthrough technologies are continually appearing, challenging even the most innovative organizations to keep up,” said Brian Burke, research vice president at Gartner. “Leading organizations will lean on the emerging technologies in this year’s Hype Cycle to build trust and new growth opportunities against a background of continued strategic change and economic uncertainty.”

According to Gartner, trust demands security and reliability, but it can also be a foundation for delivering business value if that foundation consists of engineered, repeatable, trusted, proven and scalable practices and innovations. 

Currently the market for cloud technologies and services is dominated by US and Asian providers, which is leading many European companies who store their data in these reasons to have political uneasiness, concerns about retaining data control, and complying with local regulations. One solution to these concerns is to use a sovereign cloud that will provide legal requirements to apply data protection controls, residency requirements, protectionism, and intelligence gathering. 

In addition to sovereign clouds, other technologies to watch to engineer trust include NFTs, machine-readable legislation, decentralized identity, decentralized finance, homomorphic encryption, active metadata management, data fabric, real-time incident center, and employee communications applications. 

Wanting to accelerate growth is another impetus for exploring new technologies. Gartner recommends company balance technology risk with business risk to ensure that their near-term objectives can be met. 

Technologies to explore to accelerate growth include multi-experience, industry cloud, AI-driven innovation, quantum machine learning, generative AI, and digital humans. 

Finally, technology can be used to sculpt change and bring order to the chaos that the disruptive nature of change usually brings with it. 

Organizations should look to composable applications, composable networks, AI-augmented design, AI-augmented software engineering, physics-informed AI, influence engineering, digital platform conductor tools, named data networking, and self-integrating applications.

For example, composable applications allow businesses to recognize and take advantage of business opportunities, respond to change, and meet customers’ changing demands. 

“As organizations continue their focus on digital business transformation, they must accelerate change and cut through the hype surrounding emerging technologies,” said Melissa Davis, research vice president at Gartner.

The post Gartner identifies emerging technologies to look into in 2021 appeared first on SD Times.

“Rapid change and accelerating application delivery is a topic that used to really be something only technology and Silicon Valley companies talked about. Over just the past few years, it has become something that almost every organization is experiencing,” said Lubos Parobek, vice president of product for the testing company Sauce Labs. “They all feel this need to deliver apps faster.”

RELATED CONTENT: A guide to automated testing tools

This sense of urgency has businesses looking to leverage test automation even further and go beyond just automating repetitive tasks to automating in dynamic environments where everything is constantly changing. “As teams start releasing even weekly, let alone daily or multiple times a day, test automation needs to change. Today test automation means ‘automation of test execution,’ but the creation and maintenance of tests, impact analysis and the decision of which test to run, the setup of environments, the reviewing of results, and the go/no-go decision are all entirely manual and usually ad-hoc,” said Antony Edwards, CTO of the test automation company Eggplant. “The key is that test automation needs to expand beyond the ‘test execution’ boundary and cover all these activities.”

Pushing the limits
Perhaps the biggest drivers for test automation right now are continuous integration, continuous delivery, continuous deployment and DevOps because they are what is pushing organizations to move faster and get software into the hands of their users more quickly, according Rex Black, president of the Rex Black Consulting Services, a hardware and software testing and quality assurance consultancy.

“But the only way for test automation to provide value and to not be seen as a bottleneck is for it to be ‘continuous,’” said Mark Lambert, vice president of products at the automated software testing company Parasoft.

According to Lambert, this happens in two ways. First, the environment has to be available at all times so tests can be executed at anytime and anywhere. Secondly, the tests need to take change into account. “Your testing strategy has to change resistance built into it. Handling change at the UI level is inherently difficult, which is why an effective testing strategy relies on a multi-layer approach. This starts with a solid foundation of fully automated unit tests, validating the granular functionality of the code, backed up with broad coverage of the business logic using API layer testing,” said Lambert. “By focusing on the code and API layers, tests can be automatically refactored leaving a smaller set of the brittle end-to-end UI level tests to manage.”

Part of that strategy also means having to look at testing from a different angle. According to Eggplant’s Edwards, testing has shifted from testing to see if something is right, to testing to see if something is good. “I am seeing more and more companies say, ‘I don’t really care if my product complies with a [specification] or not,’ ” he said. “No one wants to be the guy saying no one is buying our software anymore, and everyone hates it, but at least it complies with the spec.” Instead, testing is shifting from thinking about the requirements to thinking about the user. Does the software increase customer satisfaction, and is it increasing whatever the business metric is you care about?

“If you care about your user experience, if you care about business outcome, you need to be testing the product form the outside in, the way a user does,” Edwards added.

Looking at it from the user’s side involves monitoring performance and the status of a solution in production. While that may not seem like it has anything to do with testing or automation, it’s about creating automated feedback loops and understanding the technical behavior of a product and the business outcome, Edwards explained. For example, he said if you look at the page load speed of all your pages and feed that back into testing, instead of automating tests that say every page has to respond in 2 seconds, you can get more granular and say certain pages need to load faster while other pages can take up to 10 seconds and won’t have a big impact on experience.

“Testing today is too tied to the underlying implementation of the app or website. This creates dependencies between the test and the code that have nothing to do with verification or validation, they are just there because of how we’ve chosen to implement test automation,” Edwards said.

But just because you aren’t necessarily testing something against a specification anymore, doesn’t mean you shouldn’t be testing for quality, according to Thomas Murphy, senior director analyst at the research firm Gartner. Testing today has gone from a calendar event to more of a continuous quality process, he explained.

“There is a fundamental need to be shipping software every day or very frequently, and there is no way that testing can be manual. You don’t have time for that. It needs to be fast,” he said.

Some ways to speed things up is to capture the requirements and create the tests upfront. Two approaches that really drove the need for automating testing are test-driven development (TDD) and behavior-driven development (BDD). TDD is the idea that you are going to write the test first, then write the code to pass that test, according to Sauce Labs’ Parobek. BDD is where you enable people like the business analyst, product manager or product owners to write tests at the same time developers are developing code.

These approaches have helped teams get software out multiple times a day because they don’t have to wait for days to create the tests and get back results, and it enables them to understand if they make a mistake right away, Parobek explained.

However, if a developer is submitting new code or pull requests to the main branch multiple times a day, it can be hard to keep up with TDD and BDD, making automated testing impossible because there aren’t tests already in place for these changes. In addition, it slows down the process because now you have to go in manually to make sure the code that is being submitted doesn’t break any key existing function, according to Sauce Labs’ Parobek.

But Parobek does explain if you write your test correctly and follow best practices, there are ways around this. “As you change your application and as you add new functionality, you do not just create new tests, but you might have to change some existing tests,” he said.

Parobek recommends page object modeling as a best practice. It enables users to create tests in a way that is very easy to change when the behavior of the app is changed, he explained.  “It enables you to abstract out and keep in one place changes so when the app does change, you are able to change one file that then changes a variety of test cases for you. You don’t have to  go into 100 different test cases and change something 100 times. Rather you just change one file that is abstracted through page objects,” he said.

Another best practice, according to Parobek, is to be smart about locators. Locators enable automated tests to identify different parts of the user interface. A common aspect of locators is IDs. IDs enable tests to identify elements. For example, when an automated test goes in and needs to test a button, if you’ve attached a locator ID to it, the test can recognize the button even if you moved it somewhere else on the page. Other approaches to locators are to use names, CSS selectors, classes, tags links, text and XPath. “Locators are an important part for creating tests that are simpler and easier to maintain,” said Parobek.

In order to successfully use locators, Parobek thinks it is imperative that the development and QA teams collaborate better. “If QA and development are working closely together, it is easy to build apps that make it easier to test versus development not thinking about testability.”

No matter how much you end up being able to automate, Black explained in order to be successful at it, you will still always have to go back to the basics. If you become too aspirational with automation and have too many failed attempts, it can reduce management’s appetitive for wanting to invest. “You need to have a plan. You need to have an architecture,” Black said. “The plan needs to include a business case so you can prove to management it is not just throwing money into a bright shiny object.”

“It’s the boring basics. Attention to the business case. Attention to the architecture. Take it step by step and course correct as you go,” Black added.

The promise of artificial intelligence in automated testing
As artificial intelligence (AI) advances, we are seeing it be implemented in more tools and technologies as a way to improve user experience provide business value. But when it comes to test automation, the promise of AI is more inspirational than operational, RBCS’ Black explained.

“If you go to conferences, you will hear about people wanting to use it, and tool vendors making claims that they are able to deliver on it. But at this point, I have not had a client tell me or show me a successful implementation of test automation that relies on AI in a significant way,” he said. “What is happening now is that tool vendors are sensing that this is going to be the next hot thing and are jumping on that AI train. It is not a realized promise yet.”

When you think about AI, you think about a sentient element figuring things out automatically, according to Gartner’s Murphy, when in reality it tends to be some repeated pattern of learning something to be predictive or learning from past experiences. In order to learn from past experiences, you need a lot of data to feed into your machine learning algorithm. Murphy explained AI is still new and a lot of the test information that companies have today is very fragmented, so when you hear companies talk about AI in regards to test automation it tends to be under-delivering or over-promising.

Vendors that say they are offering an AI-oriented test automation tool are often just performing model-based testing, according to Murphy. Model-based testing is an approach where tests are automatically generated from models. The closest thing we have out there to an AI-based test automation tool are image-based recognition solutions that understand if things are  broken, and can show when it happened and where through visual validation, Murphy explained.

However, Black does see AI having potential within the test automation space in the future; he just warns businesses against investing in any technologies too soon. Areas where Black sees the most potential for AI include false positives, and flaky tests.

False positives happen when a test returns a failed result, but it turns out the software is actually working correctly. A human being is able to recognize this when they look further into correcting the result. Black sees AI being used to apply human reasoning and differentiate the correct versus incorrect behavior.

Flaky tests happen when a test fails once, but passes when the test runs again. This unpredictable result is due to the variation of the system architecture, the test architecture, the tool, or the test automation, according to Black. He sees AI being used to handle validation issues like this by bringing a more sophisticated sense of what fit for use means to the testing efforts.

Kevin Surace, CEO of Appvance.ai, sees AI being applied to test automation, but in different levels. Surace said there are 5 levels of AI that can be applied to test automation:

1. Scripting/coding
2. “Codeless” capture/playback
3. Machine learning: self-healing human-created scripts and money bots
4. Machine learning: Near full automation with auto-generated smart scripts
5. Machine learning full automation: auto-generated smart scripts with validation

When deciding on AI-driven testing, Surace explained the most important qualification is to learn what type of level of AI a vendor is offering. According to Surace, many vendors have offerings at levels one and two, but there are very few vendors that can actually promise levels three and above.

In the future, Parasoft’s Lambert expects humans will just be looking at the results of test automation with the machine actually doing the testing in an autonomous way. But for now, the real value of AI and machine learning will be used to augment human work and spot patterns and relationships in the data in order to guide the creation and execution of tests, he explained.

Still, Black warns to enter AI for test automation with caution. “Organizations that want to try to use AI-based test automation at this point in time should be extremely careful and extremely conservative in how they pilot that and how they roll that out. They need to remember that the tools are going to evolve dramatically over the next decade, and making hard, fast and difficult to change  large investments in automation may not be a wise thing in the long term,” he said.

Manual practices remain
Despite the efforts to automate as much as possible, things for the time being will still require a human touch.

According to Rex Black, president of the Rex Black Consulting Services (RBCS),  a hardware and software testing and quality assurance consultancy, you can break testing down into two overlapping categories: 1. Verification, where a test makes sure the software works as specified; and 2. Validation tests, where you make sure tests are fit for use. For now, Black believes validation will remain manual because it is very hard to do in an automated fashion. For example, he explained, if you developed a video game, you can’t automate for things like: Is it fun? Is it engaged? Is it sticky? Do people want to come back and keep playing it?

“At this point, automation tools are really about verifying that the software works in some specified way. The test says what is suppose to happen and checks to see if it happens. There is always going to be some validation that will need to be done either by people,” he said.

Lubos Parobek, vice president of product for the testing company Sauce Labs explained that even if we get to a point where everything is automated in the long-term future, you will still always want a business stakeholder to take a final look and do a sanity check that everything works as expected to a human.

“Getting a complete view of customer experience isn’t just about validating user scenarios, doing click-counts and sophisticated ‘image analysis’ to make sure the look and feel is consistent — it’s about making sure the user is engaged and enjoying the experience. This inherently requires human intuition and cannot be fully automated,” added  Mark Lambert, vice president of products for automated software testing company Parasoft.

Robotic process automation
Test automation vendors are flocking to this idea of robotic process automation (RPA). RPA is a business process automation approach used to cut costs, reduce errors and speed up processes, so what does this have to do with test automation?

According to Thomas Murphy, senior director analyst at Gartner, RPA and test automation technologies have a high degree of overlap. “Essentially both are designed to replicate a human user performing a sequence of steps.”

Anthony Edwards, CTO of the test automation company Eggplant, explained that on a technical level, test automation is about automating user journeys across an app and verifying that what is supposed to happen, happens. RPA aims to do just that. “So at a technical level they are actually the exact same thing, it’s simply the higher level intent and purpose that is different. But if you look at a script that automates a user journey there is no way to tell if it has been created for ‘testing’ or for ‘RPA’ just by looking at it,” said Edwards. “The difference for some people would be that testing focuses on a single application whereas RPA typically works across several systems integrated together.”

Over the next couple of years, Gartner’s Murphy predicts we will see more test automation vendors entering this space as a new way to capitalize on market opportunity. “By moving into the RPA market, they are expanding their footprint and audience of people they go after to help them,” he said.

This move is especially important as more businesses move toward open-source technologies for their testing solutions.

Rex Black, president of the Rex Black Consulting Services (RBCS), a hardware and software testing and quality assurance consultancy, sees the test automation space moving towards open source because of cost. “It’s easier to get approval for  a test automation project if there isn’t a significant up-front investment in a tool purchase, especially if the test automation project is seen as risky. Related to that aspect of risk is that so many open-source test automation tools have been successful over recent years, so the perceived risk of going with an open-source tool is lower than it used to be,” he said.

The post Pushing automated testing to its limits appeared first on SD Times.

Whether you believe that IoT is just hype, that big data stumbled out of the gate, that Industry 4.0 will never happen, or that AI is just a fad, the recurring theme that weaves each of these narratives together is the relentless drive towards digital transformation seen across industries. One could accuse digital transformation itself as being a hyped buzzword, though its longevity as a business theme points to some underlying needs which are yet to be fully realized. At its core, digital transformation represents a rethinking of how enterprises use (digital) technology to radically change performance.

In recent conversations with customers, digital transformation isn’t usually addressed head-on under that banner. More often, the topic arises tangentially due to some other problem we’re exploring, though there are three recurring themes that point to the need to change the way that embedded systems are developed.

1. Fixed function to flexible systems

Many embedded or control systems are designed in a monolithic manner; custom hardware is outfitted with a tailored operating system, likely some complex middleware, and hosting one or more applications to perform a specific set of tasks. The entire device is packaged and sold as a single device, and an upgrade is performed by replacing a whole unit with a newer generation that has undergone a similar design cycle. Not only is this a cumbersome design approach requiring re-development and re-testing of a number of non-differentiating components each design cycle, but it is also inflexible when it comes to deploying new features or fixing broken ones (including security updates). Contrast this with the modern approach to enterprise or cloud software development where applications (or increasingly micro-services) have been developed independently of how or where they will be deployed, accelerating innovation and time-to-value.

2. Automated devices to autonomous systems

Many embedded systems are designed to automate specific tasks. In industrial systems, for example, a Programmable Logic Controller (PLC) is used to automate manufacturing processes such as chemical reactions, assembly lines or robotic devices. Generally, these devices perform with a high degree of accuracy, repeatability and reliability, though they need to be individually programmed to do so and often have little scope for performing outside of their initial design parameters. However, in order to drive productivity increases and impact larger business outcomes, learning systems will increasingly be used spanning a range of control devices at the cell, plant, or system level. Similar system-level approaches are emerging in autonomous driving applications, where information from multiple subsystems needs to be merged and processed in some central unit running machine learning algorithms for object classification, path-finding and actuation.

Learning systems will also have a big impact on the type of computing workloads that need to be run on edge devices. Traditionally, embedded system design has begun with custom hardware, possibly encompassing customized silicon processors, on which software is layered – a “bottoms-up” approach. For machine learning implementations, the process is turned on its head; a defined problem statement will determine the best type of learning algorithm to use (for example an object classification problem may require a different approach to voice recognition), from which the best hardware platform will be selected to run the learning framework most efficiently. This may involve selecting CPUs with specific instruction sets or accelerators, or using GPUs or FPGAs alongside traditional processors, for example. In these environments, the software often defines the required hardware platform.

3. Software-defined everything

The advent of autonomous systems will require a shift in system design focus from individual, resource-constrained, bespoke devices, to more flexible and programmable environments that can be changed or optimized more globally. This shift will not only impact the engineering approach to architecting intelligent systems, but also the supply chain which has long been established in various industries around the production of specific, functional “black boxes”, such as Electronic Control Units (ECUs) in automotive, or Distributed Control Systems (DCS) in industrial applications.

Similarly, the skill set required to build these systems will evolve to encompass a much more software-centric aspect. Companies who may have defined their differentiation and captured their value by designing and selling hardware, will likely find that they need to develop a rich software competency. This will involve defining a software blueprint, and possibly tools, APIs and SDKs with which their ecosystem will deliver additional value-add components to an underlying computing platform. The responsibility for integrating middleware or applications from a number of suppliers could shift from the supply chain to the equipment manufacturers themselves, and bring with it a change in the support or liability models.

Modernizing the development paradigm: the IT journey
Enterprise IT systems have undergone a radical transformation in the last couple of decades. At the beginning of my career, I recall using not only mainframe computers, but a plethora of microcomputers, each with their own flavor of operating system. Look under the hood, and you’d find that these computers were powered by unique, and sometimes custom, processor architectures. As desktop PCs and servers emerged, Intel Architecture became the ubiquitous silicon architecture for enterprise IT systems, driving standardization of hardware, development tools, and a vibrant software ecosystem.

Next, we saw the transformative power of virtualization, which led to consolidation of applications and a drive to higher hardware utilization rates, squeezing yet more efficiency into the IT landscape. While the motivation was initially driven by optimization of local computing resources, de-coupling software from the underlying hardware allowed centralization of computing resources and paved the way for cloud computing.

Today, cloud computing has removed the dependency between hardware and software, and applications or individual functions can be written quickly and efficiently, while having great control of underlying computing, storage and networking resources. This decoupling has allowed developers to quickly develop, deploy and update applications and enormous scale, without worrying about purchasing or managing any hardware at all.

While IT developers can quickly build and deploy hyperscale applications, build upon the knowledge of others by using rich application frameworks, modern development languages and tools, and use infrastructure that is managed by someone else, embedded developers mostly do not have this luxury. Instead, their development model leaves them struggling to stay apace of rapidly changing silicon architectures, unable to use a lot of the advances in software development and deployment methodology that their IT counterparts enjoy, and as a result struggle with rapid innovation, affordability of their systems, and product obsolescence. They are not enjoying the advances brought about by the IT journey.

In order to change this, one must recognize that embedded systems often are very different from IT systems. Issues such as system performance and reliability, costs, resource and timing constraints, intolerance of failures or downtime, safety needs, all place very specific requirements on how systems are built and deployed. However, by recognizing and addressing these requirements, I believe we can start leveraging the advances seen in the IT domain and unlock more efficiency, innovation and affordability in the way embedded systems are built.

The post <span class="sdt-premium">premium</span> Digital transformation: A catalyst for changing the embedded development paradigm appeared first on SD Times.