Matt Deacon's digestive blog : SOA

Unbundling the bank

Matt Deacon — Thu, 15 Mar 2007 17:05:00 GMT

“Technology is the primary business driver in the banking industry” or so Craig Heimark said during his session at QCon today, not that the business is really aware, all they see is the changes in the competitive landscape. However, as he argues this change is driven (although enabled might be a better word to use) by the massive growth of communications challenging and forcing a reconfiguration from centralised vertical models to decentralised models made up of single value specialists.

The consequence is to create increased value to the consumer at the expense of margins; the higher the volumes the lower the margin. This leads to mass customisation and the eventual unbundling of services driven by consumer demand.

Not dissimilar, IMHO, to the service revolutions that we are predicting across other verticals and a breath of fresh air after my experience talking about the Software and Services at the recent "Implementing SOA in the Banking industry" conference I attended last month where their view was consolidation at all costs.

However, Craig has left the bank and is now building technology that will aid this disruption ... so the innovator leaves the corporation buy more on the innovation squeeze in my next blog.

SaaS: For dummies

Matt Deacon — Sat, 17 Feb 2007 02:26:00 GMT

SaaS is a continually evolving mix of existing and emerging technologies and business models and as I have suggested seems to be best described in terms of the following six characteristics (although I am sure there are more).

SaaS, at best should be viewed as a metaphor for the state of software delivery at a particular point in time (ie. now). The significance is that now, network communication can almost be assumed to be a given; markets are no longer constrained and in fact are floating in a layer above that of the physical world; this is no longer a global market, as this suggests a change in location; the market is no pan-global; the markets are now in the cloud.

SaaS is a fad; it is a metaphor that encapsulates the evolving software landscape of today. It is only a matter of time before the term SaaS will fade away into obscurity and be replaced by the more familiar term: Software. Only this time round the term software will not mean the same as it does today.

It’s much like music; we are in a period similar to Punk; a relatively short period in time, but a significant period in musical history. The result of which has seen the explosion of an incredible array of new musical forms. Some good and some not so good. Ok so as long as we ignore the whole of the eighties, new romantics and more recently pop idol we're looking good for an analogy here!

Welcome to the future of software as we will know it.

3. SaaS: Location

Matt Deacon — Thu, 15 Feb 2007 17:27:00 GMT

In terms of location a SaaS Application is most readily associated with that of an internet hosted web application (and hence hosting may have been a better description in hindsight). However, in reality this only represents one of many location (hosting) models that are available including these described below:

· Remote; where the SaaS Application is hosted within the vendors IT environment and accessed by the consumer remotely.

· On-premise; where the SaaS application is hosted within the customers own IT environment and accessed locally.

· Appliance; where the vendor supplies hardware/software as a "black box" that is installed in the customer’s own IT environment, this can also include virtualized environments.

· Virtualised; a variant of the appliance model whereby the application may be hosted on the users desktop, but is isolated or virtualised using technologies such as that provided by Softgrid for example.

Several inhibitors to SaaS adoption, such as multi-tenancy, security and reliability are currently driving the evolution of some of these models. However, with the likes of application virtualisation it is conceivable that this will be an enabler in its own right for the myriad of applications that do not fit instantly into the classic internet hosted web application model.

2. SaaS: Licensing

Matt Deacon — Tue, 06 Feb 2007 05:31:00 GMT

One of the most defining characteristics of SaaS is probably that of licensing provided as a subscription-based model rather than the single up-front license fee sold for perpetual use as described by traditional software “products”.

This subscription model is most typically realised through a relatively simple time-based approach such as a monthly fee for example. However, in reality many SaaS providers quickly realise that there is a need to provide a far greater range of subscription models that may take on several combinations including:

· Time-based subscription models

· Usage-based transaction models

· Features / function models

· Allotted number of service transactions used

· Advertising funded revenue models

This situation is further compounded by the fact that the SaaS provider, in the early stages at least is only just starting to understand what their core services are let alone how they are going to charge for it; all this is against a backdrop of heavy investment in the development of the functional aspects of the SaaS application itself. Invariably early adopters therefore benefit from being able to negotiate terms on an individual basis and as a result one should expected that this will set an expectation that will drive the need for great flexibility in subscription models at least in the medium term as the SaaS licensing landscape evolves.

A good analogy in thinking about SaaS licensing, which may in fact prove to be more than just an analogy, is to think of the subscription models used by the mobile phone companies. The guys have taken subscription to an all new level; providing a myriad of different plans and options that typically stem from a base fixed fee with a range of extended features and options; the key driver being the massively competitive landscape of the mobile phone market. It will be interesting to see how SaaS licensing models develop. At present the SaaS market is emerging and still uncluttered but given its global nature one could imagine a dramatic surge in “copy cat services” that in order to differentiate themselves and drive competitive advantage will look to introduce more flexible pricing models much as has taken place with mobile phones.

1. SaaS: Application

Matt Deacon — Wed, 31 Jan 2007 20:08:00 GMT

Today a SaaS application is most readily recognised and associated with user interactive web applications accessed directly over the internet (eg. the web application). Already synonymous with the SaaS phenomena is the likes of the infamous Salesforce.com for example.

However, SaaS as a concept caters for the full spectrum of functional software and therefore encapsulates but is not limited to the likes of rich or smart client applications that are hosted on the client’s machine all the way through to connected atomic services such as those provided as XML Web Services whether they be based on SOAP, REST or just POX.

The fact that the range of a SaaS:Application is so broad automatically begs the question of why this is a SaaS characteristic at all. In my opinion it is important if only to dispel the common misconceptions that SaaS is all about online “web applications” alone. In fact the SaaS model is much broader and does not even necessarily dictate that a SaaS:Application is “connected” at all.

In summary a SaaS:Application can be thought of encompasses all Software that is delivered in the context of the other five characteristics of SaaS.

Six characteristics of SaaS

Matt Deacon — Wed, 31 Jan 2007 19:34:00 GMT

The world of IT doesn’t stand still and never has this been truer than it is today. SOA and related concepts are still riding strong on the wave but a new contender is starting to make its way through into the mainstream; this being the concept of Software as a Service (SaaS).

SaaS is a very nebulous term that really encapsulates a whole range of new and existing software delivery models often bundled together in different combinations in order to deliver a particular service or function to a particular consumer be that human or computer. It is a term that to me really describes a point in time, a transition in the way software is delivered and consumed, the ultimate enabler for which is down to the ubiquity of computer communication made possible as a result of the Internet, broadband and vast reduction in hardware costs.

For this reason, we shouldn’t get too stuck on crystallising a single definition for SaaS as it really represents a moving target and at some point we'll hopefully just revert back to using the good old word software once more. But for the moment, as we move through this transitional period there is definite value in highlighting the changes in software delivery that is crystallised in the acronym SaaS.

So with this in mind over the next few postings I plan to provide an overview of what in my opinion SaaS encapsulates today in terms of a set of six common characteristics that frequently re-occur when we see implementations of SaaS in the wild.

SaaS: Application

SaaS: Licensing

SaaS: Location

SaaS: Management

SaaS: Community

SaaS: Reach

As always feedback is welcomed and if there are additional characteristics then I would be interested in your opinions.

Names at Insight!

Matt Deacon — Tue, 30 Jan 2007 18:39:00 GMT

I'm very pleased with myself because after much effort by many people it's my pleasure to anounce that Jack Greenfield, the co-author of the now legendary "Software Factories" book will be providing the closing plenary at the Microsoft Architect Insight Conference on March 5-6 this year.

However, that not being enough I have got my good friend Ed Gibson (Chief Security Advisor at Microsoft) to thank for introducing my to the Right Honourable Lord of Erroll who will be providing the opening plenary. Lord Erroll is a Hereditary Peer in the House of Lords, sits on PITCOM (Parliamentary Information Technology Committee) and on the Science & Technology Select Committee’s sub-committee on Personal Internet Safety.

This adds great fuel to the emerging theme of the conference which will centre on the definition of the architect which we will drive out through a series of focus groups and clinics during the two days.

The event boasts over 60 speakers including:

Dr Ivar Jacobson - creator of the Rational Unified Process
Dr Alan Cameron Wills - Software Architect, VSTS Architect Team, Microsoft Corp
Andrea Westerinen - Software Architect, Dynamic Systems Foundation Group, Ms Corp

See you there!

Implementing SOA

Matt Deacon — Mon, 29 Jan 2007 14:09:00 GMT

I had the very great pleasure of chair a conference on Implementing SOA in the Banking Industry in Vienna last week as the European Regional Chair of the International Association of Software Architects (IASA). It was a truly excellent quality conference with great speakers from many of the large European banks. As chair I was able to give an overview of IASA and increase awareness of its aims - if ever there was a sector in need of an architectural profession then it is banking. During the day I made a mind map of the proceedings in order to provide some insightful comments in my closing remarks but this was to prove challenging.

In closing the proceedings I mentioned a couple of interesting thoughts regarding the map, firstly that version 1.0 had ended up resembling more of a spaghetti than a map (interesting anti-pattern analogy). With version 2.0 I divided the map into three main sections, drivers, benefits and challenges. Challenges far outweighed those of drivers or benefits which might make sense given the context of the conference, but the fact that I was still adding to this section at the same rate during the final speaker of the day as I had at the start was suggestive of the size of the challenges that face those deciding to embark on the SOA journey.

One key challenge that the map has drawn out and was evident from the majority of the speakers was the need for and importance of a consistent view of Architecture across the organisation. In many cases the investment in training architects has been considerable. For SOA to be successful the uptake needs to be pan-organisational and not confined to a being a project level tactic (see project anti-patterns) and clear consistent architecture provides a platform for this to manifest itself. However, not everyone can invest as heavily as these banks in providing this platform through internal guidance and training and so this brings me back to the work of the IASA. Pioneering work undertaken by these leading organisations will only be of true longevity and value if they are taken outside of these environments and shared on a global stage to develop the infrastructure to support a whole profession that through the benefits of scale these same institutions will be able to reap the rewards for many years to come.

Service Modelling Language Talk

Matt Deacon — Fri, 22 Sep 2006 11:26:17 GMT

If you're interested in hearing about the latest developments in the roadmap towards building self-managing dynamic systems then I've been invited to do a talk to the BCS SPA group about the new SML specification announced at the end of July.

Click here to register ....

http://bcs-spa.org/cgi-bin/view/SPA/ServiceModellingLanguage

Welcome to the World of ME!

Matt Deacon — Fri, 12 May 2006 00:30:00 GMT

The following diagram provides a view of the user significant business drivers that were identified during WAX. The power of 'ME' when measured in millions is an extremely significant force .... welcome to the "World of Me"!

WAX Workshop

Matt Deacon — Fri, 12 May 2006 00:27:00 GMT

On Tuesday I ran WAX; a Workshop to discuss the intersection of existing and emerging architectures including SOA, Web 2.0, SaaS etc. with 24 guys from a diverse set of backgrounds including Analysts, Vendors, Enterprises and Web 2.0 companies (see the WAX site for names).

The day was split into 2 main sections, firstly to explore the drivers that are causing a change in the architectural landscape. These were then mashed together to look for similarities and relationships in order to produce a top level set of drivers.

Access
Profit
Openness
Simplicity
Ease
Loyalty
Choice
Ubiquity
Reach

Personalisation
Culture
User Experience
Journey
Knowledge
Minimized Risk
Agility
Low barrier to entry

The second section was intended to generate a set of 'strategies' to address these drivers or requirements that would help lead to the definition new architectural models. However, to try this in one day, with a set of individuals who’d just met and whom come from different viewpoints proved a touch to much. That said – the groups struggled valiantly and a number of interesting outputs where achieved:

Three next generation Tea Pot designs, one called the iPot and one of the others called the Tea Pot 2.0. The iPot won and was selected for an additional prize as it incorporated the secret key design principle in that it was made of WAX!
A web 2.0 maturity model including a fascinating array of Web 2.0 sites that many hadn’t heard of – a great resource; ever wondered if your MP ever says anything in Westminster? Well you can now!

Mike Platt has made a few early comments on his blog and a WAX diagram that I find kind of interesting.

Now comes the fun trying to digest all the raw data that sould go up on WAX any day soon!

Service Oriented Architectural Layers

Matt Deacon — Fri, 29 Apr 2005 04:25:00 GMT

I mentioned in an earlier blog that I’d talk about SO layers at some point. Well, given that they featured in my presentation the other day I guess that now is as good a time as any to do so.

SOA as I've said previously is more than just a distributed technology; it is a decentralised technology and as such services can be created at any time and at any place within your enterprise, without necessarily a clear indication as to what purpose they may ultimately serve. It would appear that through this process of 'accidental devolution' one could see the proliferation of services that if left unchecked would undoubtedly lead to some level of SO Anarchy.

The key is obviously good governance, something we may preach in the enterprise, but far too often do not practice in full. Ok, but how does this relate to SO Layers? Well here goes:

SO Layers are conceptual layers or perhaps more correctly categories of services into which one can notionally allocate each service. It is important to note that these layers do not constrain service communication or location as in the case of the layers within an n-tiered architectural model. A service at one layer may interact with any other service layer for what ever reason; 'all services are equal'. SO Layers represent groupings of functionally compatible types of service and therefore tend to reflect different levels of abstraction or business orientation. This is with the notable exception of enterprise services as will be discussed below.

Principal SO Layers, at increasing levels of abstraction, or business orientation

Entity Services represent simple atomic operations on an entity such as the representation of a customer for example.

Activity Services coordinate several entity services to enable some business function execution (UpdateCustomer, AcceptPO). They implement common business transactions.

Process services represent long running business processes that may involve complex workflow and human interaction (using BizTalk for example)

Infrastructure Services provide common functionality to other services. They represent horizontal common services across organisations. Examples include Authentication, Authorization, Logging, Exception management etc.

Event Services notify subscribers of interesting events triggered. This may include the use of publish/subscribe mechanisms incorporated in most queuing technology.

Enterprise Services represent enterprise wide or public B2B services. As stated earlier these differ to the other service layers as they represent the natural end points in an Enterprise SOA and as such will generally only consume other inter-enterprise services rather than being consumed internally themselves. This is not mandatory, but will affect how the service is managed in terms of governance and policy.

The benefit of categorising and cataloguing our services in such a way is clear. As with enterprise frameworks such as Zachman, SO layering will organise the enterprise’s service assets, will promote reuse and enable good governance. The mechanism is supportive of organic local growth of services, but enables them to be managed centrally. As such, a core integration architecture team can develop the expertise necessary to manage the growth and proliferation of an enterprise’s service evolution.

I would guess that the realisation of this into an active dynamic searchable repository would be the next step leveraging the features of UDDI most probably. Personally, I haven’t done enough research into this yet, but am looking forward to the Enterprise Architect Conference (London 14-15^th June) and a chance to talk to the guys at Popkin about it (what a name – I always think of a certain childhood show when I say it!).

The Enterprise Service Bus – product or architecture?

Matt Deacon — Thu, 07 Apr 2005 07:38:00 GMT

There’s a bit of a buzz going around at the moment relating to ESB; probably the result of someone shaking a “marketing tree” somewhere!

The problem with the world of TLAs is that they are easy to invent, but it is a completely different matter to then fully define what they actually mean! ESB is a case in point. Some would have us believe that it comprises a physical component of one’s enterprise integration strategy/architecture managing the flow of messages through an enormous pipe.

However, if you actually dig a little deeper, the actual definitions of ESB do not describe the behaviour of a BUS at all; they actually describe the behaviour of the message broker integration pattern in conjunction with the conceptual SOA architectural layer (See future blog) of infrastructural services. This acts to supplement rather than provide a ‘host’ for the SOA network. See the CBDI definition below:

The Enterprise Service Bus is a uniform service integration architecture of infrastructure services that provides consistent support to business services across a defined ecosystem. The ESB is implemented as a service oriented architecture using Web Service interfaces. [CBDI]

Bit woolly, but hardly that of a bus! I like Rich Turner’s description of the product ESBs as ‘smart-plumbing with dumb nodes’ in his recent blog – a bit of an SOA anti-pattern brewing there I think;).

So all in all if ESB is a bus it can be provided as a product, and if you want to buy one, then remind yourself of the success of EAI, and good luck! But, in terms of SOA, ESB represents a poor TLA, unless you were to re-define the letter 'B' to represent "Brokers" plural.

But I guess the final word will go to marketing - ‘Enterprise Service Bus’ has a great sound to it, but as a product it is really EAI with web services:)!

Service Oriented Anti-patterns; a road map for Service Oriented Anarchy

Matt Deacon — Wed, 06 Apr 2005 12:59:00 GMT

I’ve had bloggers block (or is it bloggers droop?) for a while now. I’ve wanted to write something about SOA, but the thoughts just wouldn’t coalesce into anything I could relay in any legible form. That is until know I guess, unless I get a response saying anything to the contrary of courseJ!

So what happened? Well, I’ve been working on a presentation on interoperability and this SOA thing has kept humming around my head unwilling to settle until that is, the other night. Foolishly (sadly?), I keep books by my bedside some new others more dated and there it was, literally staring me in the face – it’s lurked there for a few years now … the book on, Anti-patterns of course. Ah how I loved using words like stovepipe, golden hammer and spaghetti code – still do in factJ! So, at 2, or was it 3 am, my problems with SOA fell into place. Well ok; took on a more legible form than before.

As it turns out I’ve been thinking about best practices – but in reverse and what better way to do this than to categorise them as anti-patterns. Ok, so maybe they’re ‘old hat’! But the benefit of anti-patterns over patterns themselves is that they do not need to be that precise. Anti-patterns describe situations to avoid and as such do not need to be so precise!

Great, now I’m set, or so I thought, it seems with anti-patterns you have to have a silly name for each one. In fact this didn’t take long, but the names change as I write about them so I guess others will be able to think of better ones than me! But I guess if they stick in your head then maybe when faced with a choice of what road to take you’ll think back and say doesn’t that lead to parrot services? Well maybe not! But here goes anyway ….

SO is more than just a distributed technology it is a decentralised technology and as such adoption of services can take place anywhere within the enterprise. This freedom is viewed as a great enabler and liberator to adoption but can lead to the devolution of service responsibility entirely to the business unit itself. Left unchecked the viral growth of enterprise services can create a highly political and fragmented service landscape that serves the short term goals of the local BU over the long term objectives of the organisation as a whole. Silos tend to lead to other anti-patterns such as chain, project, multi-master, newspeak and stovepipe service anti-patterns.

Services Chains
Many advocates of SO use the phrase “services are fractal” to support the notion that services can be combined to provide increasingly business aligned services. This is fine when performed in moderation, but fractals are suggestive of much more and indicate that a system could be comprised of a myriad of interconnected services. Service interaction is an expensive operation (See “Boundaries are explicit” tenet of SO) and therefore service chains should not be taken lightly either. The creation of service chains or dependencies can incur further penalties such as performance, availability, reliability, versioning, maintenance and service level agreements. When deciding to create chains, think of them in terms of house buying chains; the possibility in a break in the chain is an ever present threat and worse still with service chains you have them for life, not just for the lifetime of the transaction itself!

Project Services
Most new development takes the form of a project focused on delivering a particular piece of business as described by a successful business case. In the majority of projects there will be some need to integrate with other systems. This integration is typically performed within the context of the projects to meet the projects immediate goals. However, this often results in a wag the dog’ anti-pattern whereby the service is now ‘owned’ by the consumer of the service (i.e. the project) and not by the service provider itself. The problem here is that the project is ephemeral in nature, the teams will soon be disbanded, contractors will leave and domain knowledge gradually seeps away through the cracks. A number of issues relating to reuse and maintenance can then arise as a result leading to the occurrence of stovepipe, parrot or newspeak anti-patterns, these in turn leading to service overload.

Parrot Services
This is the propensity to “re-invent the wheel” as regards service function, often as a result of using the project service anti-pattern for service design and development. This can quickly result in a confusion of services, making consumer choice difficult and error prone. It can lead to stovepipes, newspeak and service overload anti-patterns.

Newspeak Services
Newspeak (or forked tongue) services are services that do not necessarily speak the truth. This can occur for a multitude of reasons and often as a result of pursuing project, parrot or stovepipe anti-patterns. It is essential for the success of services that they are trustworthy, not just in terms of security and availability but in terms of the data they share. It is surprisingly easy for services to become ‘out-of-date’. A variation of newspeak is caused as a result of allowing the multi-master service anti-pattern to occur.

Multi-master Services
Data often resides in multiple places in the enterprise. This data is often shared by process including file, batch, or manual transfer and are often the target of service definitions, but more often remains discrete in the application silo to which it is tied. If a cohesive data integration policy is not followed then the resultant multi-master situation can pervade whereby each application silo believes it is the centre of the universe. In SOA no one is master by default and left unchecked parrot and newspeak service anti-patterns will result.

Stovepipe Services
The stovepipe is a well known anti-pattern and this is just a reflection of this as related to services. The Stovepipe relates to the chimneys of wood burning stoves that due to the caustic nature of wood smoke quickly fall into disrepair and as a consequence they remain permanently unstable requiring constant patching and repairs. In terms of services the cost of constant change in terms of changing or layering on new functionality adds to the cost of the service in terms of maintenance and stability.

Service Overload
Primarily as the result of the parrot and project service anti-patterns, but also as a result of ‘death by success’ an underlying service provider can quickly, but quietly, become overloaded as an increasing number of consumers connect up. If this is as a result of project or parrot services this can occur be dramatic under relatively low user load as each service makes individual connections to the underlying resource be that of a database or mainframe for example.