There are three essential components of the delivery
- Published Service
- Long-lived Business Processes
- Short-lived Business Processes
Customer_Alterations is an example of a service that is being delivered within the Programme
This at the initial baseline of the first delivery of the service and this will contain all three components. This will constitute the baseline Service_Name_1.0.0 However, the parts that can change are the Published Service (PS) and the service. The most likely scenario is adding more processes to the service or patch changes to the processes within the service.
The next section describes how these changes will be managed.
Updating of the Service
This diagram shows the additional business processes being added to the long lived business process in the service.
This will be a service of the same name but a different version, to make sure the PS points to the correct service. This will allow for the PS to point to the modified service while at the same time it will allow for the existing processes in the old service to complete their processing and eventually are not working. This is because when the new service is installed on the server the PS is pointed to the new service allowing new interactions with the service to go the updated service.
An example of a long-lived Business Process maybe "Update Customer Details"
Examples of short-lived processes maybe:
- Update Customer address
- Update Customer name
- Update
Contact details
The newer version of the service will contain all the business processes that are currently in the older version plus additional processes.
The diagram below shows how a service and processes are structured in this case in Subversion.
This shows the service name of service.person and this has two processes that make up the service.
- Service.person.1_0_0
- Soap.person
Baseline Identification
To identify those services which are ready for being promoted into testing then a developer will add a baseline to the service that is ready for testing.
{Service_name}_{major.minor.patch}
{Process_Name}_{major.minor.patch}
A suggested baseline format for test environments
{Service_name}_{Test_Environment)_{major.minor.patch}
{Process_name}_{Test_Environment)_{major.minor.patch}
For Production releases the format will be
{Service_name}_{major.minor.patch}
To accommodate this use of baselines the baseline will move on from Service_Name_1.0.0 to Service_Name_1.1.0 as this represents new functionality being introduced. As the old version comes to an end of its life then this can be removed from the server without affecting the newer version of the server as this has the existing processes contained within it. Each service will have its own baseline, the implications of this is that if we deliver a number of different services then we will have to delivery a number of different baselines as well.
This model will also assist in the promotional model being used as this will different services to be promoted at different time or dependant services delivered together Each process in the service needs to be baselined to ensure the files, which make up the process are clearly identified.
Service and Process Baselines
To be able to support the delivery to the environments the delivery baselines will be made up of Service and process. The definition for the Service baseline is:
To identify the service being delivery to an environment and this will allow for co-existence on the environment of multiple services on the environments at the same time.
The definition for a Process Baseline is:
To identify the components that makes up a process, which is being delivery to an environment.
This is described in further detail in the
next section of this document
Tags and versions
Each SCA module is versioned and the components are also version as with any CM system. However the tag or baseline needs to be carried out at different levels at the SCA modules and the components, which are associated with the SCA module and shared components, which will need their own tags.
This shows where we have shared components
such as interfaces that they will have their own tag.
Shared libraries or components in a SCA
Module.
An SCA module may be up of a number of shared libraries or components. Those components which are shared will the number as the SCA module that is being released. The shared components will have there own tag because other SCA Modules will reference these.
The tag sequence will look like this
SCA Module 1.1
C1.1 (reflecting this is non shared component)
B1.2
A1.3
The non-shared tag will also be referenced first in the list that makes up the SCA module.
Movement of baselines
If one of the process baselines, then the service baseline will change and depending on the change will determine how the baselines will change. In these examples it is assumed that Process B and C are shared libraries, so therefore have their own tags.
- Customer_Alterations _1.0.0
- ProcessA_1.0.0
- ProcessB_1.0.0
- ProcessC_1.0.0
This will always be the initial starting baseline for both the service and the process
- Customer_Alterations _1.0.1
- ProcessA_1.0.0
- ProcessB_1.0.1
- ProcessC_1.0.0
This shows that ProcessB has had a patch change; therefore the service baseline has change by 0.0.1
- Customer_Alterations _1.0.2
- ProcessA_1.0.1
- ProcessB_1.0.1
- ProcessC_1.0.0
This shows that ProcessA has had a patch change; therefore the service baseline has change by 0.0.2
- Customer_Alterations _1.1.2
- ProcessA_1.1.2
- ProcessB_1.0.1
- ProcessC_1.0.0
This shows that Customer Alterations LLP had a minor change and therefore ProcessA has also changed number, as this needs to be same as the LLP number.
- Customer_Alterations _2.0.0
- ProcessA_2.0.0
- ProcessB_1.0.1
- ProcessC_1.1.0
This shows that there has been major change in ProcessA and this will result in the Service baseline having the baseline 2.0.0 even though ProcessA and ProcessB are still which patch and minor releases respectively.
- Customer_Alterations _2.0.1
- ProcessA_2.0.0
- ProcessB_1.0.1
- ProcessC_1.1.1
This shows there has been patch change to ProcessC
- Customer_Alterations _3.0.0
- ProcessA_2.0.0
- ProcessB_1.0.1
- ProcessC_1.1.1
- ProcessD_1.0.0
This shows there has been a new process (ProcessD) being added to the service, so the follow the convention the major number will have to change and in the case it moves from 2 to 3. It also shows there has been a patch releases in ProcessC and the Service baseline has moved as well.
Co-existence of Baselines
There will be the possibility of many baselines existing on the environment at any one time the release note will reflect which baselines are currently on the environment. This will help if there is a problem occurs on the environment that the person carrying out the
resolution of the defect has a complete of the set up as regarding to SOA delivery.
Alan Rogers has been working as a Configuration Manager for the last 13 years and been in the IT industry for 17. He has worked on many projects both designing the Configuration Management infrastructure as well implementing it for many large companies for particular projects. A lot of these processes and standards that he developed for the project have in many cases been adopted as corporate standards. He also has an MBA from Henley Management College, which has been very useful when trying to explain Configuration Management to Senior Management, and is also a chartered Manager holding a MCIM.
