SOA

The Open Groups SOA Ontology

Dave Oliver — Wed, 16 Jul 2008 20:51:52 GMT

The Open Group has recently released a draft version of a SOA ontology.

The Open Group has always had a mandate to help boundaryless information flow and the ontology (specification of conceptualisation) for SOA is a demonstration of just that. The ontology is written in the Web Ontology Language (OWL) defined by the World-Wide Web
Consortium and this for me is what makes it a hurdle to learn as it's not an intuitive meta-language but then is any? Perhaps if it wasn't for the graphical tools we would get stuck.

Open Group explains the benefits as:

1. It defines the concepts, terminology and semantics of SOA in both business and technical
terms, in order to:

Create a foundation for further work in domain-specific areas,
Enable communications between business and technical people,
Enhance the understanding of SOA concepts in the business and technical
communities, and
Provide a means to state problems and opportunities clearly and unambiguously
to promote mutual understanding.

2. It potentially contributes to model-driven SOA implementation. The ontology is designed for use by:

Business people, to give them a deeper understanding of SOA, and its use in the
enterprise;
Architects, as metadata for architectural artifacts; and
Architecture methodologists, as a component of SOA metamodels.

The full draft can be found here:

http://www.opengroup.org/projects/soa-ontology/doc.tpl?gdid=16940

After reviewing the draft I am left cold. My first opinion is that business will find this difficult to adopt in the same way they found UML difficult. Why because they are both coding languages, you may as well stick in a 'Print' command. The gap between logical design and executing code is a large as ever.

I still hold the belief that business and IT can only really align on the logical level. Business doesn't want to know about detail they will want to be abstracted away from that, this is actually a key SOA deliverable, just a very unspoken one, hence why REST services appeal. I believe that IT cannot handle business logic detail on it's own, so alignment between business and IT will come when hybrid groups formed of technologically minded users and business oriented IT exist to make, maintain and specialise in services that support their business area based on IT standards and underlying IT technologies and services.

Why I believe these groups need to exist is because business and IT can never align because they have very different goals and therefore different headings. Align the destination and the groups will align, not possible with business and IT as they are very different by reson d’etre. You can't marry creatures of different species. You can however translate and interface.

These groups do actually exist all over successful organisations they just lack boundary, form and recognition perhaps even by the very people that make them up. E.g. So you code in a Spreadsheet? So do you report to the Sales-Manager or Dev Team Leader?

Back to the Ontology, I think the Open Group need to ask a fundamental question, how does business see and understand logic? I really do think we need to revisit DSL's.

Technorati tags: DSL, SOA, Open Group, Ontology

A successful approach to SOA: Change one thing

Dave Oliver — Thu, 10 Jul 2008 14:31:09 GMT

Many of us did it, made one New Year Resolutions to many at the Millennium and didn’t managed to succeed in any of them. I tried to give up smoking, losing a bit of weight, drinking less beer, save up to buy a house and learning to drive. A lot of change there, to much infact, so unsurprisingly I failed. A common story.

8 years later, all those things on the list are (more or less) achieved and how I did that was by concentrating on fixing one thing at a time. Again unsurprisingly, psychologists have been giving us this advice for sometime. In the UK one of our major high-street brands, Boots, turned it into a successful marketing campaign. So why in business should this truism be any different? It isn’t, day in day out processes and projects breaking down complex tasks into smaller manageable chunks.

The SOA concept allows this to happen as layers and services are separated by discrete interfaces that are abstracted and/or facades, so why try and implement all the parts of SOA all at once. To much change happening at once.

It does make sense to create a SOA in parts, however this statement is caveated, there is a risk that an organisation may only then implement parts and not realise the benefits of completing the SOA stack. However if they are happy and they realise benefits then this is perhaps this is still all-good. No point on trying to aim for the text-book answer if your organisation isn’t text-book. Honestly, can’t answer this one for you, so the answer is be-smart.

This isn't a compromise, to me I see this as common sense. Trying to force a sea-change on a business isn't going to be easy a step by step approach will have more chance of successful change.

When things take time it's going to be easy to lose sight of the goals, I think that this will be inevitable unless there is an active Enterprise Architecture function to pass SOA strategic goals on to and ensure they stay alive from one budget year to the next, after all that's what it's there for.

So how does an Enterprise Architecture do that? Enterprise Architects (if they haven’t worked it our yet) plan for the future, well that very topic is going to be the subject of a future post!

There has always been a debate about which part of SOA do you do first? I’ve always thought that create a Governance framework and Service Management hand-in-hand with a change to development methodology, process and departmental changes as well as change in technology is the ideal starting point … but alot to takeon in one go, however I do hear the ‘chicken and egg’ debate of service management structure and standards first before writing production service so they don’t have to be re-written. Yes that would be great but many organisation *need* to find out the reason it’s done this way round, usually they won’t accept they have to do it until they have experience the pain first hand. Sadly the ‘So what if another company has learnt lessons so we don’t need to, that’s a different company, so we are going to be better?!’ mind-set is the norm, so just like a young child they learn that a pin is sharp and Coco is hot no matter how many times they are told. So if you really must run before you can walk consider the Data and Connectivity Services first as simple abstraction and interoperability can demonstrate real initial value. However business rules will be all over the place still and you won’t be able to govern, manage or standardise your services but I can guarantee that will all get learnt when the needs arise just need to experience a sufficient level of pain first.

Vendor support for the ‘Change one thing’ approach differs from vendor to vendor. Many have great difficulty in the concept of start real small and growing by adding penalties (or what feels like them) for not buying big upfront. When starting small and growing could introduce a lot more organisations to SOA so the vendor gets a steady stream on purchases over a few years which will take them up to the version upgrade if your vendor account manager/ess is lucky. So it is in Vendors interests to have a entry-level SOA offering, and the right price is free as well which is a great way to get vendor lock-in, start with a database or development environment that is fully feature and free, even Microsoft have been doing this for years, infact they may have even been the first.

Anyway, I believe that taking it one step at a time is the very best approach as this will ultimately manage complexity and easier to manage expectations, get funding and keeping it simple. It will however take longer but success takes time just like a fine food or wine, SOA isn't a Pot-Noodle!

Technorati Tags: SOA

Avoid SOA becoming a ‘SO What?’

Dave Oliver — Tue, 08 Jul 2008 21:30:23 GMT

Analysts, vendors and end users alike appear united in their enthusiasm for SOA. Recently the Butler Group tells us that only 3% of organisations have rejected SOA. In a recent survey by systems integrator Griffiths Waite found that 2008 is a critical year for SOA implementation, with 15% of organisations already running SOA but a much larger 38% progressing towards it. Of the 47% still “contemplating” it, Giffiths Waite says “evidence suggests these will [start to] move into strategising and planning”.

However it has to be said that despite these figures scepticism about SOA is starting to appear along with news of the first SOA casualties. Anne Thomas Manes, VP and Research Director with the Burton Group, recently blogged about her ongoing research with enterprises implementing SOA. She says:

“…I think I’ve become a bit jaded from the interviews, …[because] it has become clear to me that SOA is not working in most organisations.”

She goes on to describe how despite the “stunningly beautiful” SOA infrastructures these companies have developed, their SOA initiatives “invariably stall out”. She says: “The techies just can’t sell SOA to the business. They have yet to demonstrate how all this infrastructure yields any business value. More to the point, the techies have not been able to explain to the business units why they should adopt a better attitude about sharing and collaboration – which is the fundamental cultural shift required for SOA to succeed… As one of my interviewees said, ‘Altruism is not an enterprise strategy.’”

It is hard for what is essentially an IT initiative that is utterly dependent on business buy-in to get it. So how do you sell it to the business? For my experience the best way is to turn selling SOA to the business into a mini PR project taking a strong hint from Alan Cooper work on Personsa’s and TOGAF Architectural Views

When selling SOA to the business it’s wise not to just target the individuals incharge of budgets and give them that standard definitions and turn it into an technology education session. These people will have others that influence them and report to them, all of them will have specific view-points so it is worth preparing sessions that cater directly to their needs rather than getting lost in the big picture, use Business Analysts to help identify their concerns, likes and dislikes, in other words get to know your audience. This will be time consuming but ultimately allows people from IT and Business at a non-management level to interact which will do more for business/IT alignment than any Gartner report because you are listening to each other, this is priceless. Also alot of detail will come out so ensure that your requirements capture process/tool is up to scratch because it will get a hammering, capturing as much as you can because it’s all good.as this is lthe level where SOA is made or broken down, keep the process moving by recording and moving on.

This leads me on to my next point, I’m not sure it’s wise to have business and technical staff at different locations and different time zones. Alignment comes with good relationships, you can’t make friends via requirement documents and email. Global organisation or not you will lose money going backwards and forwards and lost time in misunderstandings.

SOA effects business and technology further than most methodologies have done in recent years, how many can claim to need a change to business process? So, take business with you to avoid the So What.

Technorati tags: SOA

Loosen the grip of SOA Principles at your Peril

Dave Oliver — Wed, 02 Jul 2008 19:21:29 GMT

Recently, I was involved in a SOA review for an organisation (obviously, I do not wish to name names) It was pretty clear that they hadn’t actually adhered to many of the key SOA Design Principles that are,

Much of the SOA was built using a single vendors technologies many corners were cut because of compliancy, so tight coupling crept in to make interfacing ‘easier’, abstractions were compromised to improve performance. Reusability opportunities were missed because of ‘not invented here’ mentality and ‘it’s not quite what we wanted’. Statelessness was lost because of writing application specific services, discoverablility turned into a spreadsheet with multiple copies all out of sync and business rules all over the UI because ‘surely there isn’t going to be another one of those ???’. So corner cutting made the SOA an expansive large and complicated Client/Server application so they had recreated the very mess they were trying to escape from.

The key reason why the SOA principles exist is because you can’t predict the future so prepare for change without exception (– this could be the ultimate SOA principle). It’s that simple. This is why the argument for SOA Governance is resonating right now. So the message is follow them now voluntarily to save having it forces on you later, which I know is happening at some organisations because of the amount of money at stake.

Companies live and die because of their differentials or lack of them, a decent SOA helps people leverage them. With the economic climate as it is compliancy could lead to the need to find another job.

Book Review: SOA Approach to Integration: by Ramesh Loganathan, Poornachandra Sarang, Frank Jennings, Matjaz Juric : Published by Packt Publishing

Dave Oliver — Mon, 31 Dec 2007 18:44:12 GMT

Selling the theory for SOA is pretty easy, the execution is harder because technically it isn't actually a very simple thing to do, let alone the changing of the structure of your IT organisation to house-keep.

The book SOA Approach to Integration is aimed fairly and squarely at the Architect and Senior Developer who has the job of designing and implementing SOA technical level. The book is very resolute in keeping a strong focus on the technology and pleasantly realises that successful integration needs to take place across technological boundaries. Seems pretty obvious but I have a whole host of SOA books gathering dust because they lean heavily towards one technology and one approach. This book refreshingly avoids that, even avoid tasty new SOA areas such as composite applications and REST.

The book takes the reader through the basic principles using patterns to demonstrate many classic integration techniques. Sample code in Java and .Net and takes you through the interoperability story between these two mainstream development environments. Sadly this is where I found my first real criticism of the book, the book does not cover Microsoft .Net 3.0 and WCF or indeed any of the work performed by the Open SOA group such as SCA and SDO. I know that both technology frameworks are on version 1 but developers will be keen to use these frameworks and will feel license to do so as they aren't in beta.

One of the major problems with writing highly technical books is communicating complex points, this isn't very easy without diagrams. The book excels here because it's stuffed full of them, 92 diagrams (or there about's) and many a point sails across because of them.

Most of my list of key SOA points are covered but the books core strengths are BPEL, XML Schema's, Web Services and establishing an ESB, subjects it deals with a high degree of expertise second to none. However specific applications are not mentioned much but one of the clear aims of this book is to stay tech-neutral and keep to the keys points and I would like to thank the authors for that. It is a rare treat to see advice separate from opinion.

So would I use this book to advise me on my next SOA project? Most certainly yes! I can see it being my companion to many a design meeting and delving into it's pages for nuggets of advice. However comprehensive this book is not, thankfully it would therefore become a huge unwieldy tome and no use to man nor beast so I thank the authors that they keep things brief and to the point and at 351 pages not something that is going to weigh your brief-case down.

One very small point, I have been reading this book over Christmas and not one person thought to pick me up for reading a 'techie book' I suspect this is down to rather delightful butterfly on the cover. I wonder how many times that saved me from washing up?

Book: SOA Approach to Integration

Authors: Poornachandra Sarang, Frank Jennings, Matjaz Juric, Ramesh Loganathan

Publisher: Packt Publishing

Here from Amazon UK , Barnes and Noble & Packt

Technorati tags: SOA, Integration, BPEL, XML Schemas, Web Services, ESB, PackT Publishing

Codename "Oslo", Microsoft's next generation SOA thinking.

Dave Oliver — Mon, 03 Dec 2007 22:51:49 GMT

Oslo is the codename for technical thinking aimed specifically at simplifying designing, building, managing and scaling of service-oriented and composite applications that can span from the enterprise to the Internet.

It is thought the first version of Oslo will be delivered through the next versions of our application platform products such as Microsoft Visual Studio 10, Microsoft System Center 5, BizTalk Server 6, BizTalk Services 1 and Microsoft .NET Framework 4. So, we are talking a 18 months to a few years timeframe.

Microsoft in the past has been strongly criticised for it's SOA initiative for many different reasons which are,

Not having a comparable product range with most other vendors, making vendor selection harder.
Not adopting the same standards as other vendors, specifically in BPEL. For my mind this is a mute point as most vendors implement different versions of BPEL support in their products. The same cannot be said of WS-I WS-* standards for web services as Microsoft have supported their development using WSE extensions to .Net 2.0 and later on with WCF with .Net 3.0.

Reading the Oslo website my main concern is I'm seeing little emphasis on common standards and interoperability which for me are the main reasons why organisations decide to implement a SOA policy. So the question I'm asking is, is it really all about designing, building, scaling and managing .Net applications better which in the past has not been the strong suite of Microsoft which has made organisation go to third parties for products and advice to solve these problems.

The reason why we know about Oslo at all is that Microsoft want to have a conversation with us which is something they are getting better at however there is no blog to link to, no entry on a forum or C9 so I'm looking for somewhere where I can have that dialogue with Microsoft, hence the blog post!

Technorati tags: SOA, Oslo, Microsoft, .Net, Biztalk

Enterprise Architecture: Microsoft Architecture Journal Reader

Dave Oliver — Thu, 29 Nov 2007 16:56:13 GMT

Microsoft have release a really cool tool for downloading and reading the Architecture Journal magazine offline.

The new reader is a locally installed application that enables you to read every issue of the Journal into a searchable and easy-to-read form. The application synchronizes with our content management services so that you'll automatically have access to the latest Journal issues without needing to download PDF files or checking online.

Please note the tool is still in Beta so there is bound to have some issues. Also .Net 3.0 is a pre-requistite and will attempt to install if you wish. if not present on your system.

The download is here.

SOA is getting killed!

Dave Oliver — Tue, 09 Oct 2007 21:49:53 GMT

Zapthink's recent article on Who's Killing SOA? hit the nail on the head to the reasons why SOA is not succeeding!

However, reading the article I think that Zapthink has missed the two main reasons why SOA is currently not succeeding.

1) Education - I believe that people in Business & IT are not completely clued up on what SOA is in enough detail to implement it.

2) United Vision - People in Business and IT do not have a united vision of what SOA is and do not have a complete enough understanding of how each others area benefit and this is key, because getting SOA right is a balancing act between business and IT, get it wrong and neither will really use it further than the current implementation.

Recently, I've seen a SOA implementation go from bad to worse because,

It's not a 'Pot-Noodle' technology - SOA is a strategic initiative it's very difficult to implement when the mainstream department is BAU/tactical/operational, so narrow vision will be a problem. You just can't add water and *puff!* a full fledge SOA will appear!

Change - People don't like change, SOA is a big change, it's scary and risky but the benefits are worth the risk and even getting it about 50% right is going to benefit your business greatly.

Vendor FUD - Vendors are shits, pretty strong stuff but when one Vendor fails to get the gig and you still have a relationship with them be prepared for a rough ride from anyone that is still listening to them. Not that I like to point the finger or name names but Oracle and IBM you are the worst for FUD! Teach your account staff to be gracious in defeat.

Managing complexity - One of colleagues said, "The problem with our SOA implementing is that there is to many moving parts", "well deeeer yeah" was my reply. Under the hood it is complex, you must protect business and IT from seeing the complexities with abstractions.

So, I do fear for the future of SOA as I think it is destine to join the ranks of IT history failed because of over-hype and spin.

Introducing Biztalk.Net Services, far reaching implications on SOA?

Dave Oliver — Fri, 22 Jun 2007 15:00:26 GMT

I have been watching the channel 9 video on Biztalk.Net Services. I have to say I’m pretty excited about this project and the reason why will become apparent later on in this post.

BizTalk.NET Services ( http://labs.biztalk.net ) is an experimental project (it’s at CTP currently) that extends WCF and is all about generic, secure connectivity. It’s a free download so fill your boots!

The project has come about from the result of customer feedback where many have asked “how do I notify client applications that something has happened in a service?”

If the client is addressable and listening, this is a fairly easy question to address. But what if the clients is not addressable behind a firewall or NAT?

What Biztalk.Net Services is effectively a service bus which acts as a broker between the client application sitting behind the firewall or NAT and the Internet.

So why use it just for that? This is why I’m excited. My first thought is why not use this as an easy to implement EAI bus making it easier to integrate programs together period. This could be used as initial first stage before embarking on a costly, expensive and time consuming full SOA initiative? A great way of quickly proving the concept without all the initial expense, then scaling up from there? The is perhaps the beauty of WCF, much of the coding makes the choices of protocol and security an abstraction, so in effect it doesn’t need to be your main focus and doesn’t dominate the way you develop your applications which is perhaps the point.

The project so far is thriving on customer feedback so it’s your chance to get involved and help build a great set of utils. It’s clearly too late to be included in Orcas so it’s not clear where these service will eventually fit.

My last point is, why call it Biztalk.Net Services? When at this point in time it has nothing to do with the Biztalk product which is seemingly heading straight for the BPM space? It has been clear for sometime that Biztalk is perhaps a product that is going to be split into two, firstly being an integration piece perhaps centred around the WCF technology the second being BPM. Perhaps calling this Biztalk.Net Services is diversionary for the moment and will under-go a name change at a later date to fall inline but at the moment it’s confusing. However I should stress that this is just pure speculation on my part, I have not conferred with anyone at Microsoft to draw these conclusions.

As yet there isn’t any information on about how well it performs and scales so I wouldn’t build any production code on this just yet but it give us a glimmer of what is going on. Geez Microsoft are working on more than a few integration stories at the moment, Astoria etc, I do hope that there is a underlying unify strategy underway or we are going to get a raft of comm technologies that are in danger of being disparate.

Anyway, good stuff MS!

Making sence of all those Crazy Web Service Standards

Dave Oliver — Fri, 18 May 2007 04:43:00 GMT

I spoke recently about Astoria as a possible answer to the snowballing standards of the WS-I.

Anyway, I decided to look into this a bit more and I found this perfect article written by Michele Leroux Bustamante of IDesign, entitled "Making sence of all those Crazy Web Service Standards" that will happily explain the new standards with handy diagrams and bite-sized explanations.