Tag: development teams

  • Successful Digital Transformation Starts With Developers

    Successful Digital Transformation Starts With Developers

    Digital transformation (DX) continues to be a primary focus as companies both large and small look to become more agile, improve and accelerate the delivery of product and service offerings and enhance data-driven business decisions. The C-suite typically leans on IT departments and developers to champion such transformations, designing the software and tools that will lead the experience both internally with staff and externally with customers. The challenge often lies in the fact that most organizations lack the software resources to drive a successful transformation. In addition, research has found that 45% of executives don’t know where to start with DX projects, resulting in added pressure on the developers who hold the technical knowledge but may lack the managerial expertise for a successful rollout.

    So, with IT having the opportunity to be the hero or the scapegoat of a DX initiative, where should development teams start? Typically, digital transformation requires development transformation, so you can start at home, by modernizing the way you develop and deliver software. Doing this also significantly improves the odds of a successful digital transformation and puts development in the driver’s seat.

    Here are four factors to prioritize before kicking off a DX project:

    Buy vs. Build

    A DX initiative requires a number of digital tools and software applications, some of which can be purchased through third parties while others may need to be built in-house, depending on the desired goals of the program. Organizations must determine whether they want to build or buy new software solutions, and the answer is almost always mixed. Most developers believe that each application can be built in-house, while the C-suite often encourages purchases from a third party to accelerate adoption. Before starting to code, ask yourself if the solution you need should be bought or built. Oftentimes, the same goal can be achieved through a purchased solution, empowering you and your team to spend more time customizing those solutions rather than starting from scratch while focusing on the projects that will have the biggest impact on the business—ultimately accelerating time to completion.

    Accelerated Rate of Change

    Once applications are built and available to the public, you can expect bugs to be identified and requests for improvements to be made at an accelerated rate. Developers are constantly making software updates, but when applications are being used to support DX, the rate of change for business requirements is going to speed up, especially when those applications are customer-facing. Developers will need to learn fast and iterate quickly, so it’s important to establish an agile culture within your team.

    Adopting a DevOps philosophy often will be the most successful approach, as it enables your team to test and troubleshoot quickly and enact change across the platform. This approach also assists the rest of the organization in adopting DX practices, delivering a more seamless experience and universal data-sharing. Developer teams must be wary of traditional quarterly or annual planning cycles that create silos, slow agile processes and hinder successful implementations. By breaking down these silos, your team will gain better insight into what is and isn’t working and enable swifter improvements, creating a culture that embraces the changes that come with DX.

    Modular Software Architecture

    Software architecture is incredibly important, as it directly impacts the team’s ability to react to rapid change. A more loosely coupled, modular architecture puts the developer team in the best position to evolve quickly with fewer dependencies, enabling them to make updates and replace components over time to meet business objectives and customer demands. The ability to reconfigure or replace components without having to recode the entire system also assists in build-versus-buy decisions, with developer teams purchasing add-ons to incorporate into a system and solve problems quickly.

    DX Outside of Organizational Barriers

    We work and collaborate in a digital ecosystem. External APIs, third-party data-sharing and interoperability are all requirements as organizations roll out new tools as part of a DX initiative. DX comes down to building a digital ecosystem that flows outside of the organization, whether it is employees working remotely or customers integrating your tools into their existing solutions. Your company’s software needs to accommodate these capabilities to enable a more seamless and well-rounded DX approach.

    DX is a Journey, Not a Destination

    A successful DX initiative should be seen as a culture shift, not an end result. The digital world is not static, and DX is a practice that enables an organization to learn fast and be lean and nimble. As soon as you’ve reached one milestone, there’s a whole new set of rules to play by to get to the next, requiring the developer team to recalibrate. By taking a realistic, process-oriented approach, the developer team will have the mindset and tools necessary to make DX successful.

    — Jeff Fried

  • Salvador Partners Bridges Global Gaps for DevOps

    Salvador Partners Bridges Global Gaps for DevOps

    Salvador Partners works on a global scale to help its customers grow their business. The company, which has its own set of products, also focuses on assisting startups in making their vision reality. Indeed, it bills itself as “experts at innovation and exploiting innovation.”

    The company started life as a subcontracted electronic components manufacturing company, slowly broadening its lineup to include security products and patents and evolving to become a provider of technology for banking, financial services (fintech), defense and mechanical systems, says Lewis Daniels, founder of Salvador Partners. The company also serves as an incubator and capital arm for new technologies.

    Salvador builds circuit boards and technology products, working across artificial intelligence (AI), augmented reality and blockchain technology, together with its other endeavors. Across its projects, wherever software is part and parcel with its products, Salvador Partners’ international team of developers are hard at work.

    The firm has built a DevOps culture across its organization despite geographical and language barriers. devopsy.kinsta.cloud explores the Salvador Partners devops culture that works in an umbrella fashion among these international developer groups.

    The Global DevOps Culture Challenge

    Salvador Partners works with development teams in Russia, China, India, the U.K. and the United States who build software prototypes, which can sometimes prove tricky: There are challenges to getting foreign teams to plug themselves more deeply in to existing domestic teams for future projects. “There’s an obvious value in their experience from the build of your prototype that you then want to tap. The question is whether they want to be a part of your longer-term vision,” Daniels says.

    The company also grapples with the location question—whether to consider moving some of its operations to those countries, closer to those teams, or move some or all of them to its domestic operations. “Perhaps the world has become small enough through the use of tools like Slack and [project management] tools that you can let the technology bridge any gaps,” says Daniels. The tools so far have helped disparate development teams make the leap, including addressing any time zone and language issues that appear.

    Delineating the Salvador Partners Culture

    Salvador Partners uses an agile approach. “If each client wants a unique tweak, we simply badge up a boutique offering where we can innovate, collaborate and deploy in an agile environment to suit the client requirements,” Daniels says.

    As development teams work together more frequently, they reuse code and proven approaches more often. “We often find tricks that get carried over to the next application or dashboard,” says Daniels.

    Tools are the answer. “Things have changed in recent years. In terms of a culture, I think it’s pretty easy to leverage tools such as Slack and Dropbox to make the team smaller, regardless of where in the world they are positioned,” he says.

    Salvador Partners developers also use Trello for sharing project plans and Skype and Uber conference for team collaboration calls. “We use a secure mobile app we developed internally to communicate on some of the new, high-tech or sensitive topics. WeTransfer is also pretty useful for sending larger files,” says Daniels.

    Though Salvador Partners looks at its DevOps culture as a whole rather than by region, there are some unique, regional aspects. “We have a real good team based in India and they just go get things done, whereas some of their counterparts we use sometimes get caught up in planning the plans. This can make it difficult to pull a number of pieces of a project together,” says Daniels.

    Other Solutions to Challenges

    Locations, languages and distances present other challenges as well. Because some projects work with encryption protocols that by law can’t be shared beyond certain countries, the development work can happens only inside the U.K., the United States, Australia, Canada and some European countries, Daniels notes. In these cases, the company simply keeps the work internal, within the countries permitted.

    Language barriers can also present issues. “Such was the case where Salvador Partners had Canadian companies working on something and had a French speaker cause a few problems for his English-speaking colleagues,” Daniels says. For language challenges, the company simply whiteboards the project or uses translators.

    Time zones can also trip things up. “It creates challenges when you have a New Zealand head office dealing with partners in Singapore and developers in Russia and California. We have had conference calls where participants are going for dinner and at the same time another having their first coffee,” Daniels says.

    However, time zones and geographies are less an issue as the available toolsets to solve communications barriers have evolved.

  • Now that you can consolidate, do not implode

    Now that you can consolidate, do not implode

    The development world is changing in a big way. We all know it. And it usually happens first with the early stage startups, who have the luxury of adopting new approaches from day one. One of those major shifts is consolidation of team members, where automation is taking over previous roles. In the modern development shop for example you are not just a front-end developer, you are a data scientist, a tester, a orchestration master, and a release manager. There are a lot of upsides to this consolidation, but a lot of downsides as well.

    (more…)