⚙    bpm    sdlc    bianl    data    meta    math    ⚙ 👐 🎭 index - references    elucidation    metier 🎭
👐    Intro    Defining Tasks    101 deploy    tools deploy    Release Train    Results evaluate    👐    top bottom   👐

relmg DEVOPS = Value stream, removing constraints


Release mangement, Versions of business logic

Making work of ICT colleagues easier.

Software development full circle Testautomation in the releasetrain Details testautomation in the releasetrain Details releasetrain Details Data information security Details dataflow Looking and analyzing what the colleagues are doing, improvements and corrections getting planned (PDCA).

SIAR
S Situation
I Initiatives
A Actions
R Realisations

🔰 lost here, than.. devops sdlc

Progress


Contents

Reference Topic Squad
Intro Making work of ICT colleagues easier. 01.01
Defining Tasks Defining tasks at an Organisation. 02.01
101 deploy Deployments in the beginning. 03.01
tools deploy Deployment subordinated to versions tools. 04.01
Release Train Release Train, goal optimised & automated. 05.01
Results evaluate Evaluating results - impact value. 06.00
Words of thank to my former colleagues 06.02


sea log

Defining tasks at an Organisation.


The interests at departments are different. At the high level a classification in Business, Information management and ICT is usually made. Technical nerds are having many times big challenges to communicate with business persons.

Tasks and team names
Names for task using teams departments and roles is confusing.
native group nl
I am used to the old names for tasks, the ever lasting reoganisation and management consultants are continously changing the names, not the tasks.
I will use names similar to those of the long period mentioned in my JST history.
ICT build test run the business
🎭 SYSSUP-OS (Operating System) support. ICT infrastructure
🎭 SYSSUP-MW Middelware support tools, dbms, packages. ICT infrastrcuture
🎭 OPS-OP Running Operations ICT
🎭 DEV-DBA Support usinge DBMS resources ICT
🎭 DEV-BLD technical-functional ICT/BU Building business applications
🎭 DEV-PTG technical-functional ICT/BU Support test business applications

IM, in between ICT and Business
Tasks that are technical but at the same time requiring a lot of how the business is working, is a position under many discussions.
🎭 DA-DP metadata & security - ICT support business
🎭 OPS-PB Support Operations planning scheduling - ICT interacting to Business
🎭 OPS-OA Office Automation - technical-functional ICT/BU Support
🎭 OPS-DE Data entry, converting hard copy information into computer readable
🎭 IM-SDA Business Analysts - functional technical BU/ICT support
🎭 IM-DSK Service Desk: first line for users questions and Support
🎭 IM-OA Office support - provision of artefacts at the office

Business lines, fiancial and sales, marketing
The business is speaking an other language than what is used in the ICT world. native group chmk
Don´t get surprised that:
🎭 BuF(x) Functional - Business representation
    Multiple tenancy represtations by business lines
🎭 FCR(x) Finance Business - Marketing, sales, customer relations.
🎭 FAC(x) Finance Business - Accountancy risk, compliancy
🎭 FBK(x) Finance Business - bookkeeping, internal cost accounting.


green logl

Deployments in the beginning.


The questions to solve release managment using software arose when programs were getting stored at DASD not using anymore the physical hollerith punch cards. This was the mainframe dominated era, soon to extended wiht pc´s.

Mainframe, beginning release management
There were several approaches in use, not a single one covering everything. Those were: The line for running batch jobs covered by OPS-PB (see JST) and the OLTP tools build and implemented by DEV-DBA.
The good thing in this is a clear segregation of responsibilities, duties and sepearated storage area´s.

The two lines of in house business applications (DEV-BLD) made it impossible to find any commercial tool cover everything.
😉 ❌ Reviewed tool (Panvalet) got rejected for having too little additional value.
Computer Associates Panvalet (also known as CA-Panvalet) is a revision control and source code management system for mainframe computers such as the IBM System z and IBM System/370 running the z/OS and z/VSE operating systems. Unlike open-source solutions such as CVS, SVN or Mercurial, Panvalet is a closed source, proprietary system for versioning and control of source code such as Microsoft Visual SourceSafe on personal computers. (wikipedia)

ISS Indivdual Sales Support & OPP
This was a project based on having the administration of sales persons having a decentralised copy and synchronizing the inforamtion to the central system.
Build with: This was very advanced at that moment, everything was buil in house. No commercial tools were available.
The question was how to solve the release management for the build PC software.

A developer DEV-BLD got the assignment to build that (OPP). Still similar these days with the latest tools, the requirements did not change.
Functionality: Situation and limitation: using the same technology as ISS. After a long time building the result was shown. Reviewing it for stabilty and functionality, usability.
😉 ❌ It was not accepted. Too little and adding a lot of work that could done more easy. The Local area network became available.


modern5 logl

Deployment subordinated to versions tools.


Getting tooling off the shelf for trying to solve the release management questions is getting track. A lot of other options are also done, it is what some person is able to get through as being important.

Dedicated machines for each development stage (pc)
The question of the same user account on the same machine for Develop Test Production, got the architectured decision that: I started to get implemented and than the management was seeing the impact. Doubling the needed hardware, power and network connections. All with no real value.
😉 ❌ It was halted and reverted back to use a single hardware box.

Defining time periods for the same system for Acceptance-test and Production
Not having the budget for a lot of hardware the acceptance testing was planned every Friday morning using the production machine. All data entered at that morning got deleted after that. The production data from the morning restore at noon.
That is a very limited way of doing acceptance testing, no predictable regression tests, no time travelling and a high risk of getting test-cases in production.
😉 ❌ The risk management and audting review cancelled this.

Endevor, the last mainframe only tool
Endevor is a source code management and release management tool for mainframe computers running z/OS. It is part of a family of administration tools by CA Technologies (formerly Computer Associates), which is used to maintain software applications and track their versions.[2] The word ENDEVOR is an acronym which originally stood for Environment for Developers and Operations but is now the formal product name for CA's flagship mainframe Application Lifecycle Management source control product. It also competes against another CA source code management tool, Panvalet. (wikipedia)
The tool entered the organisation just before 2000 as a result of a merge with another company. It needed to build up from scratch on the systems already there.
🤔 ❓ It was implemented four times. The first attempt failed. The next one made a workable situation and forced JST to roll out to more departments. The third was rebuilding it again because of ohter IT standards and than again because of an iT change split by reorganisations.

Dedicated machines for each development stage (DEV-BLD servers)
From the DEV-BLD perspective two Host machines (mainframes) are setup. One for the operations production usage and the other for development and testing. For ease of accessing the data the storage was shared and both systems were seeing the same data. The isolation by hardware machines in fact undone.
😉 ❌ The shared dasd approach was not accepatable, risk management audting review cancelled this. Not able to follow technical changes using distributed approaches it got outdated.

Dedicated machines verifying OS & tools, middelware (SYSSUP-OS servers)
From the SYSSUP-OS perspective updates are possible while the system is running. The consequence is not knowing certain whether the system will still work when restarted. Solution: restarting the systems at agreed planned moments using different system boot definitions (fall back).
😲 ✅ This approach gave a very reliable system behaviour. Changes in error done past two weeks detected early. As invisible the known advantages got lost.

From the SYSSUP-MW perspective multipe versions within the same system are possible. The consequence is having the options to do regression testing for the business applications using existing test facilities.
😲 ✅ This approach gave a very reliable system behaviour. Even system messages changes are easily detected. As invisible the known advantages got lost.


modern7 logl

Release Train, goal optimised & automated.


When pc´s became common to operate by users for some reason the assumption is made this is also the preferred development and test environment although the real production target environment is server based.

Desktop stacks and tools
The desktop service got outsourced but the instructions for repackaging middleware and tools on the desktop kept an internal responsiblity. The validation of how it works after delivery also an internal responsibility.
I did already a lot with SAS previous years. Integrating it wiht mainframe and Windows for Marketing and accountancy aside technical monitoring. Now a got involved to do this at a bigger scale.

Stacks on a pc are easily leading to conflicts using tools of different suppliers. Analysing, removing constraints where possible, got me into some new conflicts. 🤔 ✅ It worked technical very well. For how to do cooperation:
    working toghether several parties for a common goal, it was not that good .

Hosting, multi tenancy & release management
Aside pc´s and mainframe other servers (Unix) running SAS services were in use.
All installations and how they were being used, different. Starting to consolidate all of them to less machines doing multi tenancy at the business usage when the type of usage would allow that. Defining a toolset for the maintenance of adding removing business applications and business users consolidates to a limited number of machines.
🤔 ✅ It worked technical very well. For how to do cooperation:
    working together several parties for a common goal, it was not that good .

Some day a colleague came in. He told that using PVCS as tool for storing versions of business logic was wanted. I explained how the business coding worked with source code in catalogs and (meta) databases. Having all segregations in place. (ca 2010)
😉 ❌ Using PVCS storing code artefacts not a fit in requirements & options.

Operations outside ICT
Some stories and experiences are a repeating one. In a big enviorment helping with selfservice anlsytics using IDE (integrated Development Environment). It is outside any normal ICT supported operations.
The situation for having regular processes run was that some person did that manually and using the laptop time schedule options. For a more regular process did what should be normal using limited options.
Some day a collegue came. He told that using Git as tool for storing versions of business logic was wanted. I explained how the tools are working and just got a not understanding response.
😉 ❌ Using Git storing code artefacts not a fit in requirements & options.

DEVOPS in a small setting using ML
In a smaller environment first doing a solution for fall back wit machines. The business ML application reordered in code removing dependencies. The goal more easy maintenance by an logical object oriented ordering of components.
🤔 ✅ REleases doing manual with addtional instructions worked very well.
    Question using Git. Was prepared although only it will be archiving function only.

Business Intelligence outside ICT
All procedures for the release train have been build during many years conforming the instrcutions of the supplier. A list of issues: 😲 ❌ Using home build pocedures is not guaranteed succesfull.

DEVOPS in a small setting, doing private metadata
A very small team needing doing evruthing with a limited number of programs ( .. < 50, ca 2020).
🤔 ✅ Releases doing manual and additional instructions was the intended way.


Small - Big

Evaluating results - impact value


Removing bottlenecks, continous flows
Integrations of object, deployment of business applications, how to align with compliancy rules at the business perspective? That is a topic that is complicated situation.
The complicated domain consists of the "known unknowns". The relationship between cause and effect requires analysis or expertise; there are a range of right answers. The framework recommends "senseľanalyzeľrespond": assess the facts, analyze, and apply the appropriate good operating practice. (wikipedia)

Handy tool
It seems that it is handled as a disordered one. The common reaction is: put a tool in place , hoping the release management question will be solved by having a tool implemented.
Evaluate cases with their failures and those that had some success. A retrospective has the intention to learn from experiences. What went wrong, what good, what did we learn.

A logical framework for release management (versioning)
What is missing is a framework for release management used with localisation for the specific situation in an organisation. Some generic requirements: In a figure:
releasemanagement tools technique
Details on what is needed more depends on the used technology.
The Develop and Test (integration / system), should look as similar as possible conform the intended production situation.
💡 Any authorisation model (security) made effective at T conform P.

Questions on how to make the development life cycle lean is removing constraints.
💡 Proposed steps in responding:
Words of thank to the ones that helped me in this.
I will put in names only for those that allow me to do:
Release management a disappointing activity all those years
Software development full circle Data information security Details testautomation in the releasetrain Details releasetrain Details Data information security Details dataflow Looking and analyzing what the colleagues are doing, improvements and corrections getting planned (PDCA).

SIAR
S Situation
I Initiatives
A Actions
R Realisations

🔰 lost here, than.. devops sdlc


👐    Intro    Defining Tasks    101 deploy    tools deploy    Release Train    Results evaluate    👐    top bottom   👐
⚙    bpm    sdlc    bianl    data    meta    math    ⚙ 👐 🎭 index - references    elucidation    metier 🎭

© 2012,2020 J.A.Karman