Tuesday, December 1, 2009

Some thoughts on service naming / service capability naming conventions (1/2)

A topic which has had a lot of discussions in the past and will still have a lot of discussions and disagreements for a long time to come, is service naming / service capability naming.

Recently I got another trigger on this topic: imho service naming which does not reflect the purpose of a service properly. A lot can be said about service naming and there are almost as many opinions to the subject as there are people interested in the subject.

This post tries to describe my personal humble opinion on service naming. You can agree or disagree and I'm willing to hear your comments, just leave me a comment and I'll be glad to take your input into this article.

Service naming is a very important subject for any SOA. Any self-respecting SOA architect has/uses a SOA reference architecture with service naming guidelines in it as it directly contributes to one of the most misunderstood but very important SOA design concepts: service (capability) discoverability. In the past, discoverability had lost a lot of its charms for architects and designers as the intended purpose (runtime) discoverability as a goal was never really reached in the way it was intended when initially conceived. Instead, nowadays, design time discoverability is becoming more and more important and service naming is one of the key concepts for defining discoverable services. If the service name does not properly match the scope and purpose (the core logic implemented by the service), discoverability becomes inherently more complex. If your service name is chosen wisely, the service sells itself better (real life example: if a hotel is not properly/oddly/ambiguously named, you will probably skip it when you are browsing the hotel directory for a place to sleep, especially if the hotel is called "amour toujours").

In this post we will use the following structure and definitions when referring to services:

service::capability where:
service - represents the unit of service logic to which the SOA concepts 'have been applied to a meaningful extent' as per Erl's definition :).
capability - represents the operation(s) which can be performed by the service.

Some examples of bad service names are service names which are
- scope and context issue: Inventory (what is the scope of "Inventory"? Just managing inventory levels? Or inventory locations, both, something else?)

- core logic: ::update (what does it update? even if we know the definition of the service itself, what is the service context in which updates happen here?)

- ambiguous naming: OrderManagement::execute (what is it that the order management service is actually executing? Ie. execute order fulfillment or ordering?)

How can we deal with this problem? How do we prevent these problems from being created in the first place?

One answer to this question (besides "governance"), is to define naming rules and conventions  (which must then be appropriately governed). Before starting  the actual discussion, we need to understand that different kinds of services exist and they are meant to perform different types of logic. I will use the "Erl" definition here which distinguishes between Entity Services, Task Services and Utility Services. More service models can be created but I have intentionally stuck tot he basics. Roughly, you can take these assumptions for this post:
- Entity service: performs their capabilities on business entities like Customer, Invoice, Order etcetera.
- Utility services are services for 'shared system logic' or cross-cutting technology services like logging, notification etc. They help the system to be operable while separating concerns like notification out of the other service types.
- Task services perform operations triggered by and executed in a certain (business) process - hence they contain business (process) logic.

Below you can find some suggestions to setup such a guide for designers to follow. I'm happy to receive any feedback on these.

As said, whether it be services, or service capabilities, apply naming standards. Don't do it for one and not for the other as it is useful for both.

Service Names should place the service capabilities in the appropriate context and define the service scope wisely. Knowing this is not a smart statement, I can say that this is up to you. Service names should be assigned differently, depending on service type (Erl definition of service types):
  • Entity services - use the [entity name] service naming like Order, Invoice etc.
  • Task services - use the [process name] service naming like OrderManagement, Collections Management, Credit Management etcetera. It's perfectly fine to sub-categorize if necessary, like in this example: OrderFulfillment instead of Order Management.
  • Utility services - use the [verb-or-noun] service naming like Notification, Logging etc.

Regarding service capability naming, apply the following pattern:
The verb is used to indicate what happens to the noun.
The noun is used to indicate, to what the verb is applied.
The (optional) subject allows for distinguishing between different logical subjects which may be meaningful to use for certain nouns).
Sometimes, this paradigm seems insufficient, ie. in case of notifications - see proposals below. Try to find a pattern which suits your needs.

Examples are:
- readOrder
- readOrderHeader
- readOrderLines
- updateOrderCustomer
- updateOrderPricing
- updateOrder
- notifyOrderUpdate or sendOrderUpdateNotification
- receiveOrderUpdateNotification

Note that when we expect readOrder to return an entire order structure, updateOrder expects to update an entire order datastructure. I would be concerned if these would be the only two operations I could perform on an order, referring to the service granularity concern: these would cause issues in that area: an updateOrder service would probably be much to big to be useful from a true SOA design principles point of view, but feel free to discover this yourself. Let me make the following statement: if you only need to update the shipping address on an order, and for you to do that, you had to read the entire order, change the applicable order parts and then save the entire order, you are most likely heading down the wrong path regarding service granularity. Continuous evaluating and re-evaluating the granularity of services and service capabilities is a constant factor anyway as the only constant factor we value is "change" ;)

Whether the service capability name may repeat (part of) the service name remains a debate on itself. An example of this is OrderManagement::updateOrderShippingAddress. Typically, the service name implies the context for the capability, making it useless to repeat the service name in the capability name. Applying this to the example would result in the OrderManagement::updateShippingAddress name.

For entity services, I can give one additional advice: try to use standardized (predictable) names, purposely chosen to make it easier for designers to define them for any other entity service. A suggestion for entity services would be: create, read, update, delete (aka. CRUD).
Following this kind of an approach reduces the number of discussions you will have on service naming. In fact, apply this predictable naming concept to all service types whenever possible, by establishing a standard vocabulary. Especially the verb naming requires some extra attention as there are many ways to explain similar behaviour using different verb names. If the intended behaviour is the same, then use the same name. Do not use aliases for the standard verb names unless it removes ambiguity if the standard verb name is used.

Examples of predictable verb names in a vocabulary are:
Get - retrieves data
Retrieve - same as get but discouraged: name too long which makes it hard to read service capability names.
Notify - creates a notification
Create - creates something (and in case of entity service, may store records in a database)
Update - updates something synchronously
Post - updates something a-synchronously as in fire-forget mode

A service capability name must describe what the core service logic does, not what the consumer does. Recently I have been involved in a discussion on service naming. Suppose we have a service exposing events about changes in a customer database object the Entity Service's service and capability names would be similar to CustomerService::postChangeNotification. This service name indicates that it is related to Customers; the service capability name indicates that it is sending notifications about changes on the service's underlying distinct functional scope: the customer objects. The replication service capability consuming these events would probably be named something like OfflineCustomerPortalCacheReplicationService::processCustomerChangeEvent. (Please don't flame me for insanely long names). The service name is referring to an underlying object "offline customer cache" and also the service is responsible for replication ( this would most likely be a utility service). The service capability name indicates that it processes the events fired by changes on the customer object (as generated by the CustomerService), in the context of the replication service for a certain offline customer cache for the portal (this example could be the implementation of a forward cache pattern).

Last advice: please remember not to try defining services and service names in splendid isolation! Get other people's opinions and make sure that you all (well, most of the lot anyway) agree to avoid different naming by different project members even if they are in the same team! This obviously also applies to other architecure and design activities you and your team members do.  Perhaps it's a good idea to setup the naming guidelines together. The discussion around service capability naming will probably never go away, but at least you will apply the same set of concepts and rules to service naming and service capability naming. In the end, life will be easier I hope.

Sunday, November 22, 2009

Let's expose everything the backend provides!

Something I hear many times in my profession is when a customer is conservative on spending money but wants as much value as possible. Attitude sounds ok, right? Well here's an example when this does not work.

The problem:
The budget is limited, the back end has huge interfaces and I need only a fraction of that. My sponsor must be convinced that now is the time to expose more.

Case study:

  • The desired service is "Change Name&Address Details". This is the actual requirement (I know, not SMART but for this example it will do just fine) 
  • The back end system exposes a "UpdateCustomerProfile" service which allows changing Name, Address, Privacy settings, Credit Status, Collection Path and collection status and a whole bunch more... 
The team starts analyzing and finds that actually, the data this back end allows to change is from different logical/functional domains; the CM, Billing, Credit, Collections etc. domains. They discuss with the project sponsor that a number of these services are actually very useful and it's perhaps wise to expose more than just the changeNameAddress capability.

When further designing the services, they find that a whole bunch of services and even more capabilities can be exposed on this back end service UpdateCustomerProfile. When they discuss their findings with the sponsor, he actually dictates that instead of exposing the proposed 10+ granular capabilities, he says I will grant you the luxury of exposing extra functionality as I see the benefit, so you get some extra money however, you must expose it as a single 1:1 service and let the consumer decide which functionality to use. This should also increase the reusability of the service so it's a sure win-win situation and I get more value for money. Let's call this service "ChangeCustomerProfile".

Done deal, right? Why is this a problem? Everyone's happy, everyone gets what they want.

Let's see why this is not the right approach:
  • By exposing all the nitty-gritty back end interface details 1:1 they actually kill the decoupled contract pattern used in SOA. The service consumer must now (because of the bottom-up approach) know how the back end system works in order to effectively use the interface on the middleware. Actually, it is as if the middleware did not exist. With or without the middleware, no difference in controlling the back-end. Where the gain?
  • As you can see from the new service's name "ChangeCustomerProfile" it was hard to find a name which makes it intuitive for the service consumer to derive from the service name what the service does. The designer of the consumer of this service must now read extensive documentation and carefully decide how to use it in order to avoid invalidating data or breaking data consistency. Hmmm... I always thought that, when it comes to consuming SOA services, the understanding of the system would be better; but nothing changed. One of my next posts will be on service naming. Stay tuned for that one.
  • By exposing this extremely large interface to the service consumers (very 'reusable' right? So many consumers), in case something must change the interface, chances are, we have to update many consumers to make sure they all keep working with this service capability. For the people who are now arguing that you don't need to change all the consumers, let's see: you are partially right. But the cost of a system is not just determined by the service delivery effort; there's also something called operation & maintenance. Every operational old version of a service interface, increases your operation and maintenance cost. This is what is referred to as your "IT Burden", which in fact kills part of your SOA strategic goal to reduce the IT burden. So you loose either way:  either because next change on your interface triggers many service consumer changes, or because the number of versions of this interface explodes, making operations hard.
We were just forced to ignore many of the SOA design principles:
  1. Standardized service contracts: We did not do this at all. Instead of designing interface-first, we created the interface from the back-end exposed interface. This bottom-up approach results in tight coupling between consumer and service provider.
  2. Service loose coupling:  This bottom-up approach, which is also reached when ie. using interface generation tools like java2wsdl, results in tight coupling between consumer and service provider. We may have a decoupled interface from technology and transport point of view, we definitely did not gain loose coupling from exposed back end services.
  3. Service Abstraction: Instead of exposing capabilities abstracted from the back end, we exposed the back end interface 1:1: no abstraction at all on capability level.
  4. Service Reusability: This is the one we unintentionally failed despite the sponsors' "efforts". A service is a true candidate for reusability when many of the SOA design principles are applied properly, including #1, #2, #3, #7 (not a guarantee that reuse is reached, but at least the potential for reuse).
  5. Service Autonomy: because we exposed a too generic interface "can-do-all", we unfortunately disallowed future designers to only use parts of the system which are necessary. Instead, they need to hit that same huge service 'capability' in many situations. By doing this, the autonomy of the service decreases.
  6. Service Statelessness: Because this service can-do all, chances are there that a lot of state must be passed back and forth. Although the service on itself may be stateless, the knowledge of the back end's data is large on client side. Usually statelessness is a significant driver for the amount of scalability which can be obtained, but so is passing around a lot of data.Worst case, the client must read ALL data the service exposes, to be able to modify and update the back end data.
  7. Service Composability: Composability is low in this example, in general. The service fails most of the design principles, resulting in low composability.
  8. Service Discoverability: There is virtually none. The service name nor documentation could give distinguishable content to make it easy to find the appropriate service for the appropriate capability. What can I do with the customer? What is this 'profile'. Is it a form of aggregated data which allows deriving customer value? Is it something related to his visual appearance? What is this thing we're exposing???
    How did this cause us to fail most of the 7 strategic goals of SOA:
    1. Increased intrinsic interoperability: failed because the technical back end interface was exposed directly to the service consumers. Gone agnostic services. Gone interoperability as composing services can only be done with exhaustive reading and figuring out how this stuff actually works: in fact, instead of making it easy to use this service in other service compositions, you remain on the good ol' integration effort path and will have gained anything in the domain of this goal.
    2. Increased federation: there is no increased federation. Everything remained as before. Your middleware exposes what your back end provides, no chance of improving federation.
    3. Increased business and technology alignment: Sort of... on one side, the business is involved during the design process. But next time this service is available and then it remains questionable whether the business is consulted. Benefit of the doubt though I tend to think 'no'.
    4. Increased vendor diversification options: Actually, no, you are just locked in more to this vendor as now, not just the consumers, but also the middleware is tightly interlocked with the vendor's interfaces.
    5. Increased Return on Investment: Your initial investment: yes, you get a lot of service (which is not used right away) for your money. But the cost of next changes or the cost of operation will increase and must be included in the ROI calculations as well. So less ROI than expected. The issues typically arise after several years when the environment becomes unmanageable. Since ROI is impacted by the first four strategic goals which we gracefully failed, don't expect anything here.
    6. Increased organisational agility: We did not help the organisation wrt agility by building this service. In fact, by having yet another IT 'asset' exposing more of the same, in exactly the same way hardly helps improving in this area.
    7. Reduced IT burden: We failed the first six goals, so what do we get on this one? Right, nothing at all. Probably what we did made managing the solution harder, so your IT burden increases instead of reaching the intended decrease.

      Saturday, November 14, 2009

      Common causes of SOA failure

      A number of common misconceptions will make most SOA initiatives fail, hard to survive or not start at all. This post is not complete, and may be updated many times, depending on the feedback I get from you, the users. If you feel a cause is missing, drop a comment including your issue, cause and resolution. Don't forget to mention your name and contact details.

      • SOA is a silver bullet
      • Failure to implement proper governance
      • Failure to get management buy-in
      • SOA "the enterprise"
      • Specific vendor has the best SOA implementation
      • SOA quickly brings ROI
      • We are doing web services, so we are doing SOA

      SOA is a silver bullet

      Issue: SOA is not a tool but an architectural approach. Implementing a tool does not implement the SOA concepts into the business and technology.

      Cause: Vendors explain their SOA tools to be the silver bullet.

      Resolution: There is none. SOA is a mindset supported by tools; as long as you are aware about that, and live up to those concepts and patterns, you may be fine.

      Failure to implement proper governance

      Issue: Failure to consider/facilitate the governance burden in a project will increase the governance burden after the project, if not make it virtually impossible.

      Cause: Implementing a SOA in a project instead of a programme may easily let the project slip into the tactical approach instead of the strategical approach.

      Resolution: Setup some governance requirements prior to starting your first business project. Having these can force the project to include governance in the project, making sure the deliverables are not left 'floating' in the organization after project delivery.

      Failure to get management buy-in

      Issue: We, the IT department got this SOA installed, but no-one is willing to invest the extra money required with the implementation of SOA services. Every project is going for the quick and dirty approach, continuing as they were...

      Cause: No management buy-in, resulting in lack of appropriate governance.

      Resolution: Evangelize! Convince the senior management staff that the SOA thing they bought is really a good thing, resulting in long-term benefits, the traditional way of working will not provide. Result of management buy-in can be that the appropriate governance is implemented and a SOA way of working is enforced. Explain the same situation to everyone who's willing to hear your story.

      SOA "The enterprise"

      Issue: Companies try to change the entire enterprise at once. This is a definite recipe for failure. No single company can change all their IT systems, business processes, governance etc. in one go.

      Cause: This is a common misconception: Implementing a SOA involves people from the entire enterprise when the business analysis and service modeling project phases take place. This means people from the entire enterprise, multiple disciplinces. This does NOT mean that we need to involve EVERYONE and ALL systems.

      Resolution: To start very small: select specific business processes to change. Implement SOA services using the SOA approach which show a clear business value and can demonstrate that SOA can work. Typically management only chooses a technology if the proof is there. Maybe even demonstrate a few quick wins. Even then, SOA is a strategical approach so don't expect miracles.

      Specific vendor has the best SOA implementation

      Issue: Comparing vendors' SOA products based on their marketing and their product specifications gave me this best of breed product, but it's not doing what I want. It's not possible to 'get the best SOA products out there'.

      Cause: A lot of vendors deliver their SOA product with a lot of promises and marketing terminology. Sometimes it's even not true that certain vendors claim delivering SOA tools because people mistakenly assume 'web services' being 'services'. Also it's hard to do a product selection without requirements. It is similar to the 'get me the best car out there' discussion. If you don't tell your requirements you may end up with a Ferrari on an offroad track.

      Resolution: Define your company's requirements, define a strategy and then compare products with your requirements.

      SOA quickly brings ROI

      Issue: If I buy this SOA thing, I will quickly get a better ROI.

      Cause: Not understanding the strategical nature of a SOA.

      Resolution: Increased ROI, Better technology/organizational alignment are prerequisites for a reduced IT burden. All of these are indirectly obtainable SOA characteristics, depending on a number of other SOA concepts. This illustrates the strategical nature of the SOA approach.

      We are doing web services, so we are doing SOA

      Issue: Web services and SOA service terminology is mistakenly assumed "the same thing"

      Cause: Web services provide a standard technology for the service contract. Web services don't force the user into following SOA concepts and patterns delivered by the SOA approach, resulting in "SOA Services"

      Resolution: This needs a proper implementation of accurate terminology in people's minds. Once this is reached, a common understanding of the difference between a web service as technology and service as concept is reached and the mistake will not be made again. This may very well be one of the hardest things to achieve (my definition of service is better than yours, your definition of service does not deliver anything concrete etcetera).

      Thursday, November 5, 2009

      How does SOA fit in today's and tomorrow's distributed architecture

      This post describes briefly how SOA fits into current distributed computing architectures. Its purpose is not to give a full detailed positioning but is merely intended as a primer.

      silo - integration - soa - grid - cloud

      Traditionally, companies would implement "silo" based applications or application silos. By nature, these software stacks integrate poorly with other solutions because they are self-providing. Vendors selling these systems are not interested in opening up their systems as it allows their installed (functional) base to be reduced by other vendor's products with similar functionality. This makes it hard to make these systems work together with other systems. Mostly, the customers of these systems need to pay prime rates to have them opened up for their intended purposes, and the vendors will gladly charge another customer money to get the same or a similar interface implemented.

      Making these systems work together is called "integration". Integrating systems is bespoke work per definition. It is considered expensive as it is custom work for every new integration. An integration effort is considered a tactical approach. Also, integration is based on a typical point-to-point approach which must be prevented to prevent IT burden from skyrocketing. The more interfaces are built between systems, the more chaotic are changes to be implemented and the more unpredictable the cost of change becomes.

      This is where "SOA" comes into the picture. SOA tries to change this cluttered 'spaghetti architecture' into a more organized 'lasagna architecture' if you will. Why lasagna? Because a layered approach helps improving the predictability of your IT systems. Ever tried to take out a piece of spaghetti from your plate? You never know what comes with that small piece... With lasagna, you can take out a neat square (read: structured) piece and work from there. If you would read these neat pieces as services or service capabilities, it becomes apparent that the predictability of cost and impact of changes is increased, compared to spaghetti architectures. Yes, I hear you thinking, "I can do that with 'integration' as well" and you are probably right. The difference between integration and a service oriented architecture approach is mainly based on the approach SOA takes. SOA is based upon services with intrinsic interoperability which would be built to fulfill a specific business purpose. Furthermore they are intended to be reused/reconfigured aka (re)composed, and integration efforts are because of their custom efforts not easily or not at all reusable. To improve recomposability, SOA services should preferably not hold state, as holding state makes use of a SOA service limited to certain interaction patterns (their functionality depends on prior calls to the services or service compositions); without it, the intended business purpose cannot be fulfilled. Because a SOA service fairly easy (all in the eye of the beholder) can be used for other purposes in other service compositions, the SOA architecture approach is considered a strategical approach. For more SOA concepts I can recommend this book.

      A problem of traditional SOA architectures is that they are really good at processing large volumes of small messages, but they lack the make-up for handling large messages. Many SOA architectures are based on a message based infrastructure. This means that messages are to be read into memory and streamed on the network many times in order to execute the business goals. These are by nature expensive resources as they eat away at network bandwidth, memory and potentially disk I/O. In a SOA "grid", services are allowed to have state and state is available (shared) across a certain infrastructure which reduces the number of times reading into memory and flushing from memory to network and/or disk. Fundamentally, a SOA grid is a special kind of SOA architecture which works around some of its challenges. It makes the SOA architecture more efficient with respect to large messages. Also a grid architecture has improved availability and fault tolerance because of its make-up.

      A "cloud" architecture virtualizes resources like storage, memory, cpu, complete machine, java virtual machine etc. Basically, a cloud consists of containers with specific characteristics to meet a certain goal. For example you can have a database in the cloud, not knowing where it's hosted and you typically don't need to worry about it. It has a different cost model (ie. x cents per effective capacity unit per effective time unit) and you do not have to worry about hosting services. This also introduces other issues, like where is my customer data stored. Many countries legislation does not allow storing sensitive data outside the country, or in case of the EU, outside the EU. This poses different challenges. Advantage is however that you don't invest or plan a huge local SOA based infrastructure, but utilize (multiple) shared but isolated virtual infrastructure(s) to host your environment. You typically pay for what you actually use. And the environment is easily scalable as the resources are virtualized and would allow (on the fly) configuration changes (ie. assign more CPU or disk capacity). It is extremely simple to scale both vertically as well as horizontally. A step further in the cloud, is software, platform or application as a service, this is where provides will provide ie. a complete application environment as a service, resulting in a cloud of infrastructure, resources, platforms etc.

      Another nice detail is that, if the concept of a SOA based approach did not exist, the paradigms and services required for a SOA grid and a cloud would be way less flexible than present. Potentially, the SOA grid and cloud would not even exist in it's current form.

      Another (more traditional) application of grid computing / grid architecture (notice the difference in terminology: not "SOA Grid") is where a giant task is  split into smaller tasks and split across multiple systems which bite on smaller chunks of the huge data load. Very big companies would use supercomputers to do this before the idea of grid computing came along. The issue was that these computers would cost insane amounts of money and they could only be put to use on one task at a time if maximum system capacity should be available. In a grid computing environment, the computing units run on standalone computers which can be configured into groups of computing units each specializing in a different task. Because commodity hardware can be used instead of supercomputers, the cost per calculation will be significantly lower. Some initiatives have gone a step further at this and utilized public computers (individual user's computers) to increase the computing power to the greatest extent. Examples are the SETI initiative, or medical companies calculating the must effective treatment for a certain disease of virus. Funny detail is that complete public communities have formed competing to process the most parts of a giant problem - they have turned this into a competition much to the benefit of the companies putting up the calculations for work. If you would like to see such competition, view this score board.

      Friday, October 30, 2009

      SOA Architect workshops

      This week I followed the SOA Architect workshops and had hoped to see Thomas Erl in action. Unfortunately he had become ill -get well soon- and asked a Toufic Boubez and Paul Buhler to help out. Boy do these dudes rock! Both are highly skilled people with a lot of field knowledge. Unbelievable how these two guys can convey the subject - and with a lot of humor as well. I almost believe that they themselves had much fun doing it ;). Both have many examples from the field and do not hesitate to put the group to work and challenge them. Not afraid to ask for more than one solution, depending on point of view or subtle case changes which have lots of impact on the proposed solution options. Also shared lots of extra insights. The participants had a lot of dialog and in-between sessions, a lot of knowledge was shared. Also expanded my network a bit.

      Great class I can recommend to people who want to get trained properly. Speed is high and I feel that one needs at least some prior knowledge and perhaps some years experience in integration and even better in SOA. And at last workshops/trainings which are vendor agnostic! The kind of workshops out there which are called training are typically vendor marketing channels. But not this one! Really, if you wish good vendor agnostic training, try the SOA training provided by SOA Systems (SOASchool.com). I am planning the followup training for SOA Security and can't wait for the SOA Governance modules. It's a pity it's a bit hard to get this kind of quality training in Europe but they are working on availability for these workshops!

      Also I made some new friends in Gemany, Oslo and Belgium. Hope to get another coffee when we meet again. We found this great place for coffee and bagels near the WTC called mockamore. Anytime pals, anytime! The place was a bit small but for a coffee to go it was great. Friendly staff and good coffee; fresh bagels, good products. Coffee's a bit expensive though.

      Friday, October 23, 2009

      2nd International SOA Symposium October 22nd/23rd 2009

      This week I attended the 2nd international SOA Symposium in Rotterdam, NL.
      Great to meet all the great minds of the current SOA era. I was happy to personally meet Paul Brown, Tufic Boubez, David Chappell and Thomas Erl. Finally got a chance to get my SOA Books signed (thanks Thomas!).

      Anyway, I wanted to share with you what I saw there.

      1. A lot of vendors... Personally, I think SOA should be vendor agnostic and all these vendors were as always trying to push why their product is better than the competition's based on extra features which lock you in into their tooling :(
      2. Remarkably low floor presence of all these good people for whom I had attended the event for. They were all in the SOA manifesto sessions. I was there but could not meet! If you wish to take a look btw, you can check out the SOA Manifesto here. I agree with their statements and one of my next posts will elaborate on why I think they are right. Unfortunately them being in these sessions did not allow me to speak with them more than a few words...
      3. I think the quality/level of some speakers was well below expectations (yes it could still be me) but if a session is not interesting I will walk out to get more elsewhere. I walked out on a number of occasions. Hopefully others did not have similar experiences.
      4. Great presentations by Paul Brown "The Critical Role of Architects in an Enterprise SOA", Thomas Erl/Anne Thomas Manes "Exorcising the Evil SOA: A Necessary Step Towards Next Generation SOA" (you should have seen the "Evil SOA!") and Steve Pope "SOA Governance and Management Practices".
      5. Great architecture in the World Trade Center Rotterdam! I'm sure the photographers got some great shots.

      Great espresso bar!

      Tuesday, October 20, 2009

      SOA is not a disease!

      So... I finally gave in... Soooo many times I have thought about what I could do with my experience and ideas related to clarifying what SOA is all about. Yes I hear you! I'm nr. 10 billion who writes about SOA and probably there will be another five before the next hype comes along! And you are probably right. Just bear with me and give it a chance - and btw thank you for being one of the five people reading this blog!

      So here I am, in the field since 1995 and many years experience with SOA and distributed computing in general. After graduating I started working at a large consumer electronics firm, writing prototype software (user interfaces) for televisions and set-top boxes. This was mainly of the demo nature and the only true production-ready SW I ever wrote for that company was embedded software implementation for a set-top box. This was challenging as the platform had many constraints and performance was all that mattered. These restrictions got to me and I moved to another company. I still remember when I wrote my first service broker based component based distributed system for my new employer, a large telco in the Netherlands. I've tried MS's COM/DCOM/MSMQ/MTS server based software and was amazed with the openness and flexibility this gave me. Nowadays we would know the concepts applied back then as service broker, asynchronous queuing, distributed transactions, durable subscribers etcetera. Little did I know :). Later I continued on the J(2)EE platform which was much more stable and required hardly any workarounds. I integrated a lot of systems and even dipped into the web-pool shortly while (co)writing two web portals intended to merge information management, workflow and sales tooling for this telco. We used BEA and JBOSS (now oracle and redhat) tooling. Around 2002 some people were talking about SOA and I looked into it - it looked promising. At the time I considered SOA a been-there-done-that exercise. Well, guess what - we made some mistakes - expensive ones. Very expensive ones! Not just technology and architecture, but mainly governance and organisational mistakes.

      Anyway, this brings me to the title of this blog. Where I'm from, The Netherlands, the acronym means something entirely different - in English you will all know the term STD and that's what SOA means in Dutch: Sexually Transmittable Disease. Today, many companies have turned their back towards SOA and indeed treat it as a disease. Because it did not deliver what it promised, or because they purchased a tool and figured it would change their luck and would reduce their investment. Well, WAKE UP! Nothing is less true. SOA will not bring return on investment, and will probably make matters worse if nothing else changes in the enterprise. Great, you think, I just invested tons into this new tool and hardware, and now you tell me it was a mistake. You tell me I will spend much more. Whoa... hold your horses. Indeed I am convinced that if nothing else changes, purchasing a "tool with a promise" will cost you. So, what else needs to change? In order to figure that out, we have to explore a number of concepts and patterns which will most likely change your mindset about SOA. And when it does, we are ready to talk about how the tools can help you leverage your architecture to bring reduced IT burden and consequently, a better return on investment.

      I won't be writing often as I simply don't have the time for it - yes I too tend to think I have a life. I will purposely pick topics to trigger discussion clarifying how SOA may or may not work, hoping that it may do the same for you.

      From this article I hope to convey one message: it's not something you can buy, it something that requires hard work and a lot of planning! Implementing a SOA is not something you do in a week-end. It is something that takes years. Any benefit you expect, don't expect it anytime soon. From my personal experience I think it would take 3-5 years before the SOA starts bringing structural benefits. If you think you need show return on investment results during this or in the next fiscal year, maybe SOA is just not your thing! That's what it is about: tactical versus strategic. And SOA definitely qualifies for the strategic approach.

      See you next time...