(I could comment further, but it speaks for itself).

Go visit and find out.

No related posts.

In my view, the real economics of SOA is about how many times you pay for the same function.

In the world of packaged applications you have very coarse control over the number and bundling of the functions that you have available. If you buy a packaged application, then you typically buy a bundle of functions or capabilities – some of these hopefully will be functions that you need, yet others will be functions that you don’t need.

An example of this is if you buy a billing application which has inbuilt functionality for handling customer contact details. You may not need customer contacts in your billing application because it already exists in your CRM (for example). However, as delivered, the billing application requires its own proprietary customer contact details module because it is incapable of working with a 3rd party’s CRM data. So there are a bunch of costs associated with purchasing a packaged application:

1. The cost of the functionality that you require.
2. The cost of the functionality that you don’t require (the vendor charges licence and support fees for the whole package, not just the bits you really want to use).
3. The infrastructure cost of hosting all this functionality – required and not required.
4. The cost of integrating the functionality you require into your business processes.
5. The cost of integrating and potentially mitigating the functionality that you don’t require.

If we consider cost 5) in the context of my example. Even though you have a perfectly good CRM, the billing system requires contact details to be managed within its own application database, so you have to integrate your CRM with the billing application. There may be side-effects of this integration which need to be mitigated. You may need to invent whole new business processes to manage duplication between two or more systems and the inevitable synchronization problems that arise.

In an SOA utopia, there is more fine grained control over the functions that you acquire from a vendor. In particular you can buy only the functions that you need and then have them plug into other services in your information infrastructure. This saves a number of costs:

1. You only pay for the function that you require
2. You don’t pay for the functions that you don’t require
3. You only pay to host the functionality you have bought – not a bunch of tag-alongs. And if your function is remotely hosted, the costs of hosting the new functionality may be very low.
4. You pay only the cost of integrating the required functionality into your business processes
5. You don’t have to pay to integrate and mitigate functionality you don’t require

So the economic value of SOA is in the finer granularity with which you can manage the cost of your IT functionality. The job of the enterprise architect moves from managing a portfolio of applications – complete with duplicates and overlaps – to one of managing services or functions, with hopefully minimal duplicates and overlaps.

But this picture wouldn’t be complete without considering the additional overheads required for a well functioning SOA. Architectural standards and governance are required to ensure that you buy the right services at the right time and that the services can be integrated properly into your business processes. You should then add in costs associated with:

• There is a cost for running an enterprise architecture function – managing standards and governance.
• The cost of acquiring a specific function may be higher because of the additional planning and research required to get the “right” function for your business processes and to fit into your enterprise services framework.
• The integration cost of exposing functions as services is generally going to be higher than just building a point integration. This is because of the greater degree of planning involved with providing a service in a reliable and re-usable manner.

But hopefully the additional cost of architectural governance and standards should be offset by the savings in managing services as opposed to packaged applications.

As a final note, it’s interesting to note that the economic model is similar for the vendors as it is for their customers. This is why many packaged application vendors are hopping on the bandwagon of SOA. These vendors have acquired applications with overlapping functionality and require a more fine-grained approach for managing and selling their functionality.

Related posts:

1. SOA Metrics for Continuous Improvement

So I really like Ian Robinson’s post on Temporal and Behavioural Coupling where he uses two coupling dimensions and the inevitable magic quadrant to classify systems based on their degree of temporal and behavioural coupling.

See Ian’s post for the slick professional graphics, but to summarise – event-oriented systems with low coupling  occupy the “virtuous” third quadrant of the matrix. Conversely the brittle “3-tier” applications that many of us struggle with, occupy the “evil” first quadrant where coupling in both dimensions is high.

However I’m a little miffed to see no mention of my favourite “document-oriented message” in Ian’s diagram. As Bill Poole writes; document messages have lower behavioural coupling than command messages, but more than event messages. So would you put document-oriented messages near the middle top of the matrix between command-oriented and event-oriented messages? Unfortunately that would break the symmetry. But it also highlights another problem.

Any type of message – document, command or event-oriented could temporally be tightly or loosely coupled. Temporal coupling is more a property of the message transport than of the message type. So I suggest that the two coupling dimensions are characterised as follows:

• Temporal coupling – characterised by message transport from RPC (tight coupling) through to MOM (loose coupling).
• Behavioural coupling – characterised by the message type from event-oriented (tight) through document-oriented to event-oriented (loose).

It so happens that distributed 3-tier systems generally employ both command-oriented messages and RPC transports – hence making them inherently “evil”. Whereas events (being asynchronous)  are naturally virtuous by typically being carried over MOM transports (it’s difficult to request an event notification).

Between heaven and hell, it is in the murky mortal realms of SOA where we need to be constantly mindful of the interactions between message type and transport – lest our system ends up in limbo.

Related posts:

1. Dimensions of Coupling
2. The benefits of an ESB
3. What is an ESB and why do I need one?

One interesting development is that the rate of SOA adoption has slowed in 2008. About half of respondents last year who were planning SOA adoption, now have no plans for SOA adoption. The two main reasons for not pursuing SOA are a lack of SOA expertise, and the perceived lack of a business case. These reasons may be correlated in the sense that lack of SOA expertise makes it difficult to build an SOA business case. But the fundamental conclusion is that SOA doesn’t make sense for everybody.

SOA Adoption shows considerable geographic disparity. Europe has almost universal adoption (70% currently using), followed by North America (55% currently using) then Asia (25% currently using). The majority of organizations in Asia have no plans to adopt SOA. The report doesn’t really analyse why Asia has such low SOA adoption. My guess would be a combination of factors including lack of SOA expertise in the region, the characteristics of Asian companies being late technology adopters and the preponderance of manufacturing in the region which the survey shows has overall low SOA adoption compared with other sectors.

Organisation size correlates strongly with SOA adoption and the range of SOA deployment. There is a sweet spot for mid-size companies with current SOA adoption high in companies with employees between 1000 and 10,000. Large companies obviously struggle with the governance processes required to adopt SOA enterprise wide.

A big surprise for me was the correlation between SOA adoption and primary development language. Forty percent of current SOA adopters use Microsoft .NET. There is also a clear trend over the last 3 years away from Java toward Microsoft .NET and “other” languages such as dynamic languages. Correlation doesn’t mean causality so there is a lot of wiggle room in how you interpret this but clearly there is a move away from Java for SOA development. Harkening back to the COM/CORBA wars of the 90′s one of the key factors was that the Microsoft development environment made COM so easy to develop versus the complexities and diversities of CORBA that eventually COM came to dominate the component world. Is history repeating itself?

Web Services are the dominant SOA model, but a significant minority uses POX and REST approaches. About one third of existing SOA adopters already use or are planning to adopt EDA. The report also claims significant plans for WOA adoption, but I’m not convinced by the data. An eyeball comparison between Figure 14 (current WOA adoption) and Figure 15 (planned WOA adoption) doesn’t show a great deal of difference to me, except for Figure 15 looking a little more “peaky” around the 50% mark. So WOA adoption will increase, but I’m not convinced the data shows this is “dramatic” as stated in the key findings of the report.

Related posts:

1. The State of SOA Adoption
2. SOA Executive Insight Report

While the WOA concept does indeed provide deeper insights into how to best implement a Service and create an infrastructural approach for scaling Services, we simply don’t see a need to identify this as a truly separate architectural approach…

ZapThink believes that the term Web-Oriented SOA represents greater clarity than WOA, since it disambiguates the desire to position WOA as an alternative to SOA as well as more accurately positions the concept at a lower level of abstraction than the SOA concept. Going forward, hence, we will prefer the term Web-Oriented SOA over WOA, since it provides greater clarity. And clarity is exactly what companies today need to make SOA a reality.

My emphasis added – hear hear!

But I still have a problem with this terminology. It doesn’t exactly roll off the tongue and the use of “oriented” twice in the same term is really ugly. Moreover, we’re still mixing two levels of abstraction into the same term.

“Web Oriented” is a reference to the style of implementation of the Services which comprise the SOA. So wouldn’t it be better to use the terminology “Web Oriented Services”?

To take it a step further, I think we can do better than “Web Oriented” in categorizing the Service implementation. The two main Service implementation patterns that we have in the current debate are implementations based on Web Services standards (ws-*) and those based on REST. A key differentiator between these implementation styles is that Web Services are based on an “interface description” of the service, whereas REST is based on a “resource” as the key entity that we operate on.

Hence I propose the terminology “Interface-Based Services” to refer to the ws-* Service implementations and “Resource-Based Services” to refer to Services implemented in a RESTful manner.

So at the top of the ontology we have SOA – our architecture comprised of Services as first-order citizens. Those Services may in turn be Interface-Based or Resource-Based in their implementation. Note that an SOA could quite easily comprise a combination of Resource-Based and Interface-Based Services.

I think this nomenclature is clearer…but it won’t catch on because these are not TLAs!

Related posts:

1. WS-* vs REST (ack)
2. What is an ESB and why do I need one?
3. Web2.0 Informing SOA

“…since there’s little question that the core ideas behind SOA seem to be the right ones. Rather, it’s been how we’ve gone about designing and implementing SOAs that appears to be at the crux of the issue. As we look at the most successful examples of SOA actually working, we keep being drawn back to the Web itself.”

Along the way Dion points out a couple of differences between the Web and the enterprise which I think are pretty salient and underscore the issue that its not the technology that divides the two hemispheres of the service-oriented world.

“One big issue…is that enterprises are often very much unlike the Web. Many of the aspects that make the Web successful…just don’t exist in the enterprise with it’s wilderness of relational databases, proprietary applications, and silos of every description, despite some success in adding a traditional SOA layer on them.

The article Dion references in the last quote has this great summary graphic:

But in addition to the technical differences between the Web and the Enterprise, I think it is worth mentioning some fundamental cultural differences:

• The participants: When it comes to Web APIs that have been so successful, the conversation is basically between technologists. By-and-large it is technologists that are writing the mashups that demonstrate the success of Web2.0. Conversely with SOA in the enterprise, the conversation is (supposed to be) between technologists and business – and plenty has been written about the lack of success there.
• The success criteria: There are different success criteria for Web2.0 versus enterprise SOA. Very few Web2.0 companies currently make money out of their APIs. Success for Web2.0 is “eyeballs” and VC funding. In the enterprise, SOA success is all about hard ROI.
• The legacy: Most enterprise services must build on legacy applications, whereas Web2.0 applications are mostly greenfields and purpose built for the Web. Legacy applications rarely expose “resources” directly. If you’re lucky, the application exposes API methods which encapsulate an awful lot of business logic around a resource.
• The standards: Also part of the legacy is that WOA is “an emergent set of best practices…not a formal set of standards.” Let’s face it, WS-* are a formal set of standards designed by disparate committees often with competing agendas and ulterior motives. The structure and evolution of these standards has not been optimal for the users.

Fundamentally, I agree that Web2.0 in the enterprise and REST approaches to SOA have a lot of value and can teach us how to do SOA properly. Conversely REST needs to address enterprise concerns more fully. The key is recognizing the commonalities and the differences so that we can hit the sweet spot in between.

* BTW I’m not a big fan of the term WOA to denote “Web Oriented Architecture” or REST-ful approaches to Services. While I understand that distancing REST from WS-* makes good marketing sense, ultimately I think we are all talking about Services – so WOA is really a style of SOA. Jockeying for market position/dominance/discrimination has already got us into such a mess.

Related posts:

1. The State of SOA Adoption
2. Web-Oriented SOA
3. WS-* vs REST (ack)

My views on this are a product of my past experience with MOM-based distributed computing. My earlier description of an ESB is based on a MOM approach and probably differs from the common perception of a “black box” ESB. The MEST approach would be very natural to people with an MQ, Rendezvous or JMS background…which is probably the minority of current SOA practitioners.

About 10 years ago, MOM messages were exchanged between systems using proprietary message representations such as COBOL Copybook or AE-Message formats. Enterprise concerns such as scalability, reliability and fault-tolerance were dealt with using techniques at the messaging level. MOM quality-of-service dealt with guaranteed message delivery and message ordering (in normal cases). Where possible, message endpoints were implemented in a stateless manner to allow for easy failover and load-balancing. This general approach is still valid today…only the message representation has changed.

When XML became more mature and accepted, MOM messages started to be implemented with XML payloads. Even after SOAP became a standard, my experience is that it wasn’t rapidly adopted by the MOM community. Proprietary XML message schemas ruled for a couple of years and SOAP had its initial application in RPC over HTTP implementations. But the great thing about SOAP is that it is a nice generic message envelope that is acceptable by everyone. Put your meta-data into the SOAP header and the payload into the SOAP body. If you didn’t have it, you would have to invent it – and many did. Hence, as a pragmatic approach SOAP was adopted as a generalized envelope over – now – JMS. Add the correct JMS headers and you have SOAP Document Literal Encoding over JMS. Additional standards like WS-Addressing, WS-Security are additional sets of meta-data in the SOAP header with meaning to the endpoints and intermediaries in the message journey. WSDL is simply a way of representing the contract between message producer and consumer. I think this is a relatively natural progression from proprietary MOM to more open mechanisms for message exchange which are compliant with the core Web Services standards.

Contrast this with the original RPC approach to Web Services. SOAP RPC Encoding was the original standard, buried within code generation tools which attempted to hide complexity from the developer. Unfortunately this resulted in Web Services which lacked interoperability and created tight couplings between provider and consumer. Moreover, the attempt to shield developers from the distributed nature of their services and the underlying transports – all very necessary concerns – led to huge problems with meeting the enterprise requirements for services. This is the experience of most Web Services developers and it is no wonder that Web Services have such a bad reputation. Subsequently, Web Services – SOAP in particular – has moved to more inter-operable approaches through WS-I. But a lot of damage has been done, and the continued tendency to ignore the distributed nature of Web Services continues to cause problems in terms of unrealistic expectations.

So I like the MEST approach and find that it resonates well with the “pragmatic” approach to Web Services via the adoption of SOAP and other WS-* standards by the MOM community. I can summarize this “pragmatic” approach as:

• Transport Independence is a myth. Use the transports for their strengths – JMS for reliability and HTTP for ubiquity.
• Understand the distributed nature of Web Services and use the long history of best practices from distributed computing and Message Oriented Middleware (MOM).
• Understand the standards and how they fit together. Most importantly, know where the holes are.
• Use the standards where they make sense. Augment them with your own enterprise standards and best practices where necessary.

The result will be better confidence and ownership of your SOA infrastructure. You will rule the standards and your tool vendors rather than the other way around. As an added bonus, you get asynchronous services as a natural part of your SOA – an area where the WS-* standards struggle right now.

Related posts:

1. Waiting for the great leap forward
2. Standalone Web Services and the Decline of the Browser
3. The benefits of an ESB

“Lots of things change in an IT or business environment: location and availability of services, versioning of Service implementations and contracts, changes to business processes and policies, new or changing requirements for reporting, visibility, and control, and of course the need for new capabilities to solve emerging business problems or capitalize on new business opportunities. However, if you think that a Service is just an API, then all hell breaks loose when you try to connect a Service Consumer directly to a Service Provider.”

I wrote about this in a previous post…the need to Design for Change is a critical requirement for any organization and is one of the prime reasons behind adopting an SOA approach. Architectural approaches such as “loose coupling” are an important part of design for change. But that is only one dimension of the problem. Design for change also needs to be built into the IT culture. Change processes must be a natural part of your Services development and management lifecycle.

I find a common mistake is that Services are designed for a point purpose at a point in time without regard for how they will change over time. The result is brittle solutions that are expensive and risky to evolve.

The ZapThink article goes on to talk about late binding and the use of a services proxy and WS-Addressing to route service invocations to the appropriate provider. This is somewhat simplistic and I find that the pointed comments about “integration-centric techies” is a bit hyperbolic, especially since the ZapThink SOA Roadmap clearly shows an evolutionary progression starting from “static binding to static services” as the first phase along the ZapThink road to SOA. But everyone is entitled to change their mind, and leaving that aside I agree that strong decoupling of consumers and providers is important for a mature SOA. Some of these concepts have been discussed by others in terms of “Service Virtualization.”

Change is a continuing and important challenge for an SOA and the solution is “in your architecture” rather than something that can be bought off the shelf. Consider these sources of change that we must deal with every day:

• Hardware failure in either our service implementation, or network connectivity – the need to support fault-tolerance or high availability.
• The need to load-balance service invocations across a number of different but redundant providers
• Changes in the underlying applications supporting the service provider – e.g. package version upgrades
• Changes in the location of a service provider – e.g. in a disaster recovery situation, or planned migration from one facility to another.
• Migration of service implementations – e.g. migration from a legacy application to a new platform.
• Functional changes to service provider to support new business requirements
• The need to support multiple service versions to allow phased migration of consumers from one service version to another.
• The need to phase out old services which do not provide sufficient ROI.

The challenge is that all of these changes happen on different timescales. Some changes occur on sub-second timescales (fail-over and load-balancing) while other changes can occur over months (system migrations). There is no single indirection technique that will span all these requirements.

Related posts:

1. Service Providers and One-Way MEPs
2. The benefits of an ESB
3. What is an ESB and why do I need one?

This is a pertinent question because there is still a communications gap between the “business” and “IT” in many (especially large) organizations and as a result SOA initiatives are often driven from the IT side of the fence with little support or even understanding from the business.

There is a fundamental “chicken and egg” problem with SOA. It won’t gain support from the business unless a business case can be made…but conversely SOA payoffs are elusive without business support. Faced with this situation, many IT architects who want to develop an SOA approach are forced to try to conjure the egg out of thin air and hope that a chicken will hatch. The danger with this approach is that rather than gain an SOA you may end up with just a bunch of web services.

Two key facilities that an SOA initiative needs are leverage and vantage. Vantage to see where you need to go, and leverage to push the organization in that direction.

SOA is all about providing services to support the processes of the business – typically across organizational silos. There is a need to understand all the processes and their requirements – now and for the future. This visibility needs a vantage point “above the fray”. A point from where you can see the processes in their entirety. Without this vantage point you risk building the wrong services, or building services for the wrong processes or not anticipating future process changes. Moreover this vantage point must be experienced from the point of view
of the business – not just IT. So the question for an SOA initiative is “who in your organization has this vantage?” You may be lucky and have complete visibility from the IT cockpit, but that is rare. In general no one person has this vantage and it generally resides across different roles and people. Hence the need for some governance process to capture that vantage into a SOA plan.

So let’s suppose you have this vantage and want to execute on an SOA initiative. SOA is primarily about sharing – shared services built on shared resources using shared standards. Without sharing you wont get the SOA pay-off. But sharing requires communication and cooperation. Leverage is required to reconcile conflicting priorities in terms of requirements, schedule, funding, and resources. There may be some organizations where all these conflicts can be reconciled within the IT department, but I haven’t seen any yet. Typically resolution is required at an organizational level above the participants – that is the prime purpose of organizational hirearchy. Hence you need the appropriate leverage to get everyone moving down the SOA path.

While the type of issues your SOA initiative will face are fairly general, the specific issues and their resolution will be germane to your organization. This means that the place you will achieve the right level of vantage and leverage will be different for your organization. You might be lucky enough to work in an IT department that has the appropriate leverage and vantage, but that is rare. More likely you will have to go higher up to get these facilities for a successful SOA. This is the essence of the “top-down” approach to SOA.

I guess the “middle-out” approach might be characterised by “figure out how much leverage and vantage you have access to an scope your initiative from there.”

Related posts:

1. SOA Metrics for Continuous Improvement
2. The SOA Governance thing…
3. SOA Metrics, Projects and Organizations

At design time, what is needed is a shared understanding of the architecture principles, frameworks, standards and best practices used within your organisation for providing and consuming Services.

How do you ensure that this shared understanding is
a) communicated effectively,
b) understood and
c) implemented by all.

This goes way beyond technology solutions and encompasses the overall development culture. Tools can help – but they should be an enabling framework rather than an enforcing roadblock.

Update: Todd Biske has recently also blogged about the relationship between governance, tools and culture (here and here).

Related posts:

1. Martin Fowler on Humane Registry
2. Leverage and Vantage
3. SOA Metrics for Continuous Improvement