Meet Abigail and Simon
ijmitch 120000JGMF Visits (1468)
Some of you will have seen me present this picture as part of how I explain our objectives for the new Application and Platform capabilities being created in Version 5 of CICS TS. These two concepts are major foundations for our move to enable to faster and simpler deployments - as valuable outcomes in the strategic Cloud initiative.
I typically start by explaining that this is definitely a vision of the future - we're at the start of a journey to a time when this sort of scenario may be business-as-usual, but it we don't start now then we definitely won't arrive. It feels to me that we're at a similar point with our Cloud initiative as we were with SOA in 2005 when version 3.1 was launched. At conferences and briefings around that time, I knew that there was definitely a set of folks who already had the business and technical motivations to adopt our SOAP/WSDL (and later, RESTful) capabilities - but also a set of folks who would look at me somewhat sceptically and scratch their heads... "What's he on about? Do I want to do this?"
Anyway, let's meet Abigail and Simon...
Abigail is an application developer, and has been working on an enhancement to the code implementing the payroll system. Since the modules and resources which make up the payroll system have been made into an Application, it is easy for Abigail to think about her enhancements as a new version of the Application. Indeed everyone who interacts with the Application can easily see what version they are dealing with, all the way from the development environment, through test and into production. By making the modules and resources of the payroll system into an Application, everyone can clearly see its scope and boundaries, and deal with it as a coherent entity.
During this activity, Abigail will obviously need to a system to use to test out her changes. So she checks with her 'Platform Provider' whose name is Simon what her best option for that is. Relating to today's world Simon is a System Programmer, but I'm going to use the term Platform Provider for this future role.
(Now here's something which might be scary/radical... an application developer and a system programmer talking on regular basis, but hey... they're human too!)
Simon is able to quickly help Abigail get the resources she needs. But instead of pointing her to a CICS system that he thinks has been kept around running just in case someone from the Payroll department wants to use it, Simon can point Abigail to the specific Platform created for just such testing. This Platform is a first-class managed resource under all the change control governance that the business requires (some people are talking about such things as 'Sof
Creating a Platform for Payroll testing means that the resources can be provisioned confidently in a very repeatable way - so there is no need to keep the Platform permanently deployed. It may be months between time when a project needs the system to be available for use. But Simon is able to quickly tell Abigail were to find the Platform she needs.
In this new world, Abigail is used to deploying Applications quickly and simply on to Platforms, so having checked with Simon which Platform to use, she is ready to go ahead and start testing later that day. She doesn't need to understand the details of the Platform, but is pleased that the resources she needs (probably the same as she used a couple of months ago for a previous piece of work on the Payroll system) can be in place when she needs them.
I guess that once the Platform is defined and becomes an easily repeatable thing to provision and deploy on the development plex, it won't really matter who goes to the repository and brings up the payroll test Platform - it could equally be Abigail or Simon.
But there's another new concept that is important to this scenario - Simon reminds Abigail that to ensure the payroll system 'behaves itself' there are a set of Policies to which it must comply and will be checked at runtime. This is good for both Simon and Abigail in their respective roles. Simon gains confidence that even if the changes Abigail is making in her new version mean more resources are consumed, this won't compromise the overall system. Abigail will receive very prompt feedback in the development environment if her changes do contravene the policy, or risk causing problems went they are moved to the Production environment.
In this scenario the job of defining and governing acceptable resource consumption is delegated to another member of the team - Oliver is able to define Policies for development, test and production platforms. The company has decided that it's important to be very strict about excessive resource consumption so Oliver specifies that abends should be the outcome of a threshold breach in the test environment - this is an aggressive pursuit of 'no violations' in the formal test phase of a project. But it is recognised that in other phases of the application lifecycle such aggressive action would be inappropriate - during development testing, the policy is to inform developers via messages but allow the code to execute to completion nonetheless giving the developer a chance to fix the problem. In production, if a path through the application which uses more than a policy threshold allows escapes from the test phase, it's too much of an impact on the end-user customer's experience to abend the transaction, so a system event is used to capture the fact that this has happened and interface with the defect tracking system to begin the process of fixing the application.
I'm sure this little scenario is a very familiar one to most readers - but can you manage this lifecycle with the agility shown here? I bet you have some tools and processes that you've created to get close to the same objectives of speed and simplicity - we're aiming for *all* CICS shops to be able to execute as fast and confidently as the best, and ensure that your enterprises see CICS TS and the mainframe as an essential enabler of business agility, combined with all of the traditional values of resilience, availability and security.
So, if you're aspiring to be as agile as Abigail, get to know a Simon (and Oliver) - if you're ready to be a Simon, go meet some Abigails!