Entries Tagged 'soa' ↓

A question I often get is “what is an ESB and why do I need one”? This question is motivated by a number of concerns; non-technical people have heard the term but don’t understand the concept, semi-technical people are trying to figure out conflicting vendor definitions, and technical people are confused by the debate between different service enablement approachs – RESTful versus ws-* versus middleware-supported hybrids.

The Elevator Pitch

A service bus provides a uniform and consistent platform to allow service providers and service consumers to interoperate. An ESB provides benefits such as:

• standardization
• loose coupling
• resilience and high availability
• monitoring and intermediation

Hardware

I’m not sure of the provenance of the word “bus” as it is applied in the technical domain (I’m sure there is some interesting etymology there) but you can confidently trace it back to the concept of a computer hardware bus. The idea of a hardware bus (or backplane) is that hardware components – such as sound-cards, video cards, floating point accelerators, tape-drives, barcode scanners etc – can all slot into and interoperate through a shared infrastructure. By supporting a standard hardware interface and a standard software protocol, the hardware bus abstracts the details of each individual hardware component. The key features of the harwdare bus are:

• standardized hardware connectivity to the backplane
• standardized software protocol between each component and the backplane
• hardware components can operate independently without having to know details about each other
• a single infrastructure replaces multiple point-to-point connections between components (i.e. does away with a lot of ad hoc soldering).

Software

Networked systems arrived in the seventies and grew out of control in the eighties. Early network infrastructures such as Unix sockets were hard-wired point-to-point affairs with little or no abstraction of the the two programs that were working together.

The idea of a software bus is that software components can work together – yet independently – via a standardized message passing mechanism that would abstract away the need to create individual network connections between components. The software bus would take care of routing messages to the required location and also take care of all that hard stuff like quality-of-service, reliability and scalability. This is equivalent to standardizing the “hardware connectivity” in the hardware bus. TIBCO’s predecessor – Teknekron – articulated the concept of the software bus in the early nineties

The Service Bus

So the hardware bus standardizes hardware connectivity and the software bus standardizes software connectivity. The Service Bus has refined the concept of the software bus by taking a more service-oriented approach and adding support for the XML stack underlying web services and transport connectivity (e.g. bridging HTTP to JMS).

So why do you need an ESB? More on that anon…

Yesterday I noted the weak case-studies at SOA Consortium. Here is a great post from Richard Veryard about the poor quality of SOA Case Studies in general.

Richard is from CBDI Forum which I can say from experience is one of the most comprehensive and independent sources of SOA best practices and information. Perhaps CBDI Forum can add an SOA case study to it’s journal?

An important force helping to push SOA up the slope of enlightenment is the sharing of knowledge, experience and validation from SOA “doers” rather than marketers. The SOA Consortium is one body set up by the OMG to try to help this along (although caveat emptor the consortium is sponsored by a bunch of vendors).

I read through the SOA Executive Insight Report which reports on the discussion between a number of CIOs who all apparently have extensive SOA experience. There are a couple of interesting comments of note.

The CIOs…

“expressed concern regarding the current industry focus on wire protocols and products, rather than business value generation and the necessary business and IT changes for sustainable SOA success. The industry – vendors, press and practitioners – must “elevate out of the technical weeds” in order to engage the business on SOA.”

This was written in April 2007, but is still so true today. In particular the arguments of ws-* versus REST are not about SOA and should not be confused with the viability or otherwise of service oriented approaches to providing functionality and value to IT users.

The second interesting comment is:

“CIOs noted the lack of common practices for

• service versioning,
• the complexity of testing shared services with multiple consumers,
• the challenge of identifying mission critical services,
• the reinvention of chargeback procedures,
• blind spots in capacity planning, and
• the need for ‘real-time releases’.

The CIOs want best practices for these issues. Specifically, they mentioned an ‘ITIL for SOA’.”

These are issues that I see creating many challenges for SOA adopters and there are no simple solutions. These are also issues I have run into in my own SOA work and I hope to write about them in the future.

One other comment on the SOA Consortium web site. There are a number of SOA “case studies” which is great to see, but very disappointing once you drill into them. They lack any real “meat.” We need more than just a few bullet points…details are needed on what challenges they faced and how they overcame them. As they stand the case studies look like a selection of vendor power-points.

I recently found another set of SOA metrics on IT-Director.com. There is a gratifying degree of overlap with the metrics that I discussed recently. I particularly like the categorization into different metrics for different roles in the organization.

From his observation of innovative organisations, Smith has come up with 10 possible service delivery metrics, grouped by organisational area:

Corporate Metrics:

1. Revenue per service;
2. Service vitality index (the amount of revenue from new services over the last 12 months as a proportion of total service revenue);

Management Metrics:

3. Number of new services generated and used as a percentage of total services;
4. Mean time to Service Development (MTTSD);
5. Mean time to Service Change (MTTSC);
6. Service Availability;

Project Metrics:

7. Service reuse;
8. Cost of not using or stopping a service;

Service Development Metrics:

9. Service complexity;
10. Service quality assurance based on systems-level tests that examine the behaviour of service-oriented use cases across possible choreographies.

The original post contains some further discussion of the metrics.

I suggest that Service Reuse also has a “management” role since that is related to return on assets which is a key measure of success for your SOA initiative.

Revenue per Service is another interesting one and I’m not clear if this refers to “external revenue” or “internal revenue”. There is an argument for measuring both.

External revenue reflects the value of services to supporting overall revenues to the business. I suspect it would be difficult for most organizations to attribute external revenues to the service level. Revenue would map to a particular business process which in turn is supported by services. There would then need to be some way to allocate a contribution to each service on this basis.

Internal revenue would reflect the value of the service to internal business operations and could be counted via some metric on how often a service was used.

Following from my last entry on metrics I do think it is important for metrics to be used to monitor and demonstrate continuous improvement as part of an SOA initiative (or any IT initiative, for that matter).

Key metrics should be built into your SOA organizational infrastructure so that they are maintained and reported as a by-product of your day-to-day SOA activities. So even though I don’t believe there is (currently) any absolute measure of SOA success, what is important is the relative measure and how that changes over time – “am I getting better at this?”

So what are some good metrics? ROI is the most fundamental metric. The reason we embark on an SOA and the reason that the business pays for it is to improve the bottom line – make IT more cost effective and more responsive to business needs. ROI is important to your CEO, your CFO, your CIO and your shareholders. The problem with ROI is that it can be difficult to measure…especially when dealing with less tangible measures such as opportunity cost around time-to-market (agility). What we need are some good proxies for ROI which can be easily measured on a day-to-day basis.

Cost to build a new service is a good metric. If services are provisioned as a project, then it should be relatively easy to measure the total cost of delivering a new service to the business. You should normalise this metric against the complexity of a service. Split services into simple, intermediate and complex if that makes sense. The total cost per new service should decrease over time.

Elapsed time to build a new service is also a good metric to monitor agility. This is a simple form of Nick Malik’s agility metric. Basically we want to ensure that we are delivering new services faster by leveraging off our SOA infrastructure. One of the commonest complaints I hear from businesses everywhere is that IT takes too long to deliver. As with the cost metric, you probably want to normalise against the complexity of a service in some way.

Service utilization is another good measure. Once a service is provisioned, how many business processes make use of that service? What is the daily throughput for the service? These can be objectively measured by service monitoring tools. But note that counting business processes requires some thought to meta-data in your service infrastructure.

Services with a high utilization will indicate what is of most value to your organization. Conversely, services with a low utilization may indicate a low value service or a function which shouldn’t have been made into a service in the first place. Perhaps your governance processes around service identification and prioritization could be improved here. Alternatively, services that used to have high utilization and now have low utilization may indicate obsolescence where it makes sense to retire that service.

Average cost per service, Delivery time for a Service and Service Utilization are easily measured, fundamental metrics for your SOA. There are other SOA costs that should also be accounted for.

Average cost to run a service is important. Add up the BAU costs (hardware, software, maintenance, monitoring, administration, power consumption etc) of your services infrastructure and divide by the number of services you are running. This measure will often be high when you start out and have few services, but should reduce over time.

Governance cost should also be tracked. What is the cost of the governance processes that you put in place to evaluate service candidates, prioritize and plan your services road-map. Usually this cost is made up of time and effort for the people involved in SOA governance. The governance cost per service will initially be high, but should hopefully reduce over time. [This raises an interesting question...how do you measure the effectiveness of governance in order to justify the additional cost? It is difficult to separate out the contribution of governance to the overall SOA benefits.]

These measures can be combined to give an overall ROI index for your SOA. If you can estimate the total business value of your processes and divide by the total cost of the services that support those processes, then you get an aggregate ROI measure

Finally a warning to be careful about how you define a service for inclusion into these metrics. True re-usable services come with a higher price-tag in terms of planning, governance and infrastructure, but the idea is that re-use amortizes the cost over multiple business processes ending up with a positive ROI for the service. There are probably many integration points/projects which do not justify treatment as a re-usable service. These “point integrations” should not be included in the SOA metrics because you are not comparing like for like.