Worst description of Java Beans ever?

JavaBeans is a component object model with API's that extend Java's reuse capabilities by enabling third parties can create applications from reusable components. JavaBeans is the Java analog of Microsoft's ActiveX, and of OMG's CORBA. Unlike ActiveX, JavaBeans is intended to be platform-independent.

By an assistant professor at the University of Virginia.

Genius

Technorati Tags: Java

Enterprise SOA Adoption strategies

Whey hey I've had a book published by the nice chaps at Infoq. Free download if you register, but of course its much nicer to have a hardcopy on your shelf at home. The book is an SOA book, not a SOD IT book and I've tried to cover as much as possible on how to define your SOA and the potential impact that this could have.

Comments, critisisms, recommendations and requests welcome.

Technorati Tags: SOA, Enterprise SOA, Service Architecture, Service Oriented Architecture

Why Best of Breed and loose coupling doesn't always work

Over the weekend there was another great example of why best of breed software choices aren't always the smartest. It demonstrated why the ability to work together to get something done is more important than just lobbing together the best things you can find. Sure the Americans on paper had the better players... but the Europeans had the better team, much the better team as it turned out.

From an SOA perspective this is an important lesson, it means that its actually the links between services are critical success factors, rather than just the services themselves. When people talk about getting in lots of best of breed services and just orchestrating them together they are missing a key point about cohesion.

Loose coupling isn't the best thing in the world all of the time. Sometimes things are better if they are naturally cohesive and actually have a high degree of coupling. This can make it easier to get them to work together and actually deliver more value because of this cohesion.

So be very careful when obsessing about loose coupling or using only "Best of Breed", think about the right level of coupling and the services that work for you.

And remember... don't listen to Accenture, when doing SOA its better to be a team than a tiger.

Technorati Tags: SOA, Service Architecture

SOA RM - exit poll indicates its going to be a standard

Okay there is still a few days to go on the vote, but the standards vote for the SOA Reference Model has passed the threshold it needs to become a standard, so as long as nobody votes "no" its going to make it. This means that for the first time in the history of SOA there is actually a standard that isn't about shifting XML from one place to another but is actually about the key concepts of SOA and the guiding principles that people applying SOA should abide by.

Phenomenal achievement by the team and in particular the chair who herded the cats, nice one Duane.

If you are doing SOA and you haven't read it already, then you really are causing yourself a lot of pain when you are trying to explain SOA to people. Get yourself a copy of the SOA Reference Model and have a read. If you use this as the definition of SOA in your organisation this gives you a much firmer base both with the business and IT and stops squabbling over minor points of detail. When you do use it, let the group know, we'd appreciate the feedback.

Whether you are doing WS, REST, Business Service Architectures, Shared Services or People Services the OASIS SOA Reference Model can define the basic principles in a consistent manner.

At last we have a standard for SOA that is about SOA and not about the technology.

Technorati Tags: SOA, OASIS, standards, Service Architecture

SOA Meeting Rules

From Steve's book of applying the blindingly obvious to SOA...

1. Meetings shall have an agenda which will
   
1. Identify which services an item refers to
2. Have a proposed lead for the item
3. A RACI for each item
   
2. During meetings only people who are RAC in the RACI can talk on that item, if you are "informed" shut up
3. Minutes will be kept for the meeting with actions assigned to both services and individuals these will be translated into work tasks or bug reports associated with the service.

All I'm really saying is that SOA doesn't mean that you can just get a bunch of people in a room without an agenda and hope to actually acheive things.

Technorati Tags: SOA, Service Architecture

Dark SOA revisited

Having been involved in a couple of REST v WS discussions recently, I've decided that not only does Dark SOA really exist, it is actually more like a black hole than Dark Matter. We all talk about business agility and flexibility, but then start arguing over the technology and pretty much forget about the business side of things in a mistaken belief that technology is what they wanted in the first place.

This attractive force of desiring to focus on technology rather than the business is really damaging to getting SOA delivering on the promises, its really creating a black hole into which IT people continue to fall while still protesting that everything is fine.

If SOA is technology then its another TLA and another black hole down which money and broken promises are thrown. And while its kind of interesting to watch these projects and ideas fall to their deaths and be compacted down on top of the previous generations of IT to form a super dense impenetrable IT estate, this time with XML as well, its not much fun when I realise that I'm probably going to have to work at some of these companies at some stage in my career.

Technology SOA is Dark SOA, its black hole creating supermass that brings everything down with it.

The clue is in the question folks, want business agility? Focus on the BUSINESS

Technorati Tags: SOA, Service Architecture