CA Endevor is a leading Application lifecycle Management (ALM) in IBM mainframe land. However, today’s companies do not just use mainframes anymore for their application development: the development happens on distributed systems and the deployment can be done on mainframe, on distributed systems or on a mix of both.
As CA Endevor only runs on mainframes, customers confronted with a heterogeneous environment have to look for an alternative solution for integrated ALM solutions.
The IKAN supplied IKAN ALM solution is the perfect match for CA Endevor. Customers can continue to use CA Endevor for the mainframe and use IKAN ALM for non-mainframe platforms, or they can use a combination of CA Endevor and IKAN ALM when mixed environments are used for development and/or production. Both IKAN ALM and CA Endevor are process-driven and both products have comparable features.
IKAN has worked out an IKAN ALM to CA Endevor integration strategy ensuring:
- True multi-platform build (compile) and deploy capabilities.
- The addition of deployment capabilities to CA Endevor
- The addition of rollback capabilities to CA Endevor
- The addition of hierarchical Approval Groups
- Deployments using the “Alternate UserID”
- Improved z/OS UNIX support
- The automation process of PC development to Mainframe build(compile)/deployment
This document briefly explains how CA Endevor and IKAN ALM work, how both products complement each other and how they can work together to offer integrated enterprise-wide Application lifecycle Management.
CA Endevor is a software product that only runs on a z/OS mainframe. It offers Version Management, Process Management, Configuration Management and limited Distribution Management functionalities. CA Endevor gives the possibility to set up a (unlimited) lifecycle customized to the customer’s needs and providing support for both regular and parallel development or maintenance activities. Such a lifecycle is set up as a series of consecutive stages.
In the entry stage, a Software Component (source) is added to CA Endevor. When adding that source, the system takes care of processing the source (usually a compile/linkedit (build) process). After having been tested, the Software Component(s) will be moved up in the lifecycle and will ultimately pass on to Production. Usually, moving Software Component(s) is not done by recompiling the components, but by just copying them to the next stage in the lifecycle.
Before moving a Software Component (or a collection of components) up to the next stage in the lifecycle, an approval process can be enforced.
Within CA Endevor the applications are grouped in so-called Systems and Sub-systems. The application components are connected to a Type determining the process to be run when a user takes an action on an application component (actions like Add, Update, Move, Delete, ...).
IKAN ALM offers a secure yet flexible process centric software change management solution for both local and distributed development teams, and manages and automates SOA, Agile and traditional development processes. It complements existing version management tools by automating the complete software lifecycle management process, offering a single point of control and delivering support the build, deploy, release and software lifecycle management and the associated authentication and approval processes.
IKAN ALM triggers a manual or automatic build (or both) depending on the way the system is set up. After having been tested, the Software Component(s) will be delivered to the next stage in the lifecycle and ultimately to Production. Delivering Software Component(s) prevents rebuilding the components again. Every delivery to the next stage in the lifecycle delivers the Software Components to every machine that is connected to the stage in the lifecycle. Every stage in the lifecycle is connected to one or more build and/or deploy environments.
Before delivering a project to the next stage in the lifecycle, IKAN ALM allows to enforce Approvals before delivering the component(s) to the next stage.
Here also, the application components have certain extensions (type) determining the process that needs to run when a project is delivered.
IKAN ALM vs. CA Endevor Terminology
The following table maps the terms used by IKAN ALM and CA Endevor and provides a brief comment for each of them. This will help the respective users of IKAN ALM or CA Endevor to have a better understanding of the terminology used by the other software.
|Project||System and/or Subsystem||The defined project within IKAN ALM will need attributes to tell IKAN ALM into which Endevor System/Subsystem the Software Items should be added|
|Life Cycle||Map||This defines the route from Development to Production|
|Level||Stage||This defines every step on the route from Development to Production|
|Environment||NA||IKAN ALM is using the (logical) Level concept in which (Build/Deploy) Environments can be defined. Every Environment represents a Machine (server/OS) in the network. This is a concept not known to Endevor, this is a unique IKAN ALM architectural feature and represents the true multi-platform aspect of IKAN ALM|
|Extention||Type||The extention/type determines the processing needed for a certain type.|
|NA||Processor group||The processor group in Endevor determines the ultimate process to run within a certain type. E.g. Type Cobol might have processor groups for Cics, Batch, Ims etc. IKAN ALM comes with a set of processors that are able to determine this kind of requirements and will set them accordingly. This will require on-site modification to meet customer demands|
|Level request||(Move) Action||A level request in IKAN ALM allows for Build, Deploy and Rollback. Endevor knows more actions, but they are not applicable to IKAN ALM. E.g. if someone likes to delete a component from the Production environment, one should delete the components from the VCR, the project should be built and deployed, and tested in all the Levels between Development and Production, ensuring that this deletion does not jeopardize the Production.|
|Build request||(Add) Action||The Build (level) request in IKAN ALM will usually take care of populating Endevor with the Software Components (ADD action)|
|(Ant) script||Processor||Runs the process (e.g. for compilation)|
|Idrdata/Build#||Footprint||IKAN ALM is generating a unique build number that can be used in several processes to identify the output from (compile) procedures. IKAN ALM is also able to set this information on members in a Pds.|
|Approval||Approval||Endevor allows to define several Approval Groups which are in the same hierarchy. Every group may approve on any moment. IKAN ALM allows to setup a hierarchy in the Approval Groups. E.g. Group2 may only approve if Group1 has approved before.|
|Rollback||Backout||Endevor allows to reverse the output from a promotion/delivery if it is a member(s) in a Pds. In the case of Db2 a (manual) rebind should be executed. With IKAN ALM an automatic rollback script can be executed for every kind of output, which will allow the customer to automate a rollback operation.|
|Machine||Ship||A machine runs a IKAN ALM agent which will take care of binding/deploying the software components. Endevor supports only other z/OS Lpars where IKAN ALM supports all platforms, including z/OS, Uss, Unix (flavors) and Windows|
|ReleaseNumber/IncidentNumber||Ccid||The release/incident number within IKAN ALM may be passed to Endevor as the Ccid (Change Control id)|
Integrating IKAN ALM with CA Endevor
IKAN has worked out the integration between IKAN ALM and CA Endevor. The concept is based on the three following starting points:
- IKAN ALM is leading: sources are controlled by IKAN ALM (VCRs).
They are pushed into CA Endevor and will not be retrieved from CA Endevor for modification. At all times, modifications should be done at one and the same VCR level.
- The Approval mechanism is moved from CA Endevor to IKAN ALM for the project.
This means that the Approval Group in CA Endevor will be defined with quorum size equal to 1 with the IKAN ALM system user as “always required”.
- In the entry stage of CA Endevor, IKAN ALM will generate ADD/UPDATE actions for all Software Components that should be handled by CA Endevor.
This means that an attribute should be defined for the corresponding IKAN ALM Environment telling IKAN ALM to ADD the sources into CA Endevor. IKAN ALM will monitor those actions and if one of them fails, that Build/Delivery request for IKAN ALM will fail and the Delivery to the next Level will not be possible. After correcting the Build error, a new Build/Delivery request will execute the ADD action again.
When delivering to the next Level, IKAN ALM will create CA Endevor Move actions to be stored in a package, cast the package, approve the package and execute the package. If the Delivery fails (in CA Endevor or on another platform), the new Delivery will automatically check the status of the CA Endevor package and if the status is “Failed” it will restart the package execution. If the status equals “Executed” or “Committed”, the package will not be processed.
|Package status||IKAN ALM action|
|None (new package)||
|Committed and Rollback needed||
Example of a Lifecycle
The following figure shows a possible lifecycle. In IKAN ALM as well as in CA Endevor users can set up customized lifecycles.
A combined use of IKAN ALM and CA Endevor allows current CA Endevor users to extend the CA Endevor mainframe services to all possible other platforms used for development, testing and production.
This solution preserves the current mainframe investment in the Application lifecycle Management process by adding the IKAN ALM component to obtain enterprise-wide, multi-platform Application lifecycle Management.
For more information
If you need additional information or would like to request a demo, please contact us.
The CA product names referenced herein are either registered trademarks or trademarks of CA, Inc. or one of its subsidiaries. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.