SOA: What’s in it for me?

My colleague, Saul Cunningham, recently posted his thoughts on SOA and stated how it has to be a strategic play. He also went on to say that organisations who view SOA only within the scope of projects and point-to-point, service-based integration, will not achieve the benefits of a SOA-assisted enterprise architecture.

While I totally agree with his post, and I have seen many service-based integration examples that are not delivering the goods, I would like to focus on the people aspect of SOA. As Saul mentioned, SOA cuts across the organisation and affects many people and their roles. In doing so, SOA requires numerous people to communicate, collaborate and align with each other. The issue I see though if SOA requires such social behaviour, is how do we communicate the concept of SOA and the business value that can be achieved through the approach? I think one of the problems we face as technologists is that while we might understand concepts such as SOA, we struggle to have that business discussion. We fail to, on the one hand understand the challenges the business folks are trying to resolve and secondly we speak to them in context that they do not understand.

I felt this first hand at the recently held Insync09 conference. The majority of delegates I met were mostly applications managers, functional specialists and business analysts. I conducted an impromptu experiment to gauge what language would work with organisational profiles such as these folks, as traditionally their role in an organisation would be to ascertain the scope of a business issue, resolve it through applications and then integrate them. When asked by some folks what is SOA and how SOA could help; I spoke about the business agility, flexibility and service reuse benefits. Their eyes glazed over, which was expected. The conversation had no context to their world. There was nothing in it for them.

I then had the chance to present with Debra Lilley, an Oracle ACE Director and Deputy Chair of the Oracle User Group UK. We tackled a potential issue applications managers face, namely how processes such as order to cash could be extended beyond the traditional border of a business application. So we got them to think about the need for enterprise process, the services that already exist in available applications, and the need and benefits of moving away from point-to-point integration. Using a demonstration, the message went down very well as the delegates understood how their particular point of reference could change for the better. Debra was interviewed at the conference after our session, and explains the analogy she uses when trying to explain SOA and where she feels SOA can help applications specialists.



SOA purists might balk at the conversations we had, but I realised that while many of us understand how SOA can impact an enterprise architecture and support transformation initiatives and the greater business strategy, individuals impacted by any level of transformation require a conversational scope and approach that will contextualise the change to their frame of reference. In other words, what is in it for them.

Insync: Getting down to the business of SOA

In their journey towards adopting a SOA approach, organisations can be faced with a number a challenges. These roadblocks can often stifle SOA initiatives and reduce them to low ROI infrastructure integration projects. It is a concern to me that many initiatives follow this path.

While I spend my life in the world of technology, I am in the fortunate position of being exposed to a broad range of organisations attempting, maturing, succeeding and failing in their SOA journey. Two of my colleagues and I decided to compile a session at the Insyc Conference running on the 20th April in Sydney to address three key areas. (There is just so much you can cover in three hours!)

The first session will address strategies and tips on how to go about having the ever-important business discussion and how to approach building a business case. The second part of our afternoon will focus on preparing the IT organisation for transformation. We will cover topics such as the position and role of the CIO in the organisation, the relationship between IT and business, the potential need for an IT structural and role change, the development and resourcing of skills, the movement from architecture to execution, project selection, and the need for the establishment of a SOA Center of Excellence and governance framework. The last session of the day will focus on successful SOA execution. It will cover aspects of architecture, various enabling technologies that can support a SOA approach and execution strategies that organisations adopted, which eventually contributed towards their SOA journey and their eventual business transformation.

While our session is not the definitive guide on how to approach SOA, as the application of SOA is unique to every organisation, we hope that learnings gained from our interactions in the marketplace will be of benefit to other organisations embarking on their journey.

Hope to see you there!

Viewing SOA as a project instead of an architecture

Recently a lot has been written about SOA's failure to deliver results and ROI. Wherever you turn you will find blogs, articles and opinion pieces saying what amounts to "At last the snake oil is exposed. Flush and lets ...".

And that's thing thing isn't it? Lets what exactly?

Lets go cloud computing? Lets go Web 2.0? Lets go mash-ups? Or whatever. Thing is will any of these turn out any different to the perceived failure of SOA in 5 years time? Why would they? Most of these concepts borrow from SOA ideas which were based on ideas that came before that. I am reminded of Larry Ellison describing the IT industry as being "more fashion-driven than women's fashion."

It all goes back to the fundamental truth that I often write and speak about . SOA/Distributed-computing/Web 2.0/Mash-ups/Cloud-computing/yada-yada-yada all need an architecture rather than the "let's go buy some software, do our project and be heroes". In fact this attitude is what created the mess that SOA et. al. was born to fix.

This was succinctly put by Anne Thomas Manes recently in a blog about called Measuring SOA Success/Failure. Anne's headlines are often read (eg. SOA is dead) but the content of what she writes is often not digested. Here are a few salient quotes that should be heard loud and clear:

• Most organizations that I've spoken with are using service-oriented middleware to do integration (SOI rather than SOA). Very few companies are actually re-architecting their systems...
• I have seen a small number of spectacular success stories. These companies have realized huge savings, they are able to deliver new solutions in significantly less time than before. All these companies adopted SOA as part of a much larger IT transformation effort...
• And just in case you miss my point, I still strongly encourage organizations to invest in SOA. But my primary recommendation is to focus on architecture rather than technology.

Here we see that most organisations use SOA to do point-to-point integration with Web Services. No wonder we see no value - all you achieve is add yet another technology to the mess.

The goal rather needs to be the rationalisation of IT. Effort needs to be applied to streamline the business process by reducing the complexity and the application and data layers. But this is difficult. It involves political fights as it cuts across fiefdoms. It involves the hard work of forward planning. Don't confuse what I'm saying to mean that you have to "boil the ocean" upon the embarking of the good ship SOA. Not at all. The SOA journey is taken as a number of steps but the before we leave the dock we need to know where we (the whole organisation) are going and why. Then each step can be taken in the right sequence - it can be taken in context with the other steps.

I am getting increasingly frustrated as each wave of IT technology is deemed to be a failure and the software products are invariably identified as the culprit. I am reminded of an old adage "a poor workman blames his tools". Doesn't matter how good the tools are - if you start building without a plan (architecture) don't cry if you make a mess.

Free Speech, Common Sense and the use of Social Networking

Read an interesting post this morning on the Sydney Morning Herald website surrounding the case of some prison officers facing disciplinary action after posting some comments to a group on FaceBook.

We are all entitled to free-speech, to a degree of course, but what we must rely on is some common-sense! Most organisations will have an acceptable use policy for their equipment, networks, internet access, software, databases etc. that governs what they expect you to do and not-to-do within and outside of work hours on tools they provide you to do your job. They do not, however, govern what you do on your own time on your own equipment - but there's a catch. If you, in anyway, cause offence, defame or bring into disrepute in anyway the organisation you work for - you could be liable for disciplinary action. This is what the prison officers in question are facing right now.

Bottom line, be careful what you say and where you say it - FaceBook is NOT like having a chat over a beer in your local pub with a colleague who feels the same way. Actually, it is - but the difference being the conversation is recorded and played back to your boss the following day!

The Fake Paul Ricketts

Addendum [02-04-09] It's always nice to hear that great minds are thinking alike. The Real Kate Carruthers wrote an article about a similar topic - that of using systems like FaceBook and other abuses of IT in the workplace. Well worth checking out Kate and her article here.