SOA Anti Patterns @ infoq

An article that I co-wrote with Miko and which takes the work that we did in the SOA Adoption blueprints group (including help from Dan Marchant and John Harby) has gone up on infoq. Apologies to those chaps for the lack of visible credit on the site, I'll take the credit for the original idea though :)

I tidied up the previous content and put it into a more formal structure. And it should be pretty clear that most of the anti-patterns that I see these days are people rather than technology problems.

Technorati Tags: SOA, anti-patterns, Service Architecture

SOA Feng Shui - colours, positions, sizes

My wife Heather and her friend Cath (now Mrs Meyfroidt) one day mocked the number of acronyms that Steve and I talked about by inventing one of their own, namely JFS a little known Java API called Java Feng Shui. Its been something I've used in a few interviews when people claim to know about all Java APIs, and its amazing how often people claim to have programmed using JFS, but can't quite recall what it did.

Anyway the reason for bringing this up is I just saw an SOA architecture diagram which used no colours at all (everything was just blank white boxes) and everything was a randomly different size.

I've no idea what Feng Shui is about, but when you are creating a service architecture do think about basic design principles this means limited (but effective) use of colours, sizes that reflect the importance of elements and visible alignments between related elements.

SOA Feng Shui... it wouldn't be the stupidest thing I'd read about SOA this year.

Technorati Tags: Java, SOA, Feng Shui

Java SE 6 - Sun add more bloat and no more brains

Oh those wonderful people at Sun, just when you thought it couldn't get any worse for those of us who build professional applications... they've decided to lob a DATABASE into the standard build What's New in Java SE 6 Beta 2 (Mustang). On Francois Orsini's blog he comments "I'd like the idea of including JPA" well maybe you might Francois but I can tell you from the JSR group that Sun opposed its inclusion. I made the point at the time that if you wanted to help developers then you'd be better off putting in JPA than putting in JAX-WS and a Web Server.

So the JDK bloats up yet again to please some mythical development market that Sun wants to please. Considering that Sun felt that they didn't have time to add reflection for parameter names into the language (which makes scripting and rules processing harder) its pretty impressive how much time they've found to lump crap that professional developers don't need.

Now of course its "just" the JDK so thank god Tomcat have moved away from using the JDK compiler for JSPs, but this really does indicate that Sun's vision for Java SE is a bloated kitchen sink of a system, with little thought put into the pieces.

As was said in the JSR group on Java SE 6, JPA and EJB 3.0 persistance would have been more useful to the majority of developers on desktop clients and lightweight apps than the inclusion of JAX-WS. Sun opposed that inclusion, but now have put in a bloody database without putting in anything that helps developers to use it. An intelligent organisation would have looked to either include JPA with that database or would have realised that bundling a database and making "Joe Average" developers (Sun's stated target market) work at the JDBC level is foolish.

I repeat my call for a change in approach for Java SE 7, but quite clearly Sun are looking to put in yet more crap... what next? They've put in a web server and a database with scripting support... why not just bundle PHP so people can just do LAMP?

Watching Perfect SOA in action

Watching the World Cup yesterday in a London Pub with the Cliff Richard of SOA and then chatting today with Mike Morris about the game made me think of something.

Football is a great example of perfect SOA in action its

• Dynamic
• Agile
• Constrained
• Goal Oriented

And lots of other positive things that a Service architecture should be. Its an example of decomposition of services as well, with the team containing players, and the match containing teams, refs and the pitch.

It also underlines how in flexible systems processes are less important than the services and the activities. The move that led to England's goal was a pass from Stewart Downing on the left to Aaron Lennon on the right, back to Beckham, cross into the box for Crouch to score. This wasn't a predefined process that was executed to score a goal it was a series of services collaborating to achieve that goal, each service made a decision as to what the next step would be. Thus resulting in a hugely flexible system that could execute multiple different approaches without requiring any reconfiguration or re-deployment.

In Football you've also got the ability as the coach to direct the services in certain ways, putting drivers and principles into their actions (or divers and a distinct lack of principles for certain teams) to help achieve the outcome you want. These directions are not absolute and concrete processes they are guidance to the services (players) on what would be the most effective approaches, it is then up to the services to determine the best route to goal.

The final point it made me think of is that services can have the same principles, drivers, goals, specification and rules and still produce completely different real world effects. Footballers have effectively the same capabilities (kick, run, head, tackle) but the key element is the ability of their capability. As service architectures become more evolved, and particularly when looking at business collaborations the importance of value or capability ability will become ever more critical, unfortunately we currently have no way to really describe such things, its currently just a description of what the capability is.

So Football is the most perfect example of SOA in the world today, and a cracking example how goal oriented services don't need a process to deliver the right results. In IT this is exactly how Agent Technologies and Belief-Drivers-Intent (BDI) services should work, and SOA can give you the ability to understand when process is needed, and when something more dynamic would suit your purposes better. In American Football its much more process oriented so they'd probably be better off with a BPEL engine :)

Technorati Tags: SOA, BDI, Agents, Football, Service Architecture

IBM enter the "package" market via the services door

In Paris IBM announced the IBM SOA Business Catalog which is a catalog of 300 services from themselves and partners which they claim will help kick start peoples technical programmes.

Looking through the services some are pretty abstract or low level (for instance there is a RAS for "Enterprise Patterns") some are service offers and lots aren't the sector specific elements that they claim, just technologies plugged for each sector (look for WBI Adapter for iSeries as an example) BUT its an interesting question as to whether a company like IBM, and its partners such as the "tier 2" package vendors, can start providing services with real business value.

As the technology in this space becomes more commoditised in the coming years this availability of business content is going to be important. It also makes an interesting question when looking to rent or own your capabilities (because at the moment IBM's catalog is definitely in the capabilities not services area) as it could give you another option over the big package vendors.

These sorts of moves make sense for IBM, who've always insisted they won't build packages, as they can concentrate on newer or more niche capabilities and leave the real back-office commodity market alone. It also means that IBM's WebSphere suite will have a real "business content and value" marketing spin to compete against Fusion and Netweaver.

So IBM aren't doing package... they are just looking to provide standard business capabilities.... not quite sure how that will look different in 2 years time.

One aside, the catalog is on a lotus.com website... lotus as the business service arm of IBM?

Technorati Tags: SOA, IBM,Service Architecture

SOA Maturity? SOD IT more like

Just came across this post that tries to describe The Three Levels of SOA Maturity - - now I have to say that I like the Systinet guys and its a good product and governance is definitely a large part of SOA... but I have to take issue with their three stages of "maturity" for SOA

In the first stage companies service-enable their applications using standard APIs. Although the costs are modest, so are the business gains, Erickson says.

So the first stage is "whack a WSDL" a technology first, point to point integration solution. Surely this isn't any stage of maturity in a 21st century technology solution. I know some might argue that YAGNI says that you shouldn't design for mediation from the start, but I call bollocks on that one in the integration space, ripping out Point-to-point calls is costly and messy. This is development, you might claim its Service Oriented Development in IT but its certainly not architecture.

Next up we have

The few companies that have entered the second stage are those that use SOA services to build new or modernize existing applications. Reaching this stage means a company has visibility into who is using which services and a sense of application interdependencies.

Oddly enough for a governance company its about governance and visibility of interaction, but even so its still about technology. This isn't SOA either, its still SOD IT again. This second element sounds like level one maturity was random use of WSDL and its actually at level 2 that people are planning what to whack a WSDL on.

Finally the nivarna of the mature organisation using SOA is...

One limitation remains, however: There is no automated way to ensure changing a service doesn't break linked components, Erickson says. That comes in the third stage, with the arrival of what he calls dynamic SOA.

In this environment a new version of a service would notify consumers about the upgrade, who could then determine if and how they might benefit from the update. If it might cause more harm than good, the consumer could decide to keep the existing service. "It all becomes more dynamic," Erickson says.

Yes folks the nivarna is when consumers have to make active decisions on technology upgrades, using of course a governance solution. Its not about having services that make business sense, having a clear plan and structure or even about having flexible services that can change quickly... nope its about auditing all the changes and ticking an approval box.

Come on Systinet, I know you don't really believe this is the top of maturity tree. The idea that the most mature SOA is a technically driven one where consumers can (have to?) approve WSDL or functionality upgrades is just plain barking.

I know from experience that many businesses just upgrade stuff and you have to cope, that is part of the contract that the service lays down (the expense policy at work has to be seen to be believed for instance). I'm not sure what the fully mature SOA technology infrastructure looks like under the covers, but I know what it looks like from outside... it looks like the business. And this is the difference between SOA and SOD IT. SOA is caring about the consumers, while SOD IT is caring about the technology.

Technorati Tags: SOA, SOA Maturity,Systinet,Service Architecture