devopsy.kinsta.cloud

Tag: application development

  • Q&A: CNCF on Instilling a DevOps Culture, Part 1

    Q&A: CNCF on Instilling a DevOps Culture, Part 1

    The Cloud Native Computing Foundation (CNCF) is a non-profit comprised of some 49 industry participants that have come together to drive development and adoption of cloud-native applications and services. The CNCF is uniting such giants as Google, IBM, Intel and Cisco Systems to distill a collection of container technologies that end-user companies deem praiseworthy to reach its goal.

    The CNCF intends its membership to represent end users (the CNCF website lists one end user, Goldman Sachs), cloud and container technologies, online and IT services, and academic institutions.

    On behalf of the CNCF, Craig McLuckie, its Governing Board chair, and Brian Grant, its Technical Oversight Committee representative, weigh in on leading the DevOps transformation and instilling a DevOps culture in this two-part Q&A.

    devopsy.kinsta.cloud: How is the CNCF specifically involved in leading the DevOps transformation by instilling the DevOps culture, in the industry or in member companies, for example?

    McLuckie: We believe that at the heart of the DevOps culture is the need to reduce the friction and, indeed, the barriers between teams that build an application and the teams that run an application. Developers learn to think about an application as a living service that evolves continuously and rapidly to meet the evolving business needs. Operations is there to deliver the tools and environment needed for them to successfully drive their application.

    devopsy.kinsta.cloud: Why do developers need an environment that is safe to change? What kind of change? Safe how?

    McLuckie: Safe change has many potential meanings: The first kind of “safe” is about creating deterministic behavior in operations. Does the system handle a change correctly every time? If I make a change to two systems, will they have the same state? How about to 1,000 systems? It’s important to focus on creating strong determinism by removing the moving parts in a production deployment.

    The second kind of “safe” is about being able to validate that a change is good—not just in pre-production environments, but in the actual production environment—with a simple and deterministic rollback. It is important to make it trivial to replicate environments, and offer a way to run a simple experiment in production (e.g. route 1 percent of my traffic to this new version) with the option to deterministically roll forward or backward without effort.

    A third kind of “safe” is about being able to ensure that every change is deliberate. One of the problems we often see in production systems is “configuration drift” that isn’t driven through any kind of formal process. This should be addressed by creating a strongly declarative toolset that makes every change deliberate and trackable.

    devopsy.kinsta.cloud: How do you recommend providing these things that developers need? How do you help provide them?

    McLuckie: There are multiple issues like data, security governance and applications that need to be addressed. Additionally, companies want to deliver apps with high velocity. How do you solve all of this? A vendor-neutral organization that can harmonize emerging technologies is important for facilitating cloud-native. Given the large number of players in the marketplace with competing approaches, having an open source way to solve this is also important.

    Grant: Cloud-native infrastructure enables self-service and “hands-off” operation, including provisioning, deployment, scaling, healing, discovery, monitoring and more, with relatively little marginal effort for specific applications. By supporting open source projects such as Kubernetes and Prometheus that provide such functionality, the CNCF hopes to democratize high-velocity application delivery, which was previously achievable mainly by web-scale companies.

    devopsy.kinsta.cloud: How does this align with instilling a DevOps culture?

    Grant: In a DevOps culture, operators are both partners and customers of the developers. Developers take responsibility for meeting operational requirements: security, reliability, availability, scalability, efficiency, actionable monitoring and logging output, necessary configurability, compatibility with the production environment, etc. Cloud-native infrastructure provides mechanisms developers and operators need to facilitate and capitalize on those capabilities.

    Stay tuned for part two of the CNCF interview.

  • Echidna Takes DevOps to E-Commerce Site Creation

    Echidna Takes DevOps to E-Commerce Site Creation

    The Echidna e-commerce firm installs and evolves e-commerce platforms, providing ongoing development so its clients can leverage e-commerce experiences to the satisfaction of their customers. “We apply carefully selected user experience technology, marketing and analytics abilities to our clients’ strategic goals to do this,” taking what it calls an “anti-Big Bang” approach to continuous deployment, says Mike Pierce, CTO of Echidna.

    “Traditional e-commerce deployments were often Big Bang deployments that people developed on the basis that they had to pressure the business leaders into feeling like they had only one chance to pack as much scope as possible into a large software development project. That approach voids any practical innovation,” says Pierce. With that mindset, it can take years to finish e-commerce sites, and e-commerce companies can go out of business by the time they actually finish such a site, since it would be far out of date by then.

    Echidna sees continuous deployment as one piece in a much larger agility play designed to ensure that businesses compete in digital economies, now and in the future. Continuous deployment is the ultimate goal of DevOps, an approach that enables the business to innovate fast enough to maintain the business’ sharp marketplace edge through acute, turn-on-a-dime competitive dexterity. “In order to do this, continuous deployment helps companies learn to develop high-quality software and deploy it on a rapid, reliable and repeatable schedule,” says Pierce.

    Continuous Deployment Timelines and Challenges

    Depending on the client, its needs and the features in the pipeline, Echidna deploys software to each e-commerce platform from monthly to daily, and at intervals in between those extremes. Echidna seeks to increase the degree of automation of each deployment over time. The challenge is that with so many different clients and platforms, Echidna must achieve its automation victories for each customer individually, solving similar and unique issues. “We are finding our greatest success using PaaS (platform-as-a-service) e-commerce platforms like Four51 because it eliminates a lot of the administrative overhead that is typical with deployments to on-premise platforms,” says Pierce.

    The development model Echidna follows to deploy e-commerce sites affects each software component, even though components deploy at different times. “Payment system modifications require significantly different testing—more testing—and we must deploy them much less often than other components. Marketing components don’t need as much regression testing as other software modules and so we can deploy them much more quickly,” he says.

    The most difficult software to move into continuous deployment in an e-commerce platform are the components that integrate deeply into enterprise systems. That is why Echidna advises business customers to use DevOps methodologies to deploy their enterprise production software at accelerated rates. When they do this, Echidna potentially can speed its deployment of the e-commerce platform components that are enmeshed with those production systems.

    The Four51 Path, Through Jitterbit

    Echidna connects Four51’s OrderCloud to the Jitterbit iPaaS integration server platform, a point-and-click integration tool. “This enables us to streamline further integrations and data exchanges with many of the disparate systems in an ecosystem,” says Pierce. Echidna sees increasing continuous deployment orchestration opportunities as more and more third-party application vendors become compatible with these kinds of integration tools.

    Four51 enables an ecosystem of connected digital services and applications where e-commerce uses numerous disparate systems that exchange data and facilitate work streams in the enterprise in question, Pierce says. “As these systems eliminate disparities and we align them on the central integration and deployment standards that we use, there will be increasing opportunities to introduce clients to lean development practices like continuous delivery and continuous deployment.”

    Conclusion

    Continuous deployment is miles apart from what information technology is used to, especially where manual change management and change control are concerned. But once Echidna exposes its customers to continuous deployment, their managers, C-levels and boards soon begin to witness the accelerated software innovation continuous deployment provides and how this makes information technology—and the business—more nimble, both technologically and competitively.

  • Simulation: The ‘Aha’ Moment for DevOps Adoption

    Simulation: The ‘Aha’ Moment for DevOps Adoption

    Every IT transformation requires that people, process and technology align and work together to achieve success. As organizations begin to appreciate the benefits of a DevOps approach and look to change to a DevOps model of software development and release, there will be significant pressure on people, process and technology to support that change properly.

    The technology and process changes required to enable DevOps to work efficiently shouldn’t be underestimated. Considerable time and investment is required in embracing the automation technologies that support a proper DevOps environment, and in developing the processes that make best use of that technology.

    But DevOps cannot work unless your people are ready to change. Development teams and IT operations—who traditionally have worked in silos—must work together, integrate seamlessly and understand not only their roles and responsibilities within the new environment but also the roles and responsibilities of those around them.

    And therefore, like every change, the real key to success is your people.

    Creating Successful Change

    The benefits of taking a DevOps approach are numerous: By moving toward more frequent delivery with reduced elements of change, you lower risk and increase system stability. Although automation is costly to implement, it allows teams to work far more efficiently, increases reuse, reduces errors and brings development teams closer to the customer. New functionality released continually and rapidly can be validated in the market, feedback can be received, lessons can be learned and improvements implemented quickly.

    But in making such a radical cultural shift, how do you ensure you change the mindset of people who have been used to working in a certain way? How do you provide your people with the helicopter view of what that future state will be, instill in them your fervor for change and provide them with the understanding and motivation necessary to embrace new ways of working? How do you ensure everyone is rowing in the same direction? Because without that, your change—already difficult and challenging—will become impossible.

    The Key to Change

    The key to any successful change is communicating your vision to your people. But providing your staff with a clear vision of what that future state could be is enormously difficult. You can outline the benefits of change, explain to them what good will look like, tell them what is in it for them, and all of these are hugely important.

    But there is no substitute for allowing people to actually feel what your future state will be like.

    Nothing compares to parachuting them into a situation where they can work through the changes required in a risk-free environment, experience the pitfalls and live the successes. As you move them to a fully functioning and productive DevOps environment, you will accelerate buy-in from your team rapidly, and give them a much more profound understanding of your vision and future state.

    The Power of Simulation

    Simulation training is one of the most effective tools to explain complex concepts and operating models quickly and convincingly. A presentation on DevOps—or almost any other topic—is not a productive method of showing someone the difference it can make to their work or their business. It’s the difference between reading a script and performing a play. More and more, companies are using simulation training as a shortcut to inform, educate and convince their teams of the value of large-scale organizational change—and DevOps is a prime example. 

    One of the key benefits of the simulation model is that people learn together. Your team learns at the same pace, working toward the same goals—and, as a result, they collectively show each other the value of change. With a traditional change program you need each employee to go on his or her own journey to recognize and adopt your vision. With a group simulation you take everyone present down the road toward a collective “aha” moment. Once that moment has happened you have an instant group of advocates who can go out to the business together and begin to effect change on a much more fundamental level.

    Simulation Brings Agility to Adoption

    Providing a simulated environment in which to train is not new; it has been used extensively and successfully by the military for decades. Commercial pilots train on simulators to provide them with as close to a real-world experience as possible of some of the life and death decisions they may need to make in an emergency. They understand the power of experiential learning.

    Simulating a DevOps model brings that power of experiential learning to your business, allowing you to immerse your people in a concentrated and deeply focused environment where they face the same challenges as they will in the real world.

    In one short morning they get to experience building a culture of DevOps themselves, making mistakes, understanding them and learning from them. It demonstrates the business value and positive impact of a DevOps approach in only a few hours, and can accelerate the adoption of DevOps across the enterprise, successfully turning DevOps opponents into advocates.

    In a world where the quality of your software can make or break your organization, it is critical to create an environment where developers and operations are not only aligned and more efficient, but also empowered and able to concentrate on developing and releasing products that add the most value to the business.

    Rome wasn’t built in a day, and you can’t effect convincing organizational change in a single morning. However, by immersing your team in a simulation, you can take a giant step forward and create a team of advocates who will go out and sell your vision for you.

    About the Author/Andrew Macintosh

    A_Macintosh_PhotoAndrew Macintosh is a Creative Solutions Director for G2G3. He works with clients across the globe, helping to understand requirements and craft technology based solutions to engage staff and customers, internally and externally. Prior to joining G2G3 Andrew ran a production company and worked within the TV industry for 12 years.

  • Walmart OneOps Won’t Be One-Upped

    Walmart OneOps Won’t Be One-Upped

    One of the biggest names in retail also is kind of a big deal in DevOps. Walmart has developed its own platform, OneOps, designed to streamline operations and keep its application development schedule in check.

    “OneOps is an open source cloud and application lifecycle management technology platform with benefits including cloud portability so developers can seamlessly move applications, databases or entire cloud environments from one cloud provider to another,” says Brian Johnson, VP of Engineering, Platform, Walmart Labs. The latter feature allows developers to leverage the broad selection of cloud environments and pricing schemes to their advantage.

    The OneOps platform deploys Walmart website adds/changes, launches new mobile features such as Walmart Pay, and creates APIs so third parties such as Hiku can tap into Walmart’s online grocery offerings, at speed and with a lower investment in the cloud, says Johnson. The OneOps platform once only managed the Walmart.com e-commerce site, but now it also serves individual Walmart stores and supports other initiatives.

    According to Johnson, OneOps undergirds and empowers the work of developers as follows:

    • OneOps continuous lifecycle management continuously auto-pilots the process of automating application scaling and repair whenever any unforeseen changes take place.
    • OneOps promotes accelerated innovation so software engineers can spin up new environments for app hosting in minutes, since the DevOps platform skirts the need to specify the intricate details of any one cloud environment by modeling that for the developer.
    • This abstraction of the cloud environment gives developers control over the tools and technologies they select regardless of the cloud provider they use.

    Life Before OneOps

    “Before OneOps, the process of updating Walmart’s website was so tedious that we rolled out updates only every two months. The process used hundreds of manual steps and required significant resources,” Johnson says. “This was time-consuming and created room for manual errors.”

    Before OneOps, A/B testing was expensive and time-consuming, taking months to set up multiple cloud environments and conduct tests. By the time testing was done, the rationale for the new feature had waned and whatever opportunity it was created to take advantage of had passed, he says.

    At that time, creating enough virtual machines (VMs) in time to handle peak shopping events and traffic would have taken teams of people months to complete, at the risk of exorbitant operating costs, Johnson adds.

    The OneOps Afterlife

    OneOps now fully manages the Walmart e-commerce platform such that in a typical day the site sees more than 1,000 new software deployments, which developers execute on demand in a span of minutes on average, says Johnson.

    OneOps serves a variety of customers such as consumers of Walmart.com, who on black Friday found their shopping experience supported by the tens of thousands of VMs OneOps was able to spin up across multiple clouds to cradle the peak traffic, Johnson says. OneOps is the DevOps and cloud platform for SamsClub.com as well.

    Solving the Single Cloud Provider Dilemma

    Walmart targeted OneOps to use multiple cloud providers easily, because of the pitfalls of being locked in to a single provider. “The fear of vendor lock-in is the major challenge to cloud service adoption. Cloud vendors like AWS don’t make it easy for customers to move from one cloud to another. The complexities of cloud service migration mean that many customers stay with a provider that doesn’t meet their needs simply to avoid the cumbersome and expensive process of migration,” says Johnson.

    Further vendor lock-in concerns, he notes, include:

    • Contracts of lengthy duration geared toward ensuring higher server utilization, maximum ROI and profitability for the cloud provider but providing little benefit for the cloud customer.
    • Lack of freedom of choice where storage space, processing power, bandwidth and tools and technologies are concerned.
    • Because it is typically difficult to find any two cloud providers that use the same tools, compatibility is an issue. “You can’t simply port your site to a new provider without rebuilding it using the new provider’s toolsets,” says Johnson.
    • “While you build and test your site on the new cloud platform, you are still paying to maintain it on the old provider, doubling your costs,” says Johnson.

    This is why OneOps abstracts the use of differing cloud providers, making porting easy.

    The Big Question Is …

    OneOps solves a unique set of DevOps challenges related to the cloud. Can you name another platform that does something similar?

  • Why Your SaaS Ecosystem Isn’t Delivering

    Why Your SaaS Ecosystem Isn’t Delivering

    Cloud computing and -as-a-service deliverables such as SaaS have the potential to be transformational, but their value depends on whether you see them as tactical, single-purpose tools or as part of a larger and more strategically integrated ecosystem.

    The cloud today is embraced almost universally at some level and seen as an essential component of nearly any enterprise, making it easier to enter new markets, transcend physical barriers and gain access to vital services. The most common, basic approach to SaaS may best be described as a JBOS approach, or “Just a Bunch of SaaS.” In this model, SaaS is used throughout the enterprise, but only as single-purpose tools, deployed to meet the needs of a particular siloed requirement. SaaS in that respect is a quick fix, a Band-Aid, lipstick on a pig—and it has not reached its full potential.

    There is a point however, where SaaS and DevOps intersect—that point where an integration framework is superimposed over a SaaS catalog, and enterprise users now gain the advantage of each SaaS being part of a greater whole. At this point where SaaS apps and data become integrated strategically, we begin to see collaboration between IT professionals, developers and line-of-business managers; we see a higher level of automation; a more agile solution that takes full advantage of the cloud model; and finally, an overall cultural shift—all components of the DevOps movement.

    SaaS’ Potential

    The potential of SaaS is well-known and includes lower costs, agile sourcing and deployment, lower CapEx and more functionality to a wider group of users. But, the greater potential has been lost on many corporate users. IT is moving to the cloud, but is it doing so for the right reasons? By focusing on the “quick fix” aspect of SaaS, companies are missing out on the bigger picture. A more successful SaaS strategy defines the future of the business, using SaaS to stay agile and to align with business needs not just the individual SaaS instances but the entire SaaS ecosystem.

    The greater potential of SaaS is achieved when it is deployed strategically, with an integration framework—and then the benefits go far beyond lower costs and CapEx. At that point, SaaS becomes transformational.

    Unexpected Results

    With all the potential, the rapid uptake of SaaS throughout the enterprise has had a few unexpected results. In addition to a marked increase in siloed information and isolated functionality that results from a lack of integration, the “dark data” phenomenon looms on the horizon, especially as the Internet of Things creates millions of new data points that never before existed. IBM Research’s John Kelly, known as the “Father of Watson,” noted recently at the San Francisco Cognitive Colloquium that 80 percent of data remains dark, and by 2020, the number will reach 93 percent.

    With the vast majority of this unused data being generated from SaaS apps and IoT deployments, the unexpected result is an enormously untapped potential. Regardless of what the app’s intended purpose may be, who it was meant to benefit and which department deployed it, useful data is being orphaned at the source. In many cases, that data may have practical uses beyond the original intent, but those uses are never seen because it never escapes its own little corner of the enterprise.

    In addition, incumbent integration platforms do not lend themselves to the cloud and lack the SaaS adapters necessary for ad hoc integration and line-of-business usage, and the solutions that do exist still lack tools for governance, API management and IoT integration support.

    The Role of IT is Shifting

    The IT department’s role is shifting dramatically. The need for agility and flexibility, along with a growing dependence on the cloud and as-a-service software, means IT no can longer continue its centralized role, lest the benefits of the cloud be thwarted. In a recent survey conducted by NetEnrich, respondents’ greatest concerns included IT is losing its relevance (18 percent) and  business applications are crashing more because IT is not involved (22 percent).

    While businesses recognize the shift, still, 39 percent are facing difficulty integrating traditional IT, cloud and DevOps, and there is no DevOps team in more than half of the IT departments surveyed.

    The Solution

    With more than half of companies lacking a DevOps team to accommodate the integration of traditional IT and the cloud, the most pressing need is to continue re-evaluating IT’s role from one of build-and-deliver to one of facilitator. Use of an as-a-service integration framework that can be guided by and facilitated by IT but used by ad hoc integrators or developers—whose specialization is not integration but have a need to connect applications and systems quickly from time to time—is the obvious next step to resolving the issues of a SaaS ecosystem that isn’t living up to its potential.

    Such a framework can be deployed effectively using a bimodal, do-it-yourself integration approach. Those integration platforms that have begun to emerge may still be inadequate to accommodate the pervasive requirements of this major shift, since they still require IT specialists to manage the integration. The use of integration platform as a service (iPaaS) overcomes this limitation by providing a framework that empowers non-specialist IT users. Specifically, IT’s role as facilitator of this self-service platform comes into play by creating and maintaining the integration platform and a library of connectors, which then can be used not only by the integration specialists, but also by ad hoc integrators and “citizen integrators” or power users within the lines of business. As a result, the inefficient priesthood of IT is then replaced with a new balance of power between IT specialists, IT non-specialists and line-of-business users, encouraging more flexibility of integration in response to different priorities.

    The iPaaS approach brings a new level of efficiency to the many new projects that are generating storms of data, such as IoT, and it supports a move away from the older IT approach that lacks the speed and agility required in today’s environment. To make the best use of SaaS, it’s time to rethink our approach and, through universal integration platforms, bring it out into the open.

    About the Author/Renat Zubairov

    Renat photoRenat Zubairov is CEO and co-founder of elastic.io, a leading innovator in as-a-service integration.

  • DevOps and Continuous Delivery: Not the Same

    DevOps and Continuous Delivery: Not the Same

    DevOps and continuous delivery are the same thing, right? Far from it. We peer through the fog to understand the difference between the two related but distinct methodologies.

    We live in an era of apps. More and more of our personal, social and work life is governed by apps—communicating with one another through social apps, booking cinema tickets through your mobile device or scheduling a business trip through the airline app. This digitization of services has arrived. Organizations that understand this sea change have a unique opportunity to jump ahead of their competitors, acquire customers more quickly and grow revenues.

    The battleground for this service development is DevOps. It’s not a product, but rather a methodology for helping organizations build teams and build software. DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other IT professionals while automating the process of software delivery and infrastructure changes. It creates a culture and environment where building, testing and releasing software can happen rapidly, frequently and more reliably.

    Organizations are marching with their feet. According to a recent study, market demand for DevOps skills is growing, and DevOps engineers are among the highest paid IT practitioners today. And it looks set to stay that way. Research in the U.K. shows that 30 percent of 300 organizations surveyed in the run up to the 2015 DevOps Summit had either started to implement a DevOps strategy or had already merged Dev and Ops, with another 13 percent planning to go down this route.

    Two Related Children: DevOps and Continuous Delivery

    So now we arrive at continuous delivery. If DevOps is about accelerating the delivery of new, high-quality services, surely continuous delivery is the same thing, isn’t it? In other words, ensuring a steady stream of new services? You might look at it as a manufacturing production line: DevOps is the machine that builds the service, while continuous delivery is the conveyer belt that rolls the services off the production line—one big unified service development cycle.

    That’s not the case. Although the distinction between DevOps and continuous delivery can be a little grey and cause confusion, there is in reality clear water between the two. Continuous delivery has become an essential ingredient for teams doing iterative and incremental software delivery. It is an approach whereby teams ensure that every change to the system can be released, and that any version can be released at the push of a button. Think of it this way: Continuous delivery aims to make releases dull and reliable, so organizations can deliver frequently, at less risk, and get feedback faster from the end users until deployment becomes an integral part of the business process and competitiveness of the enterprise.

    Gartner summed up the distinction between DevOps and continuous delivery very neatly with a report that stated, “DevOps is not a market, but a tool-centric philosophy that supports a Continuous Delivery value chain.” The analyst argues that bimodal and digital business strategies stimulate demand for improved speed and effectiveness of software delivery.

    Continuous delivery and DevOps do share common traits, though. Both methodologies are aimed at agile and lean thinking: each delivers small and quick changes; each relies on tight business an IT collaboration; and each share the common goal of faster time to market for new services.

    However, the goal of DevOps is merge dev and ops roles together—and the processes they manage—to achieve business goals. It’s all about a common, shared culture and enhanced collaboration. About clearly defined business processes.

    Automation has an essential role to play in both DevOps and continuous delivery. Automating DevOps helps your organization manage and secure continuous delivery to the business and IT users. The result is a faster, low-risk migration to a new world of composite applications, faster business innovation and better support for rapidly changing business process needs.

  • Developers Cite Startling Lack of Digital Leadership

    Developers Cite Startling Lack of Digital Leadership

    Despite app backlogs, developers say their efforts are underfunded and undertrained, and lack a priority for security

    We’ve long written about the challenges enterprises face when developing the apps they need, digging out of app backlogs and technical debt, and the overall importance of running a productive development pipeline. And, how to keep up, enterprise’s are seeing more and more citizen developers rising to fill in try to close the lag between what software apps they need built.

    Which is why it was disheartening to read in a recently published report, “Investment in Enterprise Developers is the Best Risk Management System,” based on a survey of more than 100 developers by the Application Developers Alliance, that 40 percent of respondents have experienced failed development efforts from lack of funding, and a third are concerned that current projects could be pulled for budgetary reasons. Also, despite survey after survey of executives citing security as a “top priority,” only 45 percent of enterprise developers surveyed believe that their organization sets a “high” priority for security.

    Not surprisingly, according to the survey, four out of five enterprise developers surveyed work on Windows and/or OS X, and 24 percent work on Linux. Yet only 20 percent work on mobile platforms exclusively. And, interestingly, two-thirds of enterprise developers develop their apps exclusively HTML5, hybrid or native, with native being the most common. And, not surprisingly today, cloud is the most common way to deploy apps during development, test or production.

    Unfortunately, many developers report underfunding in technology, processes and training. A third report outdated technology and processes in their organizations—more than half (51 percent) of those in organizations with more than 100 employees.

    Leadership Falling Short in Many Areas

    When it comes to cultivating processes and technology guidance, many enterprises also fall short. Only 37 percent of those surveyed said their organization has a Center of Excellence. Not surprisingly, the larger enterprises were more likely to have a Center of Excellence; however the lack of such centers is more common in North America and Europe, Middle East and Africa. Most every organization surveyed in Asia, however, has a dedicated Center of Excellence. Additionally, a surprisingly low 29 percent of of developers surveyed reported that they are required to attend training, certification programs or other continuing education.

    That’s stunning, considering that increasingly businesses are driven by their digital efforts. There’s no shortage of surveys citing this. In a recent study commissioned by CA Technologies, “The Battle for Competitive Advantage in the App Economy,” 43 percent of survey respondents said that becoming software-driven is central to being competitive today, and nearly 80 percent said that would be true in three years. Broadly, to be competitive in the years ahead, enterprises are going to have to be exceptional software companies in addition to their core current products and services. Yet survey after survey finds that enterprises are falling behind in their app development goals and are having a challenging time finding the talent they need.

    Additionally, the Application Developers Alliance survey found that only 50 percent of enterprises discuss the capabilities and skills they need to succeed, while only 26 percent integrate such competencies in their evaluation process. And, just as when it came to establishing Centers of Excellence, Asian companies stood out, with 78 percent of Asian developers saying necessary skill development is discussed.

    Centers of Excellence, the Application Developers Alliance survey found, also are excellent indicators of whether an enterprise is committed to building secure software. While 64 percent of developers believe they’re “adequately” trained to build secure software, more than 70 percent at organizations with a Center of Excellence contend that security is a high priority where they work. If they work in an organization without a Center of Excellence, that number drops to 28 percent, and 17 percent rank security as a low priority in such enterprises.

    Clearly, if enterprises expect to compete globally in the years ahead they’re going to need to step up their priorities when it comes to budgeting app development, cultivating the skills they need and building the internal organization necessary to succeed as a digital enterprise.

  • Using DevOps to Avoid Architecting Application Slums

    Using DevOps to Avoid Architecting Application Slums

    The U.K. high-rise tower blocks and built circa 1950-1980 were heralded as architectural wonders—large concrete towers easily housing the same population as the smaller houses they replaced. With large rooms, excellent views and surrounding open spaces, they initially were popular residences—low cost and futuristic.

    But looking futuristically sometimes has a habit of coming back to haunt you.

    Due cost-cutting, substandard materials, demanding deadlines and rushed construction practices, these modern-age housing miracles became the new slums of the day. By replicating tower-blocks across the country, town planners unwittingly replicated bad designs everywhere. The results: undesirable housing and elevated crime levels, leading to slums and urban decay. Even the surrounding open areas were neglected because no one had ownership over maintenance and supervision.

    In IT, we have our own design and architectural calamities.

    There are many similarities between existing IT apps and decrepit old tower blocks. IT monoliths can be hard to scale, requiring costly maintenance to avoid disrepair. They’re also tough to police, with vandalism and theft being a constant problem. Add to this integration issues (IT’s version of unsupervised open spaces and pathways), and we’re left with systems inadequate to meet the needs of modern digital business.

    Enterprise architecture must change with the times

    DevOps, with its focus on operations and development collaboration across the entire service life cycle, is now seen as the answer to some of these problems—an approach underpinned by agile and lean principles for rapidly delivering high quality digital services. That sounds great, but let’s not forget enterprise architecture (EA), because without it we could still be building IT slums—only more of them and much, much faster.

    Of course, many DevOps stalwarts may argue (with some justification) that heavy EA practices and frameworks haven’t evolved to match the pace of agile. Iterative-style development means where you start isn’t necessarily where you finish, necessitating a transition from set-in-stone architectural designs to a fluid mix on continuously evolving decisions. And, if EA can’t adapt, autonomous and self-managed agile teams increasingly are empowered to make architectural calls.

    But great developers aren’t necessarily brilliant architects; they’re not hard-wired that way. It means they could be charging down a development path without architectural guiderails, or tactically making team-based decisions that compromise program-level objectives. For example, the scalability and performance needed to support a business strategy of tripling the customer base and increasing satisfaction scores could get lost because development focuses myopically on delivering more functionality.

    However, we can’t just lay the blame on developers. Enterprise architects must recognize that any misalignment between their processes (especially the rigid and static ones) and the vision of an increasingly software-driven business will only further isolate the practice.

    Architecting new fluid guidelines and principles

    The role of EA in an agile context is still up for debate, but this shouldn’t hold us back. By using architects and fluid guidelines means we can maintain the pace of delivery while preventing chaos. The trick of course is to limit architectural over-engineering while providing developers with a minimum set of EA to avoid technical and architectural debt.

    Even in minimal mode EA can still help developers identify quickly what should be considered during design. The aim is to guide developers into understanding what architectural facets make up a successful application, and more importantly, how new ways of thinking can support longer and more sustainable software innovation.

    Interestingly, these practices can be presented in a “slum avoidance” context:

    • Avoid substandard or unsupported materials – The tool chains being used will probably comprise both commercial and open source software, but beware of anything unsupported. Just as the cost of maintaining tower blocks reached unsustainable levels, so too, will support burden on an organization if software isn’t commercially backed, especially in IT operations. Also, work with development to understand where constraints lead to testing compromises—the “construction shortcuts” syndrome, resulting in more defects and technical debt.
    • Never use new technologies to rehouse old problems – As tower blocks degraded and vandalism increased, many local authorities tried to contain the situation by housing “problem groups” in the same block. But that just increased problems. Enterprise architects can make the same mistakes—for example, laying down crazy edicts that everything must be containerized, even some legacy apps; not understanding that runtime independence only extends the life of problem applications;  or providing no incentive to drive improvements and clear existing legacy IT slums.
    • Monitor and manage your sub-contractors – Whatever cloud model you adopt, abstracting away the infrastructure or application stack frees development to focus on coding. That’s great, but don’t forget “PaaS-ing” apps to the cloud doesn’t mean relinquishing ownership of application performance and the end user experience. To this end, architects must act as cloud-brokerage advisors—for example, working to ensure any cloud service provides open APIs, so that monitoring can be seamlessly incorporated into a unified solution.

    Of course, architecting great new digital services with DevOps is only part of the answer. The innovations of today may become legacies of the future and many new apps must also integrate with existing systems. It’s essential, therefore, that architecture covers both bases: working in minimal mode to ensure fast construction of quality services, but also applying standards and governance when needs dictate and systems change.

    No matter how good your app designs look on paper, bad architecture just means building more problematic systems and never clearing the existing slums.