|
Configuration Management in an SOA Environment |
|
I am the Programme Configuration Manager
for the SOA programme for a large UK financial company, which have
adopted an SOA approach for creating new services to replace existing
applications.
Part of the problem which I have found when
first trying to come up which a Configuration Management strategy, is that
normally you can go to the internet and there are lots of articles on a subject
in a particular area. However, what I found was that there is very little and
what there is, is mostly theoretical even from well established names.
This series of articles is looking at
different aspects of the introduction of the SOA into software development and
mainly concentrating on the Configuration Management aspects of the lifecycle.
This looks at taking a lot of theory and how this migrates in to a practical
Configuration Management processes such as build management, release management
and defect management. All these areas have a new way of working to support the
SOA environment.
Hopefully this series of articles you show
how much effort is require having a new understanding of the Configuration
management. It must be clear this is not the only solution to the CM aspect of
this area but hopefully this will give all Configuration Managers some pointers
of what they have to think about when putting a CM system for a SOA system.
As in any large companies that are many
existing and well-established processes that have been used for many years and
what I have found even in these early days of the programme is that many of
these processes do not support the SOA environment.
One thing I have noticed is the management
attitude towards SOA development because they have readily accepted that the
work we are doing in the area is not cutting edge software but bleeding edge
software. It has been explained to them that they is little reference material
on this area apart from theoretical and mistakes will be made and major changes
to processes will be made and they have taken this on board.
One of the things I have noticed very
quickly is that you need to explain what this is because many people are used
to applications rather than a service being created. Therefore I have to do is
explain what a service is and a came up with this,
If there are eight departments and they all
need calculators the company will build eight different calculators. What SOA
tries to do is to take the eight calculators and extract the core components
when it is re-engineering a process, so it creates the core components and
eight interfaces and the core components can be used again.
When approaching this type of development
the communication between supporting departments is very important. This is
because many people when there first hear about it can make them defensive
because in some cases they know it may affect their job in the company. The way
this has been sold into the company is by:
- Where we can use existing process, which fits in with the
programme then use it.
- Where need to adjust the processes of the company demonstrate
to the people what parts of the process need to be adjusted.
- If a new process need to be written then the outline of the
process is written and discussed with the various departments involved.
This shows them some thinking has taken place, but the approach I have
taken is to mention this is always open for discussion which makes them
feel as part of the decision making process.
With the introduction of SOA there is a new
language to learn as well because people even familiar with Java development
there will be some new concepts and a new language to learn. To understand this language the technical
architects of the programme have been a great source to tap into because they
tend to live and breathe this kind of development.
The amount of software tooling that has
been required to support the development of SOA has been greatly underestimated
and part of my work has been to get all software used by the developers,
Analysts and testers to the correct version. This has included purchasing all
the necessary memory not only for the PC's but the servers as well. The types
of software we used will be explained and the integrations that have been put
in place to support an integrated software development environment.
One of the main aspects this has affected
has been the baselines of artifacts that make up a releases because it needs to
be done at several different levels but this be explained in much greater
detail further articles.
The build system has become more
complicated because like the baselines because the services has been in a
number of different ways such as:
- Single service
- Multiple services
- All services if there is a change in libraries
- Services with dependencies
All this has is to be controlled and over
the series articles this will be explained how this is carried out and at the
same time how this is controlled so the services can be released to the
different environments.
One of the particular problems that we are
assessing at this early stage of the project is how services will be
decommissioned from the production environment. The real challenge has been to
make people understand we will be running multiple services of the same name at
the same time. The decommissioning of the service is unlike application
software because you can't up remove the software, as you normally would use
application software. This will be explained in later articles and in detail on
the approach that has been taken to resolve the major issue.
Many of the support applications such as
Remedy that have been designed over the years and support the company very well
over the years. However, with the introduction of SOA this has required a re
think on tools like Remedy, this is because the tool needs to be redesigned to
support the SOA service. However this has to be done without breaking the
entire setup, this is mainly due to the cost involved in carrying out this
work.
One thing I haven't mentioned yet is the
choice of Configuration Management we have chosen to support this type of
development and the reasons for this choice we be explained later in further
articles. Further articles will explain how the Configuration management tool
has been setup so we not only baseline software but the documentation as well.
As you can see the introduction of SOA has
many challenges, which need to resolve, and the series of articles looks at the
practical problems and solutions that I have come up to overcome these
problems. Hopefully this will give an insight in how the SOA area needs to be
addressed in terms of Configuration Management.
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. Alan has an MBA from Henley Management
College and is also a chartered Manager holding a MCIM.
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed