Eddy Pauwels SVP Sales & Marketing December 27, 2017 - 4 mins read Comparing Delivery Automation Systems (4/4) To conclude this blog series, let me share some criteria to evaluate different automation solution in the application delivery context. These criteria can help you in the selection process for a good delivery automation solution. Logic Layering How is the automation logic layered out? Coupling Are the flow components tightly or loosely coupled? Runs Backwards If rolling back changes are needed, is a reverse flow natural or awkward? Reusable Components Can components and parts of the logic be easily reused or plug-and-played from one process to the next? Entry Barrier How hard is it to translate the real world into the underlying technology? Easy to Implement How hard is it to adapt to new applications and processes? What about maintenance? Environment and Logic Separation How independent is the logic from the environment? Model Transition Can it handle the evolution from one model to the other? Massive Parallel Execution Does the paradigm allow for splitting the automated execution into correlated parts that can run in parallel and results be joined later? Generates Model as a Result Does the automation know what is being changed and store the result configuration back into the database? Handles Model Transitions Can the system assist in evolving from one environment configuration to another? Testable and Provable Can the automation be validated, measured and tested using a dry-run environment and be proven correct? Criteria Process-Driven Model-Driven Rule-Driven Logic Layering Flowchart Model, Flowchart Decision Trees Coupling Tight Loose Decoupled Easy to Debug ✓ Runs Backwards (Rollback mode) ✓ Understands the underlying environment ✓ ✓ Understands component dependencies ✓ ✓ Reusable Components ✓ ✓ Entry Barrier Medium High Low Easy to Migrate ✪✪✪ ✪ ✪✪✪✪ Easy to Maintain ✪ ✪✪✪ ✪✪✪✪ Environment and Logic separation ✓ ✓ Requires Environment Blueprints ✓ Handles Model Transitions ✓ Massive Parallel Execution (parallel by branching only) (limited by model components) ✓ Performance ✪ ✪✪✪ ✪✪✪✪✪ Final notes When automating complex application delivery processes, large organizations need to choose a system that is both powerful and maintainable. Once complexity is introduced, ARA systems often become cumbersome to maintain, slow to evolve and practically impossible to migrate out. Process enterprise systems excel at automating business processes (as in BPM tools), because they do not inherently understand the underlying environment. But in application delivery and release automation in general, understanding the environment is key for component reuse and dependency management. Processs are difficult to adapt and break frequently. Model-driven systems have a higher implementation ramp-up time since they require blueprinting of the environment before starting. Blueprinting the environment means also duplicating container metadata and other configuration management and software-defined infrastructure tools. The actions executed in model-based systems are not transparent, tend to be fragmented and require outside scripting. Finally, many release automation steps simply cannot be modeled that easy. Rule-driven systems have a low entry barrier and are simple to maintain and extend. Automation steps are decoupled and consistent, testable and reusable. Rules can run massively in parallel, scaling well to demanding delivery pipelines. The rule-action logic is also the basis of machine-learning and many of the AI practices permeating IT nowadays. In short, here are the key takeaways when deciding what would be the best approach to automating the delivery of application and service changes: PROCESS MODEL RULE ✓ Easy to introduce ✓ Easy to model ✓ Simple to get started ✓ Hard to change ✓ Complex to orchestrate ✓ Highly reusable ✓ Not environment-aware ✓ High entry barrier ✓ Decoupled, easy to change and replace ✓ Error prone ✓ Duplication of blueprints ✓ Massively scalable ✓ Complex to navigate and grasp ✓ Leads to fragmented logic and scripting ✓ Models the environment as a result ✓ Not everything can or needs to be modeled ✓ Fits many use cases Rule-driven automation is therefore highly recommended for implementing application and service delivery, environment provisioning and orchestration of tools and processes in continuous delivery pipelines. In fact, a whole new generation of tools in many domains now relies on rule-driven automation, such as: – Run-book automation – Auto-remediation – Incident management – Data-driven marketing automation – Cloud orchestration – Manufacturing automation and IoT orchestration – And many more… Release management encompasses a complex set of steps, activities, integrations and conditionals. So which paradigm should drive release management? Processs can become potentially unmanageable and detached from the environment. Models are too tied to the environment and end up requiring scripting to be able to deliver changes in the correct order. Only rule-driven systems can deliver quick wins that perform to scale and are easy to adapt to fast-changing environments. Get an early start and try Clarive now. Install your 30-day trial here. Share this:Click to print (Opens in new window)Click to share on LinkedIn (Opens in new window)Click to share on Twitter (Opens in new window)Click to share on Google+ (Opens in new window)Click to share on Facebook (Opens in new window)