Tuesday, July 18, 2006
The concept of services within a business context are not new. We are all used to the following being thought of as a “service” provided to the business:
- Product technical support (Call centres)
And the list goes on. Interestingly, these services have lots in common:
- They are managed and used in direct support of the business. They have a function to perform with a clear path showing how the service contributes to the success (or otherwise) of the business.
- They can be “easily” swapped or replaced for an equivalent service from an alternative provider
- They can be delivered by an internal group/division or by an external service provider
- The product of the service and any input from the business that the service consumes is clearly defined and clearly understood by both the service provider and the consumer
- They are often governed by well defined service level agreements
- They support the ability for consumers (and providers) to measure (using service metrics or KPIs) the use of the service and the ability for it to deliver
- They often support a fine-grained and open cost structure (audit trail, pay-per-use)
- Without them a business would grind to a halt – but they are only normally a part of the business, not the whole!
- They form part of the processes that define how the business works (sometimes a small part, sometimes a large part).
So service’s are not new: what is new is the view of software systems as another kind of service to the business. Before we look at what that means lets take a look back at how software (and to some extent IT in general) has been viewed in the past:
- “software as technology” – In “the beginning” (60s/70s) software was really just a technology, a science if you like. New developments were occurring at a rapid pace, and problems were being solved for the first time. In this era software was centrally deployed and managed (think thin-clients) – as hardware was still expensive. But software too was expensive : it was complex and expensive to build for vendors, but equally expensive to administer and support for consumers. Software and hardware were often bound together tightly.
- “software as product” – The view of software in the 1980s changed. With the advent of cheaper hardware the PC was born. And with it came shrink wrapped products aimed at the “owners” (users) of those PCs. Software was created by development houses, packaged and shipped to customers who installed it on their hardware. Support was provided as long as the customer had a licensed copy of the software.
- “software as project” – As software and IT became integral components to how a business operated, there was a shift in the 1990s towards custom software. Large projects were commissioned to create central software systems for use by the business. These projects were performed by internal IT groups or external software vendors. Sometimes the systems were customised (pick & mix) instances of large complex products (e.g. SAP, Axapta), others were technology-led and developed from the ground up. In recent times these projects have been categorised by late delivery or complete failure to deliver.
SOA is about the next step in this evolution towards “software as a service”, just like any other business service - with the same attributes discussed above.
This view of software really applies to software that makes up some key part of a business process. It does not apply to a calculator type application (personal tool). It applies to software that is central to the operation of the business and used by multiple people in order to communicate some kind of information between them. Typical examples are:
- CRM and contact management tools
- Electronic calendars
- Travel booking systems
- Time tracking
But it is not just software within the business that can be modelled as a service, the interface between companies can be modelled as software services. This allows the service provider and it’s customers to conduct more business electronically: ”e-Business”. For example the primary interface to an external travel agent could be a set services for booking travel and managing preferences etc. This is not to say that other human interfaces are not required, just that the more business that can be conducted electronically the better since it is significantly cheaper. The ultimate vision of SOA is that every business function (internal and external) can be called as a service.
TCP/IP supports the notion of ports in order that a server can run multiple “services” and clients can connect to that service at a particular port. In this world we are really talking about application service such as FTP, HTTP, RPC etc. Most services have “standard” ports.
90% of firewalls on corporate networks automatically block traffic on all but outbound port 80 – this is left open to allow users (web-browsers) to browse websites. This is with the naïve assumption that this will allow the IT group to control traffic and prevent use of unauthorised or unsecure services (such as chat applications or external, or external email that may not be virus scanned).
So software application developers can now only rely on outbound port 80: anything more than this is likely to require users to seek “permission” from IT groups to open ports in the firewall. This will normally be a very slow process and most likely the request will be denied. I believe this is because there is a perception of each open port as a “hole in the wall” – i.e. it weakens the defences.
Since the developers can only rely on port 80 there is now a tendency to squeeze all kinds of traffic through it:
- HTTP file uploads as an alternative to FTP
- Various custom HTTP based protocols for modern IRC apps like Windows messenger
- HTTP based mail protocols like hotmail; and in other cases basic webmail
- Web services – RPC (and hence any computing you like) via HTTP
So IT groups (through poor policy and process) have not plugged any security “holes” in the network, they have just moved the problem on. Now it requires more “advanced” firewalls to attempt to control the traffic going through port 80. Which will cause developers to find some other way to “wrap” different forms of traffic and make it look like the “widely accepted” one.
This cycle will never stop. We all suffer because each iteration causes more processing power to be required in the software (to unpack all the layers), and more processing is required in the firewall to detect “naughty” traffic masquerading as “normal” traffic.
Friday, July 14, 2006
I thought I would find out what this blogging malarkey is all about. I was attracted by the blog feature of Office 2007 beta which I am using.
This is really just a test. Below is a picture of my sister, my niece and their dog.