devopsy.kinsta.cloud

Tag: Strategy

  • Scrimmage for Control: On-Premises Vs. SaaS in the Observability Super Bowl of 2024

    Scrimmage for Control: On-Premises Vs. SaaS in the Observability Super Bowl of 2024

    Observability means data. It encompasses a set of practices and tools designed to track the performance and health of software applications, providing insights into the “why” behind system behaviors, not just the “what.” At its core are data pillars we’ve learned how to work with and hopefully get the most out of—metrics (quantitative data on system performance), logs (recorded events within the system) and traces (detailed views of request paths through the system) that offer a comprehensive view of the system’s operation in real-time. SaaS is where the industry has been turning towards for the past decade. It’s easy to operate and upgrade and takes away maintenance and manpower requirements.

    But, using a SaaS solution where data is stored on the vendor’s infrastructure can be compared to playing a football game at your opponent’s home field. Your team does not own the field and must play along with conditions that are outside their comfort zone. While your team can still strategize, execute plays and score points, the control over the playing environment, including the surface, lighting and even some rules, lies with the owner of the stadium (in this case, the SaaS vendor).

    You don’t get the home-field advantage and the comfort of your familiar surroundings, and you also can’t control the audience’s shouts and cheers in the stands across the arena.

    Just as a visiting team must trust the host’s management of the stadium and adapt to its conditions, organizations using SaaS solutions entrust their operational data to third-party vendors. They must trust its data protection policies and privacy agreements to ensure that the organization’s data is handled securely and in compliance with relevant regulations.

    And even more importantly, they have to adhere to its hosting costs.

    Let’s Leverage the Home-Field Advantage

    The alternative is clear: While playing on your own field, you, the coach—hell, the entire team—know this field by heart, and you know best how to keep and enforce your own rules.

    Just as a football team controls the ball and decides on the play, having on-premises data means a company or organization keeps its data within its infrastructure, offering direct control over its storage, management and security. The organization decides how to deploy, use and protect this data and even how to manage the tradeoff of data costs.

    The downsides? Playing on your home field at all times means you’re running slower than the world out there. You’re not quick to update your software to the newest common practices and you’re tasked with maintaining another stack—your observability stack—on top of building your product, which serves your users.

    There’s Another Way. Play the Data on the Scrimmage Line

    In football, the scrimmage line is the imaginary line across the field where the ball is placed at the start of each play. This line serves as the point of engagement between the two opposing teams, with specific rules governing how players can position themselves and how the play begins.

    What if we can keep the data on-premise, in the home field, a little like having the ball on our side of the scrimmage line, within our team’s possession and control? We have the ball, and we decide and strategize how to advance the ball or score from the position behind the scrimmage line, but we can still interact with the outside world (or the opposing team) under a set of rules to which we both adhere.

    This is exactly where observability solutions are heading: A combination of the advantages of SaaS—easy to update and maintain value, with an easy way to distribute the solution inside the organization, alongside the advantages of on-premise—data privacy, data control and full transparent and controllable data costs.

    I call this approach inCloud. It is a modern on-premises approach—data in your cloud environment, protected and controlled by the user, but still governed, managed and served with a guaranteed SLA just like the best SaaS offerings out there.

    Just like the scrimmage line in football that provides a clear boundary and set of rules for how the game is played, inCloud acts in a similar way. Data is kept on-premises, allowing the organization full control over retention, privacy and data integrations. And on the other hand, inCloud defines a set of strict rules under which a control plane is allowed to operate and pass the scrimmage line, or past the organization’s cloud borderline, to manage and access the data like a SaaS solution does best.

    So when we sit down to watch the Super Bowl this Sunday—let’s use that halftime show to think about where we’ll be taking our organization’s observability capabilities in 2024. Will the data be in our hands, crossing that invisible scrimmage line? Or will we lose to our opponent’s home-field advantage?

    May the best team win.

  • 4 Things to Consider When Integrating Generative AI

    4 Things to Consider When Integrating Generative AI

    Generative AI has emerged as one of the most influential innovations of the past two decades. ChatGPT gained 100 million users in record time, and new generative AI-powered point solutions emerge every day.

    Considering the current state of VC funding, the surge of investment dollars in AI companies is remarkable. Microsoft’s $13 billion investment in OpenAI and AWS’ $4 billion investment in Anthropic (who themselves just raised a $850 million Series C round) demonstrate the tremendous excitement around Generative AI and how it will shape the future of tech.

    As newer companies like Adept and Cohere are emerging, existing SaaS companies are integrating generative AI capabilities into their products and services. However, in the race to join the hype, many companies are building first and strategizing later. Before diving headfirst into building a generative AI solution, companies should carefully consider a few crucial factors, including model selection, usage tracking, monetization and customer transparency.

    1. AI Model Selection: To Build or to Buy?

    Companies must first consider whether to build a generative AI model from scratch, or whether to use a pre-existing model from one of the major AI vendors. This decision depends on the level of customization and control desired, as well as the resources and expertise available.

    Building a from-scratch model is likely infeasible due to the inaccessibility of the necessary hardware. The GPUs needed for cutting-edge model training and inference are currently only built by NVIDIA, and there is stiff competition and long lead times for any company looking to acquire the product. What’s more, large cloud and AI companies like OpenAI, Google, Meta and Tesla already have built systems with up to 100,000 of these chips. New companies looking to enter the scene would face a steep climb to assemble the infrastructure needed to even begin to compete with the current classes of models.

    Small or new companies do not have the funding or time to invest in building their own infrastructure or generative AI models, so a key business decision is to select the best vendor and model for the use case. While ChatGPT is the most well-known, there are other specialized models that can be better suited for certain use cases. For example, OpenAI’s DALL-E is built for image generation, while Anthropic’s Claude 2 is built to perform better with specialized tasks such as legal and math and to handle long-form inputs.

    Regardless of the AI vendor you choose, you will be charged based on your usage with them, which, by extension, is your customers’ usage. Tracking this usage is critical to your generative AI solution becoming profitable.

    2. Metering AI Service Usage: The Key to Success

    Implementing usage metering for generative AI services is crucial at both the individual user level and at the global or system-wide level. This is because usage tracking is valuable to all business functions and is a critical element of any modern PLG strategy.

    For example, customer-facing teams can leverage usage data to proactively track account health and to contextually recommend new solutions and approaches. Usage history provides valuable intelligence to account teams for up-selling, cross-selling, and contract renewal. Product teams can identify usage patterns and customer segments, as well as areas of friction or improvement for new feature development.

    Usage data also plays a major role in developing pricing plans that align with customer expectations and overall market trends. It can be used to inform pricing plan development and optimization to ensure the rates are sensible for the level of consumption and value being realized. Without tracking usage, this becomes a guessing game or a futile exercise in “gut feel.”

    Usage data is imperative to calculating your internal costs. Vendors commonly charge according to a usage-based model for these generative services–per word, per token or per generation are some common models. In any case, having accurate, granular usage data is a must-have for calculating internal costs and, in turn, customer-facing pricing.

    3. Monetizing Generative AI Services: Usage-Based Pricing Strategy

    In the rush to beat competitors to market and offer generative AI services to customers, do not neglect to lay the groundwork for monetization from day zero. It is much easier and more efficient to build with monetization in mind from the start than it is to backtrack and try to monetize a service once it has been offered, particularly when usage-based pricing is involved.

    Usage-based pricing has emerged as the optimal pricing strategy in the AI domain. This is because service usage varies over time for each customer. These services are priced by the vendors according to a usage-based pricing model. Since the backend costs of the service are elastic, the frontend, customer-facing pricing should also be elastic.

    As a roadmap to monetization, follow these steps:

    -Meter service usage to understand segments and patterns

    -Calculate internal costs of usage using vendor pricing

    -Using the information from steps 1 and 2, build customer-facing pricing

    -Track revenue and margins and continue to iterate with pricing as needed

    4. Customer Transparency: On-Demand Access to Usage and Billing Data

    Prioritizing transparency and clear communication with customers is non-negotiable. Ensuring that usage and billing data can be seen at any point in the billing cycle helps foster trust between the company and its users and eliminates billing surprises when the invoice is delivered.

    Adopting Transparent Communication Builds Trust With Customers

    Invest in creating a customer-facing application, portal or experience that allows for on-demand access to usage and billing data. The beauty of combining this level of visibility with usage-based pricing is that customers are empowered to pay for only what they use while viewing usage statistics on demand and modulating usage as needed in real-time to keep the spend within an acceptable range.

    In practice, usage data is available on a per-query level from the vendor’s APIs. For example, for any generation action, OpenAI will show the precise number of tokens consumed for both the prompt and response, as well as all details around the model type and context needed to identify the per-token rate from the vendor pricing. It is important to collect this data and build a user-friendly way to display it back to customers in an app, portal, or website that allows for on-demand access and browsing.

    Conclusion

    While planning to build a product with generative AI, take all of the above factors into account. Do not make the mistake of racing to deliver a technology solution without also considering the business implications and monetization strategy. With all the hype, excitement and investment around generative AI in 2023, it is akin to a modern-day gold rush. Don’t show up to the gold rush without a shovel.

  • Preparing for Machine Learning Readiness to Unlock its Full Potential

    Preparing for Machine Learning Readiness to Unlock its Full Potential

    With the rapid advancement of artificial intelligence (AI) and machine learning (ML), companies need to understand and evaluate their readiness to adopt these technologies and drive material business outcomes.

    To assess a company’s machine learning readiness, we must consider several key factors, including:

    ● Vision/strategy
    ● Data availability
    ● Expertise, infrastructure and resources
    ● MLOps and governance

    In this article, I will review these three key factors in assessing ML readiness and how they can help your organization prepare.

    1. Vision/Strategy

    A company’s vision for its AI/ML strategy is essential to consider when assessing its machine learning readiness. This includes ensuring that the expected AI transformation aligns with the company’s strategic goals and that it will ultimately be meaningful for the business. To evaluate this, organizations should consider their overall strategy for AI adoption and determine how it fits into their broader business objectives. Additionally, companies should identify specific use cases and applications of AI that support their goals and how those can be implemented to drive business outcomes. A company that has already woven an AI/ML strategy into its business planning is in a far better position to assess its ML readiness.

    2. Data Availability

    I believe data availability is another crucial factor in assessing ML readiness. Machine learning algorithms require vast amounts of data for training and validation to offer real value. It would be challenging for a company to successfully implement machine learning without access to sufficient data, or they’d risk a model that cannot be trained effectively and that would, in turn, perform poorly. Companies must consider the quality and quantity of data at their disposal, as well as any potential future data sources when assessing their readiness for this important element of machine learning. I also think organizations should consider the feasibility of collecting and integrating data from various sources, whether internal or external, to have the most impactful machine learning initiative.

    3. Expertise, Infrastructure and Resources

    It’s no secret machine learning requires a diverse set of skills, including data science, programming and statistics, and every organization must be sure they have all the necessary talent and resources when building that function. These resources include data preprocessing, model development, model validation, deployment, monitoring, maintenance and the ability to train and onboard new employees to oversee AI/ML programs. Companies should also enable collaboration across these different units and roles. If a company chooses to outsource machine learning projects to third parties, the skills needed internally may need to shift toward project management and collaboration with external teams, as well as a nuanced and sophisticated understanding of the business problem, industry and technical capabilities of the vendors, to ensure proper execution.

    A company’s systems and technology stack are key to any operation. This includes selecting the right technologies and tools to enable the end-to-end creation and use of AI/ML-powered analytical applications. Before adopting ML, companies should evaluate their current stack to determine if it’s equipped to handle AI, including the availability of hardware, software and programming languages. Organizations should also consider the costs associated with selecting and implementing the right technology stack for AI/ML, including the costs of any necessary upgrades or new investments. Decision makers should also research and evaluate different technology vendors, their products and services, and find the one that best suits their needs in regards to cost, value and alignment with long-term goals.

    4. MLOps and Governance

    To be machine learning-ready, I find it important for companies to have machine learning ops (MLOps) in place. MLOps is a set of practices that allows companies to manage the end-to-end machine learning life cycle. It covers the entire machine learning process, from data preparation to model deployment and monitoring. Implementing MLOps includes continuous integration and delivery, model versioning and management and monitoring and alerting. Additionally, MLOps practices such as automated testing, model evaluation and deployment can help organizations improve the overall efficiency and effectiveness of their machine-learning efforts over time.

    A company’s governance structure for AI/ML adoption is another factor to consider when assessing machine learning readiness. Companies should evaluate their existing governance structures and determine if they are equipped to handle the implementation of AI, including data governance, compliance and risk management. We must also consider how we will manage the deployment and scaling of AI, including the development of policies and procedures to govern the use of AI and the identification of internal stakeholders and decision-makers who will be responsible for its implementation.

    Ultimately, I believe the key to machine learning readiness is to assess current capabilities, identify areas for improvement and develop strategies to address them. By taking the time to assess their machine learning readiness, companies can ensure they are in the best position to take full advantage of the benefits that machine learning can provide.

  • Implementing DevOps? Start with a Strategy

    Implementing DevOps? Start with a Strategy

    Organizations today are focused on improving the IT delivery process and taking it to the next level. DevOps plays a key role in achieving this goal, if it’s done right. But while the concept of DevOps is not new—it’s more than a decade old—a significant percentage of organizations have not yet implemented or are facing challenges in leveraging DevOps to achieve the intended benefits. Why do some companies achieve success with their DevOps implementation and others struggle? Simple: Those making DevOps work for them started their journey with a clear and implementable strategy. In fact, a number of organizations have formed their business strategy around DevOps.

    The relationship between DevOps and agile is complementary; however, DevOps implementation must be looked at differently than agile. It needs to be treated as a separate initiative other than the regular IT delivery scope until it’s established. It requires strategic thinking, significant focus and commitment make it successful.

    Key Pillars of DevOps Strategy

    The four key pillars for DevOps strategy are:

    • Identifying the vision and goals.
    • Identifying foundational factors.
    • Critical success factors.
    • Basing the strategy on measurements to track the progress and realization of benefits.

    Vision and Goals

    Drivers and challenges form the basis for vision and goals. Before embarking on the path to DevOps, it is crucial to analyze the “as-is” situation and understand the current challenges and drivers for doing DevOps. Current challenges could include:

    • Too many production defects.
    • Business stakeholders demanding features that the team is unable to deliver.
    • Painful deployments.
    • Team burnout and frustration.
    • Deployments done as ceremonies with multiple teams on call.

    If any of these sound familiar, that’s a sure sign your project needs DevOps.

    Drivers for creating the vision and goals may be external or internal. External drivers may be improving customer satisfaction by meeting expectations around availability, reliability, usability, performance, features, value and time to market. Internal drivers may be improving operational efficiency (speed, throughput, quality) or improving employee loyalty, improving technical capabilities or simply making deployments less painful.

    Critical Success Factors

    Below are the key factors in implementing the DevOps pipeline which includes continuous integration, continuous delivery and deployment. The continuous integration aspects cover configuration management, code packaging, branch/trunk implementation, static code quality analysis, code reviews and static security scans. The objective of continuous delivery and deployment is to move the code from the lower environment to the production environment in an automated way. The key aspects as part of the continuous delivery are embedding continuous testing within the pipeline and automating the applicable tests—unit testing, system testing, API testing and/or browser testing, along with the non-functional testing (performance and security). Another key aspect is integrating continuous monitoring into the pipeline—infrastructure monitoring (application and database servers) and application end user monitoring, which provides key input and metrics on how users are using the application and can be leveraged to improve customer experience.

    Key pillars of DevOps strategy

    Foundational Success Factors

    Foundational factors are critical for DevOps to be successful in an organization. Before embarking on the journey, ensure foundational factors are in place, such as management buy-in and support, maturity of the current agile process, conducive culture, collaboration among teams, CI/CD tools and availability of technical skill sets.

    It can be difficult for agile project teams to focus on working on the DevOps items along with the sprint-specific “functional” requirements. One way to increase the priority is to include the DevOps-related items in the sprint. That said, it can be challenging to focus and achieve DevOps objectives, as they may take a back seat to functional requirements during the sprint. Another option is to form a DevOps-focused group from within the projects (based on technical skills and inclination for innovation) that is assigned with the task of building and implementing a CI/CD pipeline. If necessary, this group can get help or expertise through suppliers. Forming a DevOps-focused group has been shown to be helpful in terms of achieving DevOps objectives.

    Metrics: Identify, Measure and Continuous Improvement

    Tom DeMarco famously said, “You can’t control what you can’t measure.” In DevOps, metrics and measurement are critical for success, as implementations take time. Metrics, therefore, should be aligned with goals and vision to track progress. Also critical are identifying the effectiveness of the identified metrics and making any revisions to existing metrics, as well as identifying and adopting additional elements for success.

    It is helpful to quantify the “as is” situation at the start of the implementation by measuring the metrics. That allows you to see the kind of progress being made on each of the aspects as you go along.

    The metrics can be categorized as per the balanced score card perspectives:

    • Financial (e.g. cost savings).
    • Customer perspective (e.g. time to market, number of defects per deployments).
    • Internal perspective (e.g. average deployments per sprint, number of successful deployments, average time per deployment, mean time to repair).
    • Innovation perspective (e.g. number of enhancements to pipeline).

    Though there are multiple DevOps aspects that can be measured, it is better to start small to avoid being bogged down by measurements. For example, you can start by capturing the average time per deployment or time to market and add other metrics as you go along.

    Conclusion

    DevOps is a critical initiative and focus area for organizations today. To be successful, a DevOps strategy—a top-down approach which provides clarity and transparency within the organization—is necessary. The key pillars of DevOps strategy can help lay the foundation and prepare—and keep—organizations on track during their DevOps journey. The strategy can be part of the project plan for a single project or can be leveraged for scaling out a DevOps initiative throughout the enterprise.

    — Girish Kulkarni

  • Don’t Let Cultural Debt Bring Down Your Business

    Don’t Let Cultural Debt Bring Down Your Business

    Businesses today are faced with myriad challenges to innovate and optimize. In doing so, we often need to make decisions that borrow against the future. This can come in a tangible form, such as taking money from investors to fund growth, or in more inconspicuous forms, such as making tradeoffs in technical decisions. When we make such tradeoffs, we expect them to come at the cost of additional technical work in the future; however, these decisions can also borrow against an externality that is often overlooked: culture.

    Technical Debt

    Technical debt occurs in the development of software when the “easy path” is taken to solve a problem rather than using the best overall solution. The concept implies that the time saved now will need to be paid back later (with interest!) in the form of rework.

    Ideally, technical debt is incurred knowingly, i.e. a decision to take a shortcut is made deliberately to increase velocity, and it is flagged to be fixed before becoming a compound problem. In calling out technical debt as such, we can better analyze our decisions, considering their net present value and future opportunity costs. By documenting it, we gain better insight into the responsiveness and flexibility of the code base. Having a strategy around managing technical debt has therefore become an essential discipline in the management of software products.

    Technical decisions also have an impact on the culture of a company, though, and this facet of technical management is often overlooked. “Cultural debt” can be taken on unknowingly, and the unmanageability that flows from it can be difficult to ascertain.

    Cultural Debt

    Cultural debt is when we make a technical decision that borrows against the culture of the organization. Such decisions can introduce divisions between teams, deteriorate communication or even weaken the effectiveness of leadership. These types of decisions need to be made regularly throughout the software development life cycle, and it is therefore critical that we begin to identify them, call them out and manage them accordingly. If the interest goes unpaid we can end up with a toxic environment that is difficult and onerous to manage—we risk a paradox wherein attempts to innovate can stifle progress.

    A Closer Look

    Just as with technical debt, a business ideally will have a strategy for managing cultural debt rather than allowing it to accumulate and bog down the business. Typically, decisions that involve cultural debt will impact on areas such as:

    1. Mission: Ensuring connection to the company mission and that there is minimal variance in how the mission is understood by different teams and departments.
    2. Values: Effective and reliable transmission of company values, the ability to apply them consistently and ensure that they are clear and tangible.
    3. Communication: Fostering openness and the ability to discuss, providing channels for communication and using channels effectively with clarity of purpose and minimal “noise.”
    4. Visibility: Providing the ability for everyone to see up, down and across their organization.
    5. Attitude: Happiness of employees, their effectiveness and retention.
    6. Leadership: Ability for leaders to govern effectively, and influence across departments

    When making technical decisions, we need to think outside the box and consider how our decisions will affect these cultural dimensions of the business.

    To reinforce the concept, let’s look at some current issues that the modern enterprise is being confronted with:

    1. Domain-Specific Tooling – As roles become increasingly specialized, a best-of-breed approach provides the tools needed to perform complex tasks. Unfortunately, tools create silos, and more tools means more fragmentation. Furthermore, in a world where tools are proxies for business processes, domain-specific tooling can cut off teams from processes, reducing visibility and impeding communication. This mean the business will need to devote cycles to meetings, emails and other noisy distractions just to pay down the interest and get the visibility and coordination needed for cross-functional effective leadership. Paying down the debt requires tool integration, and without an infrastructure to reduce the cost of integrating, domain specific tools can be a heavy debt to carry.
    2. Customization – Often we see the introduction of new tooling without the requisite investment to customize them to the business. Tools such as ServiceNow or Salesforce are highly valuable for being specialized to their use cases, but they still require customization to be effective. For example, when customer data is stored in notes fields rather than using structures data captured in the tool, visibility and reporting is gradually reduced and employee frustration abounds. The decision to introduce tooling should be made with the understanding that customization will be required and must be maintained over time to keep pace with the organization’s culture as it changes.
    3. Bimodal IT – One strategy for enabling cutting edge technologies is the use of a “bimodal” structure with essentially two IT organizations that operate under different constraints. While bimodal IT may be valuable for encouraging adoption of new technologies, it also encourages confusion of responsibilities, cross-team rivalry, knowledge silos and double work. The longer the structure remains, the deeper cultural divide and the more difficult an eventual transformation will be. The decision to introduce new technologies or practices using a bimodal structure should be done deliberately, cautiously and with clear goals in mind.
    4. Technology Selection – Often we are presented with new technologies that promise to deliver great benefits. Let’s assume that the new technology passes a technical assessment and is found to deliver on the promises: e.g. a language such as Clojure or Kotlin really will simplify development and increase velocity, or a new delivery tool does indeed remove a key bottleneck. Adopting such a technology invariably creates some cultural debt—developers unfamiliar with the new language may feel alienated, new silos will form around knowledge and expertise and tribes could be forcibly broken apart. Technology decisions that ignore cultural debt will involve more cycles and greater risk, while those that recognize it will implement new technologies with those issues in mind, providing the cross-training and collaboration needed to ensure success.
    5. DevOps – The dirty secret about DevOps is that it involves the introduction of a number of technologies and technical practices that carry a large amount of cultural debt. This can actually tear an organization apart if that debt is not managed closely, and it is therefore why DevOps—despite being closely associated with technical practices such as automation, infrastructure-as-code and CI/CD—is regarded as primarily a cultural movement. In the enterprise, DevOps technologies threaten roles, responsibilities and livelihoods. The cultural debt actually does outweigh the benefits, and DevOps transformations need to focus on cultural issues first before attempting to implement the associated technologies. This is common sense that we learned from observing lean manufacturing transformations in the nineties, which involved a similar change situation where technical practices became a function of culture.

    Cultural debt, like technical debt, can be hard to detect. If your business does not have a strategy for paying off the debt, or at least one for paying down the interest, the result will be a heavy load of cultural issues weighing down decisions and processes.

    Key Measures for Managing Cultural Debt

    • Understand your stakeholders: In an agile world it is easy to overlook stakeholders. We can learn from the disciplines of business analysis and project management, though, where stakeholder analysis is a core componency and key practice in work management. It is not possible to do a thorough breakdown of stakeholders for every technical decision, but an actively maintained stakeholder matrix will increase your mindfulness and can be referred to for a free sanity check when needed.
    • Understand your culture: Your organization is filled with cultural artifacts—if you are not aware of them and taking the time to manage them, you will not be able to assess cultural impacts. These artifacts can include mission and value statements, organizational and tribal structures, meeting cadences and compositions, control systems, routines, rituals, symbols and even legends. Think through your cultural artifacts and ensure that they match intention and are understood by leadership.
    • Obtain buy-in: Getting buy-in means giving people a stake in the game. Imposing technology decisions on people will not only result in a requirements mismatch, but it fosters discontent and mistrust. You can make a large downpayment on your cultural debt by bringing affected parties into the decision-making processes early. This has been shown to be very effective in helping pass decisions even when they have negative consequences.
    • Embrace the ‘Three Ways’: We can borrow from the DevOps movement the Three Ways, which provide a solid foundation for undertaking any technical work: Systems thinking encourages considering how decisions impact the whole system, not just the local area; feedback loops allow continuous feedback and communication about impacts; and continual experimentation and learning ensures that the organization is adaptive and resilient. Leadership that embodies the Three Ways is issued debt on very good terms.

    Conclusion

    Peter Drucker is quoted as saying that “Culture eats strategy for breakfast,” and the examples we’ve seen here highlight this. The best technology in the world cannot compensate for a broken culture, and a broken culture can be the result of a succession of ill-considered technology decisions. Understanding cultural debt is a key differentiator in being able to leverage Conway’s Law rather than be trapped by it. A key aspect of managing technology going forward will therefore be to identify and control this cultural debt as it is being created, and ensure that the organization is able to function with full-capacity engagement.

    About the Author / John Rauser

    John Rauser is the IT Manager of Tasktop Technologies, a global enterprise software company. As part of his role, he is responsible for specifying, managing and administrating software lifecycle tools, witnessing first-hand the impact they have on users and the business on a broader scale. He also serves as VP Operations at the board of the Project Management Institute – Canadian West Coast Chapter, providing leadership and expertise on technology issues. He has deep passion for discussing the business impacts of technology and analyzing strategies for IT management.

  • Part 2: Meeting relentless mobile app demand

    Part 2: Meeting relentless mobile app demand

    As we discussed in  Meeting the Relentless Mobile App Demand of the Enterprise, the enterprise thirst for mobile apps will far outstretch what enterprise internal development teams will be in a position to produce.

    Developers will need every edge provided to them in order to help their enterprise success. And there’s no doubt that IT teams need to be agile and move as quickly as possible and this is as true with mobile development than anywhere. By not being able to meet the increasing demand for enterprise mobile apps, enterprises can’t be as effective and productive as they need to be. That creates substantial business opportunity costs.

    Here are some ways I think enterprises can improve the mobile app development efforts, in addition to what Gartner suggested, detailed in our part 1:

    Adopt agility. Enterprise IT is changing rapidly. The tight collaboration with development and operations teams, drive for agility, continuous development and other approaches that are increasingly mainstream are pushing applications out into production, and updating existing ones, more quickly than ever was before possible. Not only do successful DevOps organizations have short app backlogs, they are more innovative. Our special guest contributor Matt Selheimer wrote am insightful series that culminated with DevOps with purpose: ACT-ing with greater agility that details how to be more agile through DevOps practices.

    The more agile your organization, the more swiftly they can re-adjust and move always be producing the apps that matter and those that will drive the greatest business impact.

    Leverage APIs. Instead of building apps from scratch and creating more data silos, take a page from Gartner’s advice on mode 1 which is building infrastructure and APIs. Most existing large enterprises have enormous data and application and database silos. One effective way, when possible, to unleash that data and reduce silos is through APIs. APIs are the most straightforward way to build the capabilities the business needs through    extending the utility of existing applications.

    Leverage the cloud to the hilt. Whenever possible, it’s time to go cloud first. It’s time to gate legacy on-premises systems and maintain them until they can be displaced. This will include public, private, and hybrid cloud architectures – but the more rapidly legacy on-premises systems can be retired the more agile IT can be.

    Our post, Three tips for maximizing efficiency in the age of the hybrid cloud environment, provides insight into how to manage hybrid cloud environments.

    Choose cloud and development platforms carefully. There are a number of other critical platform questions, too: Can the data be provided wherever the user needs it? Does it help alleviate security, privacy, and regulatory compliance demands? And can the platform help with role-based identity management and provide for auditable access control?  All of these things being provided as utility help expedite application development and clear your app backlog.

    The more people in your organization who can develop the better. This could come in the form of training non-developers to build some of the app capabilities they need in cloud platforms and with very high level coding tools. It’s easier now than ever before for anyone to create business process workflows with hardly any code.

    Be MVP lean. The Minimum Viable Product (MVP) is a viable way to identify mobile apps that are in need and will likely provide the most immediate value. Simply defined, the MVP consists of what is only necessary to get the task done and little more. If the app is successful, it can be improved upon and iterated based on user feedback and business need.

    One way DevOps helps to achieve this is through splicing development time so many apps can be worked on incrementally, and the MVP concept is ideal for this type of workflow. It makes it easy to re-prioritize apps and new incremental work on existing ones based on pressing business priorities.

    I’m sure there are other ways to help make mobile app development efforts both effective and strategic to the enterprise rather than fire-fighting app demand. If you have any ideas, we’d like to hear them in the comments below. What strategies, tools, techniques are your organization using to increase mobile app development efficiency?

  • Does DevOps spell death for Line-of-Business (LOB) Applications?

    Does DevOps spell death for Line-of-Business (LOB) Applications?

    Perhaps wrongly, “DevOps” has been associated with “new” and “that thing for the cool kids” and the “hipster developers”. This is used both as an excuse and as a source of animosity against the movement. But more subtly, I sometimes observe IT departments that acknowledge DevOps as a thing, but claim it wont work for their applications. I always pause and ask: What are the applications they are referring to, and are they correct?

    (more…)