Services and Web Services

I speak to a lot if people about Service Oriented Architecture and find that many people do not really understand what a service is and what role Web Services plays. The root of the problem is that to understand what a service is, you first need to understand the make up of an SOA. The two key components of an SOA are the Business logic and, for want of a better description, the plumbing. It is the separation of the business logic from the plumbing that makes SOA technology important.


The plumbing layer is concerned with executing services and handling messages. It is entirely independent of the business logic and it is this separation that distinguishes SOA from previous IT architectures. The plumbing is very techie and is consistent throughout i.e. it never changes. The business logic layer is, or should be, entirely free of programmers and their code and allows business analysts to model their processes without recourse to code or script.


It is this separation that gives SOA its agility. Models of business processes can be amended at the same pace the users business needs are changing, overcoming the disconnect between IT timescales and business expectations that has dogged IT until now.


Business processes are built up by linking together models of individual business actions called, in SOA speak, Services. An example of an individual service would be to perform a credit check. Another may be to determine stock availability and so on. Business processes are created by stringing together services. Two factors work together to make this technology very agile. The first is that many services can be re-used over and over again and the second is that the code less development of new services by business analysts is itself very fast.


Typically, a new business service would be made up of a mixture of existing services and newly designed services. The next important feature of SOA technology is that the services are not hard wired or integrated together in the traditional manner - They are loosely integrated. A services communicate with each other by asking for information. For example, if a credit check is needed, any service anywhere in the network can ask the credit checking service to perform a a credit check. This is possible because every service uses an agreed standard for communication. It does not matter what this standard method is as long as every service within an architecture uses the same one.


This brings us to Web Services. These are just a recognized and agreed standard way of communicating between services. Standards such as this are needed so that business processes can be designed that call on services not resident and under the control of the local designers. An example of a commonly used external service is Google maps.


There is one problem with web services - they are relatively slow. For this reason it makes sense to adopt a faster, leaner communication standard internally and to reserve the use of Web Services for external communications.

what constitutes a reuseable service

At the core of the SOA drive lies the desire for reuse. This is because reuse is seen as the way to shorten development times and therefore achieve some measure of agility. The idea is to create services which are then registered and aviable for re-use. The problem is what constitues a re-useable service?

For example, a service might be created that can access data from a specified table and return values that meet certain criteria. A service such as this is nicely non-specific and so the options for its re-use are large. However, developing solutions that orchestrate services of this type will still be a long task.

An alterantive example is to consider re-use at the compound service level. As an example, we might have created a compound service that returns customer data from a specified database. The methods available may return the primary address, delvery address and so on. This woudl be a compond service because it will include several simple services, including the one in our first example. It could even have been contructed with a set of graphical interfaces already defined

The options for re-using the compound service are more limited than those for the simple service, but using compound services at this level speeds up the time needed to create new processes immensly. Which extreme is best suited to a developeers needs

Ready, Steady, Stop - SOA gets in the way

Imagine your a supplier of software. You have invested in developing your software offerings over a decade or so and now you want to know how to respond to the move towards SOA among your customers. This is the problem facing a company I visited this week. They had two problems. The first is that they have several software offerings sold individually and in combination. Currently, these systems are not integrated and each time they sell a combination they hard wire them together afresh. The IT Department believes that the integration requirement is the same every time, but the implementers disagree.

The second problem is how to present themselves externally. If their customers are moving towards an SOA architecture, they are wondering if perhaps they should offer a loosely coupled integration option via web services.

The IT department is proposing that they adopt an SOA strategy and that they integrate their existing software systems using web services and offer web services as the means of integrating their products into their customers IT environments.

Unfortunately, this is a loose loose option. The first point is that adding a few web services to the existing software has nothing what ever to do with SOA. Adopting an SOA strategy would require them to re-build all their software from the ground up. Using web services simply as a means of integrating existing lumps of software is not only nothing to do with SOA's but also will not prove to be an advantage over using an EAI approach. Web services are slow and intended for inter company links where traffic volumes are low.

Unfortunately, the argument for using them for integration with the customers existing software systems is even weaker. With no advance knowledge of the system to be integrated with or how it has been implemented, it is unlikely that a pre-conceived web service will work any time let alone every time. Add to that that the traffic volumes involved are often very large and you have a recipe for disaster.

The Immediate problem for this companyis that the decision by IT adopt the use of web services and present it as an SOA strategy is blocking all attempts by the company's divisional management teams to address their immediate needs for a better way to meet their integration needs

Integration hub v ESB

I know several vendors of software products who are debating the same question: Should they go all out to use Web Services as the only primary interface for integration? Each of them sells software products that have to be integrated with other systems, often legacy systems in already in use at their customers.

This question raises two important issues plus one interesting technology question: The first is just how real is the movement towards SOA's i.e how long will it be before the big majority of their customer operates an ESB with which they can contract? The second is how important from a marketing perspective is it that they be seen to be ready to participate in an SOA?

The interesting technology question is: How good are Web Services for integration tasks anyway?

To give a view on the first question - there is a lot of activity in the marketplace. SOA's are the subject of the moment. That said, there are very few implemented examples of any meaning and the jury is definitely still out on whether or not the approach will give an adequate return on investment.

The answer to the second question - how important is the market perception of a products SOA credentials - paradoxically this seems to be very important. So here we have a conundrum. In practical terms there are very few ESB's in use. The majority of customers of these software's will need an alternative to Web Services for several years yet. But purchasers will want to be reassured that when and if they do get there their vendors will be ready for them

The more difficult question concerns Web Services themselves as the technology of choice. Being XML based they are slow - very possibly too slow for integration use where traffic volumes are high and/or each transaction is very broad.

Being practical, in the short term vendors will be forced to offer rules based EAI or, if their customers will wear it, individually hard coded integrations. Wouldn't it be good if there was a solution out there that offered its users the option to start will a rules based EAI approach and phase in an ESB solution when the customer was ready using the same suite of software?

Trend goes live with SOA solution

Trend Communications has gone live with a ground breaking on-line quotation and order entry system. Developed using EdenAgileIT (www.datadialogs.com).You can view it at

http://83.138.140.161:7734/TrendProto.html)

the solution consists of 150 re-usable services developed using Eden's codeless modeler and orchestrated with a combination of Eden's ESB and JAVA designer. The resulting Rich Internet Application revolutionises the way Trend does business through its distributors.

The approach Trend adopted was to leave their legacy ERP system alone rather than trying to expose any legacy functionality as services and the create the entire customer facing process set from scratch. Quotations under development are stored in a separate SQL Server database and only when an order is confirmed are the details of the assemblies required, with their bills of material passed into the ERP system (Infor's System21on an i-series) so limited are the options for using this ERP system within an SOA architecture that Trend decided not to try and literally Poke the data directly into the ERP systems database (This turned out to be much easier than the vendors scare stories would have Trend believe)

Web services were not used because the large volumes of data involved made them too slow. That's the third time this month I have encountered SOA developments electing to not use Web Services. It looks as though We Services are best suited to inter-company collaborative developments where high volumes are not an issue

Watching an SOA strategy take shape

Before I get on with the technical SOA stuff I promised, here is a diversion you might find interesting. I have come across a mid-sized company that packages and sells materials through supermarkets - Its a well known brand name with a turnover in the £60m range. Just the range that is going to have to deal with the issues I have discussed thus far in this blog.

They have already set up a strategy group to look at the feasibility of Service Oriented Architecture so I have the perfect opportunity to watch the process as it develops and write about it in this blog.

As soon as they give me the information, I will tell you about both the politics of the venture and the technical decisions they take with their reasoning. First decision will be how to start - Agility first i.e a quick kill by identifying a process or related set of processes or the purist, technology led approach through the creation of an ESB and an entirely new process built with all new services.

I can tell you the toolset they have chosen is IBM's Webspere and Weblogic. Watch this space!

SOA - What should I expect in return for my investment

The more people I talk to about Service Oriented Architecture, the harder I find it to present SOA as a one stop suits all solution. I can split the conversations into two groupings. The first set I would describe as managerial in that the questions centre around what the measurable benefits of implementing the technology should be. The second set are technical and centre around how the technology should be implemented. In this blog I am going to try and address the first group. The second group I will address in the next.

I guess the place to start is to re-state the driving objective behind the move to implement SOA's and that is to reduce the cost of delivering solutions to users. Of course, this needs further definition to be useful, since some managers might think that the most effective way to reduce such costs is not to attempt to deliver any. There are two sides to the cost equation. There is the cost incurred while waiting for a solution and there is the cost of delivering that solution. The balance between the two will form the core of any measurable ROI.

Service Oriented Technology is aimed squarely at both sides of this equation - the cost incurred while waiting will be less if the time taken to deliver the solution is less and the cost of delivering the solution will be less if it really is simpler and quicker to create than with any other technology as it is supposed to be.

Unfortunately, adopting this technology is not without an initial set up cost. How large this cost is and therefore how long it will take to reap a rewards for its introduction depends on the interpretation of the technology used and, that in turn, depends on the needs of the organisation proposing to adopt it.

Lets look at the options in turn. At the top of the pile we have the SOA purists. The approach proposed here will eschew any attempt to make a start by attempting to expose services from within traditional existing systems as "Sticking lipstick on a pig". This immediately requires the organisation to invest in the creation of the entire architecture from scratch and therefore the time taken to begin seeing any reward will be long - very long. For a technology that is presented as making IT more agile, this can be a dubious start. The same purist approach will demand that an Enterprise Service Bus (ESB) is implemented and that individual services have to contract with the bus. This is deemed necessary to ensure that no process requires any knowledge of the working of any of the services it needs. Instead it just needs to know what services exist in the registry and how to ask the bus for information from them at the right time. The bus knows content in what format the requesting service needs the information and it also knows what content and in what format it can get it from its register of services. In theory, I am now free to extend the capability of existing services or exchange them for new services at any time and only the ESB needs to understand the changes. Remember, any one service may be a constituent of many different processes.

If by now you are wondering what happens if a service is changed such that it no longer meets the need of every process that uses it this too has been addressed. Governance is the key to ensuring that services are managed so that this does not happen.

The problem I have with this is that there is a real danger that the very agility that is being sought can be negated by the need for tight governance restricting the development of services in line with the needs of the business. This in turn will lead to the development of ever more new services instead of encouraging the re-use of existing ones, thus undermining the whole theory. Whether this concern is well founded is still to be determined - there are not enough experiences around yet.

In terms of getting an acceptable return on the investment, the likelihood is that such a project will be unlikely to give a return on investment in a period of less than three to five years if current results remain the norm. Projecting the future that far is notoriously difficult and is the preserve of the very wealthy or foolhardy

The alternative to the purists are the incrementalists. Here the objective is make quick kills to convince the user community of the value of the approach. By definition, to make a quick kill corners have to be cut. Lipstick will be put on the pig so that existing investments in systems are preserved, An ESB may not be used and the overhead incurred when a service is altered swallowed, possibly inadvisedly, as an acceptable price to pay to make swift gains now.

This approach does, however, have something to be said for it, particularly because recent technology developments are riding to its assistance. The first development that helps concerns detecting and talking to services. The big argument for an ESB is that when a service is changed, only its contract with the ESB needs updating. This avoids the need to update every process with the change. However, there is now technology available that can discover and use a service without any need for re-programming. This makes this task much easier and undermines some of the advantages of an ESB and as ESB's are expensive swings the ROI balance in favour of the incrementalists.

The second development is one that makes the creation of services a code free exercise. This has several impacts on the argument. Its quick and easy to put lipstick on the pig, its cheap to create new services on demand and, most importantly of all, its very simple to re-engineer existing services. Taken together, these technologies when used incrementally put SOA technology within reach of businesses right down the the SME level.

Overview of Example of practical approach to SOA

Imagine a typical medium sized company. It has an ERP system it implemented two years ago, a CAD system and a PDM system plus an separate CRM package. The company has identified a requirement to upgrade its quotation and order entry system which currently is largely manual supported by multiple spreadsheets. This process is labour intensive, prone to error and seen by their customers as unresponsive.

In Service Oriented technology terms, the new process will be made up of the following identifiable compound services:

1. Handling customer data both existing and new
2. Creating a quotation/order header
3. Capturing order line details including Configuring the complex products
4. Creating bills of material as required
5. Printing Quotations/order confirmations

All of these services will be made up of several elemental services that can be re-used over and over again.

Each of the compound services needs to interact with the ERP system. If we start with the customer data, the ERP system needs to deliver customer name and addresses and delivery address information on request and also accept and process new customer data. Unfortunately, although the ERP system was purchased only two years ago, it is of traditional construction and does not offer any services. The first task, therefore, is to add service functionality to the ERP system. In fact, several services have to be created and exposed to get this job done.

1. Customer details existing and new
2. Quotation/Order header and line details input and recall
3. Parts data including costs and new bills of material input.

To accomplish this, I use a technique I call creating Application Service Managers. (ASM's) which I create with a code less modeling tool called EdenAgileIT. Essentially, ASM's are an extension to the Host ERP system that is integrated into it and exposes functionality as, in most cases, a web service. To build an ASM takes me between a day and three days, depending on the complexity of the service being created and the architecture of the host ERP system.

Once I have these ASM's in place, I can go on and create the new compound services required before orchestrating them into the new quotation process. These compound services can be very complex, especially those concerned with configuring products or services. It is not unusual for a configuration service to be made up of more than fifty elemental services. I use the same tool set to build all the services. We have accomplished this particular task for a number of customers now, and the whole process from start to roll out requires between 30 and 50 man days.

SOA - where do I start?

I have just read a paper from IBM about predicting and measuring SOA projects ROI's. I'm not impressed. Urging people to be satisfied with instinct and hope is not going to fly with any CFO's I know. IBM's approach is flawed from the outset in that it fails to capitalise on, or at least preserve, the investment companies have made in their existing IT infrastructure

Very few of us are going to be able to begin with a greenfield site. The reality is that we start with a host of legacy systems, all of which were conceived long before Service Oriented Architectures were invented. Very wealthy companies with a history of being early adopters can afford to set up large teams and set them the task of re-creating their primary systems as collections of re-usable services. Most of us cannot. Nor do I believe that you should even if you could.

A better way is to identify quick kills and make a difference early. For example, re-designing your interface to your principal customer or supplier might be a good place to start. The questions is how? You still have that legacy ERP system to deal with.

The answer is to add a software component to your IT infrastructure I call an ASM - Application Service manager. It's function is to integrate closely with your ERP system and loosely with everything else. Each ASM should be designed to expose a specific function within your existing ERP system as a service. To get going with a project to allow major customers to place orders directly via a web service, you only need one ASM. Building an ASM, if you use the right tools, will take less than a man week, maybe much less, depending on your ERP system.

Once you have built one, move on to another - maybe to upgrade your supplier relationships this time. Pretty soon, you will have exposed a significant number of functions from within your existing ERP system as services. Along the way, you can introduce new functionality made up entirely of elemental services and create improved processes made up of services exposed via ASM's and new services composed from new elemental services.

Each step of the way you will have made a real, measurable difference. Users will see the benefits quickly and support the process. management will see a return and the ROI will be tangible.

SOA – Hooray, got web services, now what?

Just been talking to a friend of mine who was pleased to announce his company has just implemented a new version of their ERP environment. He was quite chuffed with it because now he had lots of new functionality inside his system. Turning this functionality into something that his business could use left him with somewhat disappointing consultancy costs, but never mind, he was happy.

“But”, he said, “this environment comes with Web Services. What do I do with them?”

Fair question. So I asked if it came with the ability to orchestrate these new web services. Looking at me somewhat puzzled, he asked: “ability to orchestrate ? Not sure what you mean.”

“A web service in itself is a nice thing to have but it doesn’t do anything. What you need is a way to use web services from different systems in order to make your way of doing business more agile.” – I replied. And I continued with an example.

Suppose your new environment can expose the outstanding balances of invoices. What you could do is define Key Performance Indicators (KPI’s) that keep track of the fact that the outstanding balances together with their due dates are enough to keep the cash flow position of the company stable. In order to do this, you need something that can calculate these KPI’s and use the outstanding balances from the web service to come to measurements.

If you have the ability to present these KPI’s as a service (possibly a web service) then it would be quite simple to present these figures though any web environment or even to a PDA.

Think about it, wouldn’t it be great to be sitting on the beach of Allicante and being able to check your company’s cash position without leaving your cocktail?

And all this doesn’t have to cost the earth. There are a few solutions available that actually make use of your existing web services and can turn other systems into a SOA-compliant system including web services.

One of my personal favorites is the Google Homepage. I customized it by simply adding a few links and now it shows the local weather, my calendar, my activities, some KPI’s for my company and the latest technology news. (And some other gimmicks that are not very relevant here)

An upgraded system containing web services is like a HD ready TV. It has got the HD socket but without the HD Box (orchestrator) it is still the same as a normal TV.

SOA - Loosing sight of agility

Its getting harder and harder to remember that the idea behind the SOA technology is agility - agility in the sense that the business can get the business processes it wants when it wants them. That timescale is increasingly measured in hours or days, not months or years.

The aspect of systems that is driven by change is the knowledge encapsulated within them. When you create a service to, say, configure a service or product within an order entry system, the service or product is changing to meet market demand. Insurance policy constraints change regularly due to legislation as well as market forces - in short, agility can only be achieved if it is possible to adapt and maintain elemental or replace composite services easily - within hours.

Its the technology used to create the services that will ultimately determine the level of agility achieved, and therefore the ROI gained. Coding services the old fashioned way - functional specification, program spec, programming in a language etc - is, therefore, not a realistic option. At the end of many man years effort, all a company will have is another legacy system, albeit made up of composite services carefully orchestrated.

Look for a technology that enables users to create composite services without any coding - that's where agility lies.

SOA - Why Web Services?

When people talk about Service Oriented Architectures, they usually assume that the solution will use Web Services as the method through which services are loosely integrated. However, there is nothing in the theory of SOA's that demands the use of Web Services. If you are thinking about moving towards Service Oriented Architecture, it is important to think about the nature of the business and the advantages sought from a SOA before automatically assuming you must use Web Services.

The primary argument in favour of Web Services is that it is being adopted a common standard. This is only important if at least one of the following is true:

You intend to expose services to the outside world and include suppliers and customers

You expect to purchase packaged elemental or composite services from vendors (your ERP vendor, for instance)

The primary argument against Web Services is that they are relatively slow, so if your environment is one where all your services are being created internally for use internally and the transaction volumes are very high, then there is a powerful reason not to adopt web services for your primary business processes

An example of businesses that falls into this latter category is an insurance company. Frequently the core systems need to be bespoke and the transaction volumes are very high. In Addition there is almost no requirement for electronic communication between the company's main systems and other companies. Where there is such a requirement, then those specific services could be based on Web Services

SOA, Web Services, Ajax and Mash-up – an overview

Nowadays you can hear buzz words like Service Oriented Architecture, Web Services, Ajax and Mash-up. But for the average business oriented person they can be hard to understand. So what do they mean and what have they got to do with each other?

Let’s try to shed some light on this.

Service Oriented Architecture (SOA) is a concept of making functionality, complex or simple, that is handled by a specific system or server, available to the outside world. This outside world can be inside your own company or exposed over the internet. The service can be called upon as and when it is needed by any other component as part of various business processes.

Web Services is a bit of a misleading name. It implies it is a service exposed over the Web but that doesn’t need to be the case. A Web Service is the technology in which a service can be approached. This service can expose itself over any network connection, including the internet. Hence the misleading name.

Active Javascript And Xml (Ajax) is not really something new. The concept of Ajax has been around for years but of late, more and more development environments have supplied the software industry with tools to make it easier to build browser based applications that interact and feel like more traditional (windows-) based applications. So now you can see more and more application developments creating rich user interfaces for their web applications.

A mash-up can be compared to a portal where various functionalities from different sources and applications are placed on one screen and these various (usually small) functionalities can interact. A common example is the screen that shows the latest news, has an overview of the outstanding tasks and shows, once a task has been selected, the location for that task in a map.

So how does it all link together?

This question is probably best answered by using an example.

Suppose your company has a server that holds all the accounts receivable information. As part of an SOA, a service is created that can expose outstanding balances based on a customer code. This piece of software on the accounts receivable server uses a web service to expose itself.

On the actual webpage that you see, an area of the screen can be used to query these outstanding balances using Ajax. The customer code comes from another area of your screen where all your tasks for today are. Once a task has been selected (clicked on) it takes the customer code from that task (in this case a task could be a phone call) and queries the web service for all outstanding balances. The result is shown next to your calendar. And it does this without contacting the server for an entire new page. It only gets the little bit of info that is needed to display the balances. So now, before you make the call, you can see if there is anything in particular going on with this customer that you may be able to mention during your phone call.

So now the browser contains a mash-up page and the accounts receivable server fits into a Service Oriented Architecture.

Of course this is but a simple presentation of the reality and in real-life there are many issues to consider (security, availability and protocols) but it does give an overview of how it is tied together.

What is SaaS?

As time and technology progresses, delivering solutions to the market have evolved from sending floppy discs to downloading software. So the question arises: is SaaS just another way of delivering software to the user? The answer is: No.

Software as a Service (SaaS) is not about the software but about the solution it brings. In short, SaaS is a model of delivering a (software) solution to the customer where the supplier takes care of maintenance, daily technical operation and support for the solution provided.

In the past, another concept of delivering solutions to the customers in a managed manor was branded ASP. It is fair to compare the two but there are fundamental differences.

SaaS is usually delivered on a pay-as-you-go concept. This means the client uses the solution and is charged based on that usage. It is not very common to tie customers into long term contracts, contrary to typical ASP, where the supplier was forced to have long contracts to make sure every cost has been covered.

But the main difference is not in the payment concept. It is in the providing organization and its solution. SaaS solutions have been designed for internet use and have also been designed to be very scalable in accordance with user demand. The supporting organization is shaped to support high fluctuations in customer demand. Their entire support and service is built around the variation in client numbers. The software is designed to allow users to help themselves as much as possible and provide FAQ’s and newsgroups.

SaaS offers many advantages including a lower risk of piracy, lower installation costs, controllable implementation and maintenance costs and an always up-to-date solution.

But SaaS also comes with risks. These vary from uptime and availability to the stability of the supplying organization. Other elements to be aware of are security and integration issues.

Is SaaS the way of the future?

Yes, for many reasons SaaS will be the way of the future. Companies have been slow to adapt to the concept of SaaS but more and more the risks are being overshadowed by the advantages. In current day-to-day business, the focus is more and more on cost effective and agile solutions.

And this is what good SaaS solutions, together with SOA and Web 2.0 can deliver.

SOA - loosing sight of the objective

I visited an insurance company today to talk about their investment in creating an SOA. They had appointed a manager to lead the project and had forty five programmers working. They have been working for over a year. So far, there has been no tangible result. Yes, they are creating services but they need a lot before they can create a worthwhile business process.

Forty five Programmers for a year? They have obviously lost sight of the principal justification for such an investment - Agility! How can a technology that's touted as the answer to everyone's need for agility need more than forty five man years of effort just to get started.

Then there's another problem - Once the new services are created, say with an average of two man years of programming a piece in them, how easy is it to modify them? They desperately need a technology that can create services in a hundredth of the time. A technology that does away with the need for specification and programming. One that allows its users to create services based applications iteratively through dialogue with the users. They do exist.

Until you've got that, you have not got anything.

SOA Explained

Service Oriented Architectures hold the key to the creation of truly agile IT environments – Agile in the true sense in that user needs for improved or new business processes are met within hours or days instead of weeks or months.

The concept is a simple one – monolithic legacy programs that cannot share their functionality are gradually replaced with small software components that each perform a task. The components are constructed so that they expose what they can do as a service – a service to be called upon as and when needed by any other component without the need for any specific integration. This “Loosely Coupled” arrangement means that every component can be re-used endless times in any number of business processes.

To become a realistic solution, the technology to be used has to be agreed so that companies can call each others services. The chosen technology for this is web services. This technology uses a standardised approach to the problem by specifying the messaging protocols to be used and the way each service is described. The message technology is SOAP and the service description is an electronic document called WSDL.

What is Agile IT?

Agile IT systems are based on new technologies that allow existing business processes to be modified and new business processes to be developed at the same pace as the user can articulate them. To achieve this, the traditional development process of Analysis, specification, programming, testing and release has to be ditched and replaced with a single step, iterative process.Because the processes most likely to be developed this way are the key, customer facing knowledge based business processes such as quotation, configuration, order processing, pricing and margin management, the key enabling technology at the core of such systems is business rules server capable of capturing knowledge coupled to an advanced graphical forms designer. Using this technology, business processes can be expressed entirely in terms of inputs, rules and outputs.Unfortunately, having this technology alone is not enough. To be really effective, Agile IT solutions have to be an integral part of the overall existing IT infrastructure. Ideally, this should be accomplished by first exposing the services available in the participating legacy systems and then calling these services as and when required within the new and improved business processes as they are developed. This type of architecture is termed an SOA (Service Orientated Architecture) and the resulting integration is termed Loose. It is not essential that this type of integration technology should be used, and agile IT solutions can and are being developed without it by relying on more traditional, hard, integration techniques.When selecting an Agile IT toolset, it is important that it should be able to participate in an SOA environment, even if its first uses are based on more traditional technologies.