This is an ongoing of series of articles
about Configuration Management in a SA environment. This is one of most
difficult areas to understand because this uses multi layer baselines to
support it and also there is also a difficulty of long lives process and
short-lived process.
The definition that has been used in the
SOA programme is:
- Short lived is measured in seconds and minutes
- Long lived is measured in hours, days and months
So instead of an easier application release
which is straightforward as the baseline covers just one cut of the software,
this needs to multi layer in its approach.
To understand the multi layer approach we
need to understand the structure of SCA modules
SCA provides a number of important constructs that are
defined as part of an SCA module deployment description.
- SCA
libraries - each library provides a number of XSD and WSDL documents that
describe the services artefacts that are being reused or referenced within
the module.
- SCA module
file - this provides the definition of the module in terms of the internal
components used within the module. WSRR does not interpret the internal
content information but does identify any externalized dependencies as
imports and exports.
- SCA imports
- these provide the definitions of the external services that the module
depends on. These import files define the interfaces, bindings and
endpoints that the module will need to resolve when it is deployed.
- SCA exports
- these provide the endpoint descriptions that the module exposes in terms
of interfaces, bindings and endpoints.
From this the two most important are the SCA library and module file
and this is where the article concentrates on as these provide the complexity
of baselines.
The complexity comes in because of if there are shared or unshared
libraries then the shared baselines will need to have a baseline of their own.
Also adding to the complexity is determined how the SCA modules are
defined and the project I am working on there are defines as the following:
- Long Lived
Processes
- Long lived
Non Human Processes
- Short lived
Process
This will also have an impact on the releasing of the SCA modules,
as it will be described in further articles.
So as it can be seen already there are a number of different items
that need to be thought about and we have even got to the baselines methodology
that the project is using.
The SCA modules will be baselined to show the versions of the
software that may up the module and the same baseline will be used fro unshared
components, while the shared will have their baseline, therefore the baseline
will look like
- SCA module
1.1
- Unshared
module 1.1
- Shared
module 2.1
- Shared model
3.2
While this looks quite easy however then the problems come thick and
fast this is because there are two ways the baselines can change
If the SCA module changed does the baseline well I think most people
would take the view that this would change.
The shared modules could change does this mean we have to change the
SCA module?
The shared modules could change does this mean we have to change the
SCA module? And what does this mean for the rest that uses this shared module
do their baselines change as well? And does this mean we have to test all the SCA
modules that uses this change?
What is the answer, not mind the question! The answer lies in the
type of change that happens in the interfaces. If the changes are not at
interface level then in SOA terms this is not a change, if the change is at
interface level then this is classed as a change and the will required the top
level SCA module baseline to change.
Behaviour Problems
There is an associated problem with this is that the SCA module has
behaviours that have to be supported in away that can be traced but at the same
are treated as a software change which would created a new version of SCA
modules which is not what you want.
The idea to support this is a very old idea which I have used many
years ago but which fits the build exactly this is the use of information
notes. The type of behaviour we are trying to control is the change of business
rules, which will change every so often as the business gets the used to the
service. As each new information note is issued then the behaviour changes and
usually comes thorough the Configuration Manager. This will show the previous
and new behaviour that the service has to use, however the information of the
change comes from the Senior business Analyst. The change is as usual is tested
in an environment before it goes in to the Production environment and when it
is tested to make sure the production environment has change has taken affect.
The information note has work in conjunction with the existing
systems as this will provide extra information to the /change request record.
To get his baselining in we have approached this is an two stage
method so people can get used to this new method and allow for the main
baseline to get in and then look at how we adjust the overall method for the
second baseline to put into place and this has to tie up with existing systems.
While this article gives a favour of the problems SOA gives to
traditional methods of baselines and how many of the existing systems need to
be adapted to the new ways of working.
Another aspect of this work how hard I have had to work on the
senior management to make sure that they on board for the changes to the
existing systems and making sure I have the budget to make this happen. This
has require a great deal of explaining to them and they have been very response
and supportive we has made my life a great deal easier.
As it can be seen the considerations that I come across during the
construction of the baseline for the project and that as Configuration managers
we have to deal with. While information notes are not consider as baseline in
the true sense of the Configuration management. It is a type of baseline
because it is identifying a controlling artefact of the SCA module
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. He can be
contacted at
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed