Due to work commitments and “normal life” (whatever that means to an Endevor administrator!), “in-approval” has run its course in terms of off-the-shelf topics, tips, and techniques that I had documented over the years. From this point forward, “in-approval” will contain articles that occur to me over time as I actively work at helping sites attain better implementations.
In this final blog in the regularly-scheduled series, I want to reflect on the state of Endevor and life-cycle management as a discipline and as it seems to have evolved based on my experience over the past 30+ years.
One of the “hot” trends in application development is the rise of “Agile” methodologies. As a project management professional, it has been interesting to see the “snobbish” attitude that strict adherents to the principles of agile have over traditional waterfall methods. As an IT professional who cut his teeth doing application development for many years before engaging as an Endevor administrator/SCLM manager, I actually intimately understand the frustrations developers had with waterfall and the theoretical “freedom” and ability to react to perceived end-user needs that is more inherent in agile.
There have been those, however, that criticize Endevor as being “more for waterfall than for agile”. I would counter argue, however, that that argument reflects a poor understanding of both methodologies and is actually an argument for another look at “what” a site is doing with Endevor versus “how” they are doing it; a classic need to re-examine real objectives rather than perceived subjectives.
At the end of the day, neither method changes the reality of a developers day-to-day activity; the need to rapidly code-compile-test-repeat. Neither method changes the reality of, once the developer has created something successful, moving to a state where code-compile-test-repeat begins again with other coders bringing forward their contributions. And then moving forward again until a sprint (or phase) is ready for release.
In the distributed world, this is often achieved by moving to different machines that represent different states. In the Endevor world, welcome to environments and stages.
Agile or Waterfall; they both still need life-cycle-management.
I think the difference is that, with Endevor, many of us have gotten too tied up in the naming and “strict” usage of environments and stages. Too often, we have gotten tied up with projects or testing managers in trying to “automate” the population of the CICS region or IMS region or DB2 catalog at a specific stage because “that’s the name of that stage”.
Times when an environment or stage in Endevor begins to deviate from a one-to-one relationship, especially for a specific system (today it wants to go here, tomorrow it wants to go there, and the next day it wants to go somewhere else), I would advocate it’s time to engage with a different definition of what your SCLM process is trying to do and approach the populating of operational libraries using something other than processors or processor groups.
Years ago, I began advocating having your stages represent states of being. In other words, if there is a one-to-one stage-to-testing-environment ratio, or even if the ratio is one-to-some, then let Endevor “automatically” populate those environments.
But if your testing, QA, or development centres are creating a vast and/or complex array of catalogs and regions that they want Endevor to populate, I believe it’s time to step back and call a reality check. I advocate falling back to a position of representation; the stages in Endevor provide libraries that Endevor can ensure represents a “state of being”. In other words, as Endevor administrator, you can assure people that elements at Stage X are created with the complete technical integrity that Endevor brings to bear. WHERE they want to test those elements has now become the responsibility of testing, QA, or the development centre.
And at this point, I think Package Shipment has FAR more to play than has been universally adopted so far. In essence, Package Shipment (remote AND local) has much to deliver in replicating the distributed worlds current model of installing development software for testing on different machines. In essence, Package Shipment has always been there to deliver the same functionality…. so let’s use it!
An imaginative leverage of Package Shipment would allow the developer to ship/deliver/install the same elements to as many different regions as may be defined. All the Endevor administrator needs to do is define the libraries and define some post-install scripts. This keeps Endevor “cleaner” and easier to administrate while at the same time delivering the ability to provide technical excellence across the enterprise.
This approach also keeps the promise of being development method agnostic; it doesn’t matter whether you got to the Endevor stage using “agile” or “waterfall”. What mattered is that the element created with integrity in Endevor is made available to whatever targets the developer has need to exercise their test or QA cycle in.
So with these final thoughts, “in-approval” has now been “executed”, a new “in-approval” package of comments and articles is on the horizon!
I want to thank you for reading these musings over the past months; it’s been my privilege to correspond with some of you and I consider it an honour to work with some of the finest minds in the SCLM discipline.
John Dueckman
"in-approval" 