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.