SOA method melee

Much of the talk about SOA revolves around undelivered promises or companies reticent to commit. Here I present a way of working that allows a layered approach for those who need to at least assess the risk that may lay ahead. One of the greatest challenges that faces SOA adoption is what to do first; A recent report suggested that the majority of companies that thought about SOA adoption simply weren’t moving yet just because they want to watch the market. This is largely because with the best will in the world people don’t know what to look for, we hear about bottom-up, top-down, WS-*, registries and so on and so forth. In actual fact SOA itself does not have a formal definition, it’s interesting asking different people what they think often each assumption has a valid counter. The more complex SOA projects are often strategic, pan enterprise and involve issues of Geography and time. The only way to begin that SOA process is to get enough information at the top level to convince your CIO to invest and to do that you need enough understanding of each prospective part even at a high level.

This brings us to how you go about the process, what method do we use? This is usually when the wars begin! I have found from experience (not just in SOA – but going right back to CASE days) that one always to pull bits from different methods and make them work for you. A common mistake is to underestimate complexity with any size integration problem as that is all SOA really is – integration and maybe control processes over that. Most development methods where meant for a single project or at least for where you have the same level of control of all aspects of the development. The first point that I always encounter is lack of a common meaning or even agreement on meaning of terms, the truth is you need to begin with a taxonomy at the same time as you start to define services which is often people’s starting point or service discovery. This is totally compliant with Design by Contract.

Often when left to a bottom up approach this facet is missing and often discovered too late. This stage is your metamodel and it can be done incrementally. I does not have to be full blown MOF comliant design but it pays in spades to have a common description of terms. I like to do this step in an agile way informally identifying legacy systems to wrap or new services using the Zachman Framework iteratively (going down in layers through design iterations) as this is an excellent communication tool when it comes to reporting your initial findings back to the stakeholders. It’s important to have four things beginning at this point, as mentioned your early service discovery, your metamodel description (so each system can agree on types or how to transform them), developing a CIM with the business analysts and most importantly your error conditions. At this stage it’s vital to identify your exception conditions as asynchronous interconnects and transactions do not work like their synchronous relatives. One needs to design skeletal compensation statements right at the beginning. Let me give you an example, I recently designed a system that controlled a number of physical devices some of which may respond with an error condition hours or even days later therefore a classic rollback is out of the question so a set of cleanup or compensation actions has to be set up. All of this can often be done quite quickly over a few iterations and presented in a container this is a useful and simple container for the rest of the lifecycle although you may wish to choose a deeper method later, for example I would happily use an XP process to define the initial services which are held in and communicated through Zachman, then within each service moving into some MDA techniques such as defining a PIM and feed this iteratively into your effort to get the meta model off the ground (MOF), so within Zachman you can define what, where, how, who, when, why iteratively through layers of abstraction/detail with a common vocabulary so out of this comes your highest level service definitions using a common typing system, but that’s the easy bit because two important aspects can be added at this time your SLA definitions and your compensation procedures for asynchronous error conditions, and then later your KPI’s. So from a few simple iterations you have a framework that you can apply level by level per iteration to identify services, semantic types, SLA’s and error handling. So the next iteration might define a security model for example. It can be seen that I have only taken those parts of various methods to suit the deliverable at hand, one needs to be able to treat an integration project this way i.e. with agility because many aspects of your system can and will change in time. This is one of SOA’s promises – agility and this will not happen unless one can deliver in an agile way.

 

So where is RUP or Agile method X?  You will notice that the above draws on using EA and MDA techniques, the downside is there may be a learning curve for some but most EA/EAI will cope some care needs to be exerted as it doesn’t follow any method process flow. This is largely because this doesn’t exist for SOA and it doesn’t exist because every part or subsystem can be entirely different thus most methods don’t fit the distributed nature a large SOA because as previously stated they were designed for single projects but there is certainly a place for these methods per service definition, and indeed different sub systems may require different methods – it all depends.

 

Depends on what? Governance. This is the ability to control any aspect of the system, it’s design, it’s deployment, manage it when it’s up and running, upgrades – everything. Large SOA projects are nearly always never centrally controlled but this has to be your aim, in short the project will fail at worst or at best be compromised if this is not the case. Governance is the key, establish this at the outset and constantly work on it.

 

This brings us to tool support, this the area, not surprisingly that is most lacking there are many tools one might need from packet sniffers to workflow authoring tools

 

Looking forward to this coming year much talk is about cloud computing and virtualization, whilst these are interesting subjects they are more of a deployment and runtime governance issues and don’t really effect (too much) your design time choices