SOA Success Plus Wiki

By Nick Hortovanyi

Recently, we have created a SOA Success Plus wiki. This wiki is open to all, who register, to contribute if they so desire regarding experiences around SOA. Yes, wikis are all the rage at the moment and we are working out how to gain contribution from the larger SOA attentioned community as we go!

I've created a front page of types but am now thinking of creating six major sections being:

1. SOA Architecture Style;
2. Governance for SOA - both business and IT;
3. SOA Tools;
4. SOA Platforms;
5. Knowledge Transfer; and
   
6. Services (well this one is open to interpretation a little ).

Any assistance, suggestions or comments on getting this wiki up would be greatly appreciated.

Empowering IT to enable innovation

By Nick Hortovanyi

Are we starting to see a resurgence in business to allow IT to do what it does best - facilitate innovation in the business?

Many reading this would have careers in IT that have spanned generations of technology and seen lots of interesting technologies evolve. There are now so many products and technologies available it is becoming difficult to determine "which are potential candidates?" and at "what stage should they be introduced into your organisation?".

I believe there has also been another inhibiting factor, being IT departments led by so called "business" focused people. These persons, have chosen the lowest risk options and in some cases the lowest cost options as well where the focus may have inadvertently led to what I am calling Contract Based IT Management. Once embedded, these contracts dictate the technology being used, the people supporting them and to a large extent stop change. They may have created some short benefit through imposing a new structure where previously activity may have been considered slightly chaotic. In addition, through outsourcing the organisation may have lost some of their brightest human assets.

Well we know the IT industry is continuously changing. So for how long can an organisation afford to keep this status quo that has been imposed by the previous contracts established? I think the first sign is when users are starting to suggest that their internal systems are dated and no longer reflect current business processes.

So what are these contracts now doing that facilitates innovation in your business?

The IT professionals that I know, whilst realising that Contracts are important, do not want to be known as Contract Administrators.

If the answer is not, that it is facilitating your remaining internal IT team to focus on innovation in the business. Then maybe ask why?

Freeing up people's time from contract administration and releasing funds to focus on innovation through in sourcing and teaming with specialised organisations, when appropriate, may be the means to start empowering your IT.

I'm starting to see signs of this becoming a general trend. What are you seeing?

What are the alternatives to a SOA style architecture?

By Nick Hortovanyi

Some people I have spoken to recently have suggested that they are not convinced as yet that a SOA (Service Oriented Architecture) style architecture is correct for their organisation.

The major vendors are all promoting SOA and for better or for worse it is the architectural style that is being used for new projects. It may not necessarily be called SOA. But largely, if the architecture is not a 80s/90s style client/server model, then there will be a business tier that exposes services at some granularity to be consumed by a presentation tier or another business tier service.

So the main alternative for a SOA style architecture would be to more tightly couple the integration moving back to a 80s/90s style client/server model. Some organisations have still not moved from this model.

Portal technology as an onramp to SOA

By Nick Hortovanyi

A number of organisations use Portal technology as an onramp to SOA. Have you ever wondered why?

A SOA architecture style enables a number of services to be exposed that can be consumed by a number of other services or business components. A key issue in this environment will be the granularity of the service. This is such an interesting topic! I could really spend the next few months writing about it. However, a Portal, normally through discrete portlets, allows a service to be consumed in an atomic manner. That is the portlet will utilise the capabilities of that service with out the potential need to interact with one or more other services, thus introducing the need to ensure control transactional consistency across the services.

Many portlets can be assembled on a page, and through the use of wires, these can be assembled into a composite application. As the user selects something in one portal a message is sent through the wire to the other portlets. Normally there will only be one update type portlet hence only one update service engaged in transaction. Therefore it becomes the responsibility of the ESB, if being used, or the service being invoked to maintain transactional integrity.

One could argue, that this is working around some issues and in reality it is! I would suggest not trying to overcome these limitations at this time. If you have a different argument leave a comment, would love to hear about it.

to SOA or not to SOA

By Nick Hortovanyi

When is the correct time to introduce a SOA Style Architecture into your organisation?

It probably is already happening, so really it is at what point do you jump on the band wagon. Well, in my opinion the answer is the sooner the better, it is a journey that has already started that has no clear end.

A Service Oriented Architecture (SOA) is an IT Architecture style. You can do a google search and find lots of information. Boris Lubinsky has written an excellent article on IBM Developer Works called Defining SOA as an architectural style.

This is important to understand, as I've read a lot of blog entries by journalist saying that if they talk to developers they are developing web services and if they talk to IT Architects they say they are building a SOA environment.

I would say that there are parallels for this through history where the Architecture being developed was not understood by the persons outside of the field of endeavor that it was being defined for. Of course many persons and organisations benefited from successful implementations based on those Architectures.

There is a lot of great support material available from the major vendors to help educate and address the questions and issues raised by business. This is not a cop out for not having an Enterprise Architecture, that addresses the business, but a way of helping to raise the priority for revisiting or creating it in the first place.

SOA architectural style, represents a set of Architectural patterns that can be leveraged in a repeatable fashion through meta models to reduce the time to value and risk of implementation failure. The various products evolving to support SOA, implement some combination of these patterns. The patterns that you will need, will be dependent on the business domain, business model and problem domain.

An interesting read is Toward a pattern language for Service Oriented Architecture and Integration, Part 1: Build a service eco-system. Try and avoid the SOA Anti-patterns.

Would be interested to hear from people regarding SOA architectural styles and patterns. Have you had success? What other styles have you found successful?