The Smile-IT Blog » Blog Archives

Tag Archives: scripting

Dynamic Processing Control of Automation Flows

This post is part of the "Automation-Orchestration" architecture series. Posts of this series together comprise a whitepaper on Automation and Orchestration for Innovative IT-aaS Architectures.

 

The final compelling element to consider in an enterprise-grade automation solution is its ability to dynamically control – in real-time – how automation changes the behaviour of your IT landscape. This includes:

  • On-demand business process changes requested by stakeholders, mandated by regulatory requirements, or directly affected by events outside of the enterprise’s core business model
  • Risk of service level (SLA) penalties caused by an application failure or the system’s inability to handle a change of load demand
  • The ability of the system to support a rapid introduction of a new product line or service to meet changing business needs

When assessing such capabilities, the following architecture patterns within the proposed automation solution are of importance:

Dynamic just-in-time execution

As described earlier, object orientation forms the basis for aggregating artefacts built into the automation solution (such as: actions, tasks, workflows, file processing, reports). This capability shall be provided in a way that automation operations remain sufficiently granular and at the same time allow the solution to act as a large automation ecosystem. More importantly, the solution must retain the ability to dynamically re-aggregate executions on-demand as required.

If the automation platform handles each artifact as an object, then object interaction, object instantiation parameters, or object execution scheduling can be redefined in a matter of minutes. All that’s left is to define the object model of the actual automation implementation for the specific IT landscape – a one time task.

The best automation solutions include a library of IT process automation actions that can be aggregated throughout automation workflows. These “IT process automation” actions are ideally delivered as part of the solution as a whole or specifically targeted to address particular automation challenges within enterprise IT landscapes.

Examples are:

  • If IT SLA measures reveal a particular IT housekeeping task at risk due to an increase in processing time, dynamic adaptation of the specific workflows would involve assigning a different scheduler object or calendar to the task or re-aggregating the workflow to execute the process in smaller chunks. This assumes end-to-end object orientation and proper object model definition.
  • If a particular monthly batch data processing workflow is exceeding a particular transfer size boundary, the workflow can remain completely unchanged while chunk size definition is altered by changing the input parameters. These input parameters would themselves be derived from IT configuration management so dynamic automation adaptation would still remain zero-interactive.

Pre/post processing of automation tasks

Not only does dynamic execution require maximum object orientation patterns within the implementation and operation of the automation solution, but it must also provide the ability to:

  • Change the behavior of an object by preprocessing actions.
  • Process the output of an object for further use in subsequent automation tasks/workflows.

Adding pre or post execution logic instead of implementing additional objects for the same logic makes it an object property – an inherent part of the object itself instead of treating it as separate object within the model – which rarely occurs with pre or post-processing. These tasks thus become part of the concrete instance of an abstract automation object.

Examples for applying this pattern in automation are:

  • System alive or connectivity check
  • Data validation
  • Parameter augmentation through additional input
  • Data source query
  • Dynamic report augmentation

Automation solutions can offer this capability either through graphical modelling of pre and post conditions or in the case of more complex requirements, through script language elements.

Easy-to-use extensible scripting

The scripting language offered by the automation solution is the key to offering a system capable of implementing enterprise-grade automation scenarios. While scripting within automation and orchestration tends to evolve into supporting mainly standard scripting languages such as Python, Perl, JavaScript or VBscript, a solution that offers both standard and proprietary scripting is still optimum.

An automation system’s proprietary scripting language addresses the system’s own object model most efficiently while at the same time – through extension capabilities – enabling seamless inclusion of target system specific operations. The combination of both is the best way to ensure a flexible, dynamic, and high performing end-to-end automation solution.

 

Published by:

Homogeneous end-to-end Automation Integration

This post is part of the "Automation-Orchestration" architecture series. Posts of this series together comprise a whitepaper on Automation and Orchestration for Innovative IT-aaS Architectures.

 

Whether looking to extend existing IT service capabilities through innovative service orchestration and delivery, or trying to increase the level of automation within the environment, one would always want to examine the following core features of a prospective automation solution:

  • Automation
  • Orchestration
  • Provisioning
  • Service definition and catalogue
  • Onboarding and subscription
  • Monitoring and metering
  • Reporting and billing

Though not all of those might be utilized at once, the automation solution will definitely play a major role in aggregating them to support the business processes of an entire enterprise.

Either way, homogeneity represents a key element, when it comes to determining the right solution, with the right approach and the right capabilities.

Homogeneous UX for all integrations

First, the automation platform one choses must have a unified user experience (UX) for all targeted applications. This doesn’t mean that for every component in the system the exact same user interface needs to be presented. It’s more important that there is a unified pattern for all the components. This should start with the central management elements of the solution and extend to both internal and external resources such as an Automation Framework IDE for 3rd party solutions discussed previously.

In addition, the core automation components also must match the same UX. Introducing an automation system with standard user interfaces and integration concepts ensures rapid implementation, since SME’s can focus on automating system processes rather than being bogged down with training on the automation solution itself.

A single platform for all automation

The more products that make up the automation solution, the greater the effort required to integrate them all into an IT landscape. Software and system architecture throughout history has never proposed one single technology, standard or design guideline for all functional capabilities, non-functional requirements, or interface definitions. Therefore, a bundled system comprised of multiple products will in 95% of cases come with a variety of inter-component interfaces that will need to be configured separately from the centralized parameterization of the overall solution.

Project implementation experience shows that the slope of learning associated with the solution is directly proportional to the number of different components contained in the automation suite. (see figure below):

Automation adoption time

Automation: Adoption time by number of platform components

Functional integration with target systems

Finally, the solution’s core functionality should be able to integrate with target systems using industry standards such as common OS scripting languages, REST, JMS or quasi-standards with target applications like RPC and EJB. At minimum, the solution should include 90% of these industry standards out-of-the-box.

In addition, an enterprise-grade automation solution should provide:

  • Multiple action/workflow templates (either bundled with the core solution or available for purchase)
  • Ease of integration implementation with target systems’ core functionality at a very detailed level – such as administrative scripting control from within the automation core through scripting integration (to be discussed in the following chapter)

 

Published by:
%d bloggers like this: