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.