an ecosystem of shared interest

There is an opportunity to bring some things towards a binding time.  It has been difficult to conflate the composable edge with an accelerator because there is so much edge everywhere, picking a place to start became a kind of non-starter.

At least so far.  Working with members of the Cloud Native Computing Foundation’s Cartografos Working Group, I was introduced to the idea of an Internal Developer Platform.  My version became the Internal Developer Experience Platform in order to conflate the Internal Developer Platform with the Developer Experience trend.

What occurred to me was that if there was an Internal Developer Experience Platform to support software development in a cloud-native context, there could certainly be Developer Experience Platforms in many engineering practices.  We might call that the a-DEP, or the Anything (needed) Developer Experience Platform.

Having found an open-source solution which could serve as a micro-controller for an IDEP generation process, and a macro-controller to support the journey of a developer through the experiences provided by the platform, we are on our own journey to a-DEP’ing things in general.

By way of this design pattern, it was discovered that the path of a software development organization from a shift left model to an IDEP model could be a digital twin for the process of building a composable edge platform.  Which led to the following realization.

Let’s say that there are four centers of organizational experience in order to separate the system supporting the composable edge tooling from an external environment.  The four centers are Information Technology, an External user community, an Internal user community, and Operation Technology.  By selected these four topics, we get access to a myriad of design patterns we can use to track our work-in-progress on something similar to the Gartner digital marketing tube map. 

To be more explicit, Information Technology provides the Open Group IT4IT version 2.1 material to enable manageable data driven process techniques.  Serving an External User community practices can be derived from Customer Relationship Management, Account Based Marketing, and digital marketing practices.  Serving an Internal User community models and metrics can come from human resource studies and organizational governance mandates. 

Operation Technology has most often been used to describe the assets and protocols found in facilities management.  Again, today, that has a different aspect to it as organizations have the option to support work from home or work from anywhere rather than work in the office.  These developments have required organizations to acquire assets and tools to manage team interaction-at-a-distance.  It is more helpful to think of this as an information supply chain challenge than strictly a technical one.  And there are many supply chain models and metrics we can use to manage this type of workplace.

With the four centers of organizational experience forming a boundary for purposes of solution delivery to an organizational requirement in an acceptable timeframe, we have edges and arcs for use in the development of the digital twin. 

As IDEP solutions become more widely understood and adopted within market segments, we have the opportunity to match the development of composable edge platforms along the way.  Developing a program to support that thesis is a next step.

For now, the ChatGPT response that started this train of thought is provided below.

Session 47.0.0 Setting the stage for a journey

What is the golden path when moving from shift left development to an internal developer experience platform using the 12-factor app as a guide?

The golden path when moving from shift-left development to an internal developer experience platform (IDEP) using the 12-factor app as a guide involves the following steps:

  1. Evaluate Shift-Left Practices: Assess the effectiveness and impact of the shift-left development practices implemented so far. Identify areas for improvement and understand the challenges faced by development teams during the shift-left journey.

  2. Understand the 12-Factor App Principles: Familiarize yourself with the 12-factor app principles and their relevance to an IDEP. Understand how these principles can be applied to create a more developer-friendly and efficient development environment.

  3. Identify IDEP Goals and Objectives: Define the goals and objectives for the IDEP implementation. Determine the desired outcomes such as improved developer productivity, faster onboarding, streamlined collaboration, and enhanced development practices.

  4. Infrastructure Provisioning and Automation: Establish an infrastructure provisioning process that enables developers to easily spin up development environments with minimal effort. Utilize tools like Kubernetes, Docker, or Infrastructure as Code (IaC) platforms to automate the provisioning and configuration of development environments.

  5. Development Environment Standardization: Define and enforce development environment standards to ensure consistency and ease of use. Set guidelines for IDEs, code editors, programming languages, version control systems, and other tools used by developers. Provide pre-configured development environments or development kits that include the necessary tools and dependencies.

  6. Implement IDEP Tools and Services: Identify and integrate IDEP tools and services that enhance the developer experience. This may include code review tools, automated testing frameworks, continuous integration and deployment platforms, documentation and knowledge sharing platforms, collaboration tools, and developer productivity tools.

  7. Self-Service and Onboarding: Enable self-service capabilities for developers to provision and manage their development environments. Implement onboarding processes and documentation to help new developers quickly get up to speed with the IDEP tools and practices. Provide training and support resources to ensure smooth adoption.

  8. Continuous Improvement and Feedback Loops: Establish mechanisms for continuous improvement and feedback loops. Regularly collect feedback from developers to identify pain points, bottlenecks, and areas for improvement within the IDEP. Use this feedback to refine processes, update tooling, and enhance the overall developer experience.

  9. Documentation and Knowledge Sharing: Emphasize documentation and knowledge sharing within the IDEP. Encourage developers to document best practices, lessons learned, and troubleshooting guides. Implement a knowledge sharing platform or a wiki to centralize information and promote collaboration among developers.

  10. Measure and Track Developer Experience: Implement metrics and tracking mechanisms to measure the effectiveness of the IDEP. Monitor developer productivity, satisfaction, onboarding time, and feedback to assess the impact of the IDEP implementation. Use these insights to drive further improvements and enhancements.

By following this golden path, organizations can transition from shift-left development to an IDEP that provides a seamless and productive development experience. The IDEP focuses on standardizing and streamlining development practices, fostering collaboration, and enabling developers to focus on writing high-quality code. This ultimately leads to improved software delivery, increased developer satisfaction, and accelerated innovation.

 

May 24th, 2023 version of ChatGPT used to generate the Session material.

Previous
Previous

applying the choice rules rule

Next
Next

Thought exercising