Chatting about SOA

Well thanks to those awfuly nice people at Sun I've done my first VODcast on SOA, tools and what technologies are hot. Unlike the people on the West Coast I had to do it via a webcam link (cheers to Simon Cook for the help there).

In quite a busy month there is also an interesting article in information age about SOA "who plays, who pays" where I put some of my oar into the debate, but the interesting bit comes from Chris who puts it all in a consistent context. Its a key question on SOA, how do we change the current funding model to make IT more accountable and more successful.

Technorati Tags: SOA, Service Architecture

Shooting the myths of SOA

Over on the Yahoo SOA group list there is some discussion going on including my bug-bear of REST v SOAP. In this, and in some other conversations recently I realised how often certain elements are stated as being the accepted wisdom or an absolute rule. Its not the first list out there, but hell its my own.

1 - SOA = WS, or the broader SOA = Technology

SOA is about architecture this means thinking about the problem and planning. Working out what the services should be and then worrying about the implementation technology. This doesn't mean prancing about doing powerpoint, but it does mean that technology is NOT about the architecture. Technology is about implementation or delivery, Service Oriented Delivery of IT = Technology, so in an SOA world "technology = SOD IT".

2 - Services should be stateless

No they ruddy well shouldn't be. Lets be clear here just because the executable code is stateless doesn't mean the service is. If you store information in a database then the service has state, the consumer of the service doesn't give a monkeys whether you store it in memory, a database, flat files or using the collective unconscious as long as when they call again they know that the service has remembered what they did last time.

3 - Services should be loosely coupled

Again this isn't a sensible blanket goal for an SOA, because sometimes its smarter and more agile to assume that certain services are highly cohesive as they work together to achieve a common goal. Services should be sensibly coupled, but if you are calling a service and using their interface then you are coupled to that interface and will have issues if it changes.

4 - SOA is about reuse

Nope its about use and there is a big difference between the two concepts.

5 - SOA is something I buy

SOA doesn't come in a box, it isn't about technology and you can't just download it or buy it off the internet. SOA is about changing the way you think, its about working differently and thinking of systems in a different way, and most importantly thinking about the business.

6 - SOA is about IT

If SOA is about IT then lets all go home now. We've tried to keep in our little boxes and pretend that the outside world doesn't matter, the whole principle of SOA is that its about the services to be delivered rather than the delivery of those services. SOA is about the business, not about IT.

7 - I've been doing SOA for years

No you haven't, well to be honest there is a possibility that you have been but the reality is that odds are you haven't. SOA isn't just EAI using XML, despite what the old EAI vendors say, and its not just client server either no matter what the analysts might say. Its true that some people have been doing SOA for a while, but the majority haven't. What we are seeing is a collective rewriting of history, which was nicely summed up by Miko in his Defensive SOA anti-pattern. So be honest about it, if you really did think in terms of business services and capabilities then good on you, but if you are saying SOA because you are using technology that came in a box with SOA on it and doing the same thing you did five years ago then it isn't SOA.

8 - Services are atomic

Again no they aren't, first of all they've got capabilities and second of all they might contain other services. So a high level "Sales" Services will contain all of the services related to sales, it might provide a couple of high-level capabilities as well but most of the functionality is going to be delivered by the services that are within it. Services being atomic means that they are at the lowest level of granularity all the time, that just doesn't make sense when you think about how organisations work, Procurement is in Finance, Training is in HR, etc. Services aren't atomic and having this as a goal is dumb.

9 - Services implementation must be hidden from the users

Now generally this is a good idea, but its not a golden rule. Take for instance ordering a product and having it delivered. Hiding everything would mean that you'd see the order go in and then wait. Most decent companies now however enable you to watch the execution of the process through their supply chain so you know exactly what is going on and when things will happen.

So its an okay general rule, but don't think its absolute.

10 - Services are separate from processes

One of the technology created ones, mainly because no products out there enable you to design your service architecture properly, and no process tools enable you to assemble multiple processes behind a single interface. This doesn't mean that service is separate from process, it means the tools are currently rubbish at doing SOA.

Don't start with process, start with service. All process does is provide you with another implementation language for your services.

11 - SOA is heavyweight

There is no denying that some of the sledgehammer to crack a nut technologies out there come under the heavyweight banner and have become associated with SOA. But as SOA is about changing the way we think about systems to make it easier to make the right choices and to separate the different services out so we can deliver them using the right method and the right technology then SOA should in fact be considered as a lightweight approach. It really shouldn't take that long to determine what the services are, and if you can't its a pretty good idea that you don't have a Scooby Doo what you are doing.

12 - Reducing implementation costs reduces TCO

This isn't specific to SOA but its a beguiling myth out there in IT. It says that anything that gets something delivered a little bit quicker means that its cheaper to do. This approach says that if something was scheduled to take 40 days but by doing X you can do it in 30 days that its always good to do X. This misses a fundamental point, and its something that is critical to building a successful SOA, once the service goes live there will be more money spent changing, enchancing, fixing and supporting the service than was ever spent developing it.

If X makes support and modification easier then its a good thing, if it doesn't then you are just storing up problems for the future.

Technorati Tags: SOA, Service Architecture

Why Service Interface != implementation

One of the assumptions that some people make is that if the interface and contract are the same then the implementations must behave in the same way. Sometimes this is manifest in an idea that a service implements one and only interface, other times its just an assumption people make when doing testing or an upgrade.

So here are three examples from Google Maps, the AA and Multimap of exactly the same route request from Trafalgar Square, Westminster, Greater London, SW1 to Trafalgar Square, Gosport, Hampshire, PO12. No particular reason it just seemed like a reasonable test. So the interface for these two is exactly the same when viewed as a service. We have two input parameters and in return we get a list of directions and a Map. Our preconditions (that the places exist) and post conditions (the route is possible) are the same so from any service consumers perspective these two elements are identical. Ignoring the formatting differences of the pages there are a couple of things to note

1. Google Maps is clearly US developed, it uses street names far more than its UK based cousins which focus on the route number (e.g. A4)
2. All produce different distances and times
3. All go via slightly different routes

So from a consumers perspective they meet the post-condition but the ability of the consumer to follow the process may vary based on how the process (route) has been described. Here for instance Google Maps produces a set of directions that are a bugger to use around London as you don't want to be looking for the names of the streets when there is a great big "A4" sign at the junction.

So Service Implementation can definitely differ for a single interface, and regional differences between services shouldn't be under estimated. So when you are looking at that global logistics planning service do remember that people in different countries navigate the roads differently, simply meeting the post-condition might not meet the required business objective. This is one of the reasons that I like to capture business priorities and drivers against actions, so a driver here wouldn't just want "fastest route" they'd want "simple to follow" as well.

Google Maps also demonstrates another rule for SOA, one service implementation can expose multiple interfaces to the world. So as well as routes you can find out who in London is doing service architecture and the stunning revelation that there is no beer in Sydney (tough luck on the aussies today in many ways).

So:

• Same interface != Same implementation
• interface can have more than one implementation
• an implementation can implement more than one interface
• Regionalisation is important, even when you meet all your semantic and functional contracts.
• Services don't have to have WSDL interfaces
  

Technorati Tags: SOA, Service Architecture

Gartner Analyst reveals ignorance

One of the truly scary things about SOA is when people boldly stand up, open their mouths, and make themselves look very silly indeed. Massimo Pezzini, vice president and distinguished analyst at Gartner Inc. sets new levels for this however. Beating out the previous winners who said that "SOA = WS" Massimo goes for the jugular of bad description with the phrase

"the secret few SOA gurus want to let out of the bag: SOA is an update of classic client/server."

AAAARRRRGGGGGHHHHHHHHHHH GNNNURRRRGGGK

Its couched around that "people were doing SOA in the 90s" bit, claiming he was pushing SOA in 1996 and preaching to the converted, but people didn't call them services. I worked on a project in the early 90s where we used the term services, it was 100% not client server as that term meant very little in an environment where event the bit that did the UI was also considered to be a server, indeed everything was both client and server. So yup SOA isn't new (just like OO wasn't new in the 90s), but that doesn't mean everyone was doing it, just in the same way as all the C programmers claiming they did OO was rubbish, so is the statement that client/server = SOA.

SOA is not an update of client server, at least not in my world. SOA is about changing the way you think about systems and having that change the way you implement them.

The good news for Massimo is that he clearly is part of the crowd over at Gartner

"Advanced SOA" might be the term for future SOA implementations moving beyond request and reply.
-- Jeff Schulman, group vice president for Gartner

Advanced or just plumb obvious? That system in the 90s I worked on (or the ones I worked on in the late 90s and in 2000) all mixed RPC with events, throwing in a bit of pub/sub when required and even fire and forget. Not just doing request/reply doesn't make something "advanced" it makes it sensible.

The biggest problem here is that this is what drives the product vendors to get onto the magic quadrants, which in turn drives quite a bit of IT procurement out there. And if people flogging old client/server as "SOA" are now included into the mix then we really aren't going to address the fundamental problem.

The only benefit here is that this underlines the point that if SOA is to succeed it can't be about the technology. These analysts are talking about ideas that have repeatedly failed to deliver on their promises as being the thing to do. This can't be what SOA is about otherwise it will go the same way as all these other technology, and analyst, led pushes... into ignominious failure. SOA is about changing the way you architect your solutions, this means thinking differently and then having that thinking impact delivery. Technology is the thing you add after you've done your service architecture.

Gartner have dropped into the SOD IT trap, confusing technology delivery with architecture. Someone throw them a rope.

Technorati Tags: SOA, Service Architecture, SOD IT, Gartner

Web Service Best Practice made simple

Now while I like to stress that SOA isn't about the technologies and it doesn't have to use Web Services, lets face it the odds are that when you get to the technology its liable to involve them somewhere. There are some good, long, articles out there around all of the challenges and what you should do. But I've used a few simple rules to help me

1. Don’t expose functionality directly, always use a façade
1. Depending on the technology you can then log inside the face, error reporting etc. Some tools have these elements done for you.
   
2. WS-I compliance is a must if you have heterogeneous clients
3. If you are doing transformations, use a mediation approach (i.e. something between you can the caller and the consumer)
4. Publishing is a “phase 2” element for most organisations, don't worry about it
   
5. End points wise, if you are using “standard” J2EE then JAX-RPC (and now JAX-WS) are pretty well tooled up, if coding then AXIS 2 is worth a look.
6. If you are using something other than HTTP be aware that currently both end-points have to be using the same technology stacks
7. Remember that Point to Point WS is still Point to Point, if you are going to be doing quite a few of these then put in the patterns (e.g. mediation and a facade) that make lobbing in indirection simpler
   

Other good practice elements are to define the schema separate to the WSDL so your type definitions are independent (can cause versioning challenges though).

The biggest recommendation is to use a decent IDE with good WS support. In terms of documentation what I've done is design the WSDL and the data structure, then cut and paste the images from the tools of these things into the document. For each method on the WSDL I'd. define (in the doc) the pre-conditions, post-conditions and sometimes the invariant, brief overview of what the service is for and if there are any interaction patterns (call X before Y) then state them if simple (as pre-conditions) or if complex diagram the process. Then the WSDL is an appendix along with the Schemas.

Its not rocket science and from experience it doesn't need to be complex and if you are using REST I'd say that everything but 2 and 5 still apply.

The most important by a mile is the facade rule, it will save you a huge amount of pain over right-click exposing something internal.

Technorati Tags: SOA, WS, WSDL, Web Service

SOA 2.0 what next?

Okay I've been a little quiet on this one, but fair play to the folks over at Macehiter Ward-Dutton they've got some momentum behind the anti-SOA 2.0 bandwagon with their petition, I liked it so much I voted twice (or to be honest I pressed the back button then say "yes" to the POSTDATA dialog). Now personally I'd say that SOA already includes Event Driven elements as that is just one communication style that is completely independent of the basic idea of SOA which is thinking about services and particularly business services.

However one question is why we should worry about a branding slogan, well I think we should not just because when you look at "Web 2.0" people are talking about doing research into collaborative technologies... then it turns out they mean looking at Wikis (imagine being commissioned to do that, researching a wiki... how long would you spend on the beach?). But also because if we start now we'll have a major revision everytime we add something new.

There are two clear worlds here, the one (like the OASIS SOA RM) which talks about SOA as a concept and an architectural element, and predominately focused on changing the way people think about systems. This world considers SOA to be as much about the business as it is about IT.

The second is the vendor world, this is about flogging product, which means shiny buzzwords and a constant desire to feel new. I don't blame Oracle for claiming SOA 2.0, if they hadn't one of their competitors would have. But all of these pronouncements needs to be married to the fact that they are about selling product. "Yes last years product was SOA, but this years is SOA 2.0", hell its even a full number jump so the upgrade will be harder. SOA column inches are currently dominated by this deliberate miscommunication so people need to understand the motivation behind it.

Being rude the challenge I see is this...

SOA by vendors = RPC

EDA by vendors = messaging

SOA by sentient human beings = Business service architectures, structure and thinking differently.

So vendor SOA and vendor EDA are just two communication patterns when using proper SOA.


Why do I say that SOA is about thinking different? Because I have to deliver projects, and if we don't think differently then its the same old crap that failed last year. Why do vendors attach products to buzzwords and generate more buzzwords? Because they want people to buy their next product which needs to appear sufficiently different and important in relation to the last. I want to deliver a project, they want to deliver a product, understand the motivations and you understand the messaging. Why should you take the SOA as thinking message over SOA as product? Well if you want to build a product you shouldn't. If you want to deliver a project however then we are sitting in the same boat.

If we allow SOA 2.0 then we'll get the following

• SOA 1.0 = RPC
• SOA 2.0 = RPC + EDA
• SOA 3.0 = RPC + EDA + ERP
  
• SOA 4.0 = RPC + EDA + ERP + "Semantic"
• SOA 5.0 = RPC + EDA + ERP + "Semantic" + Agents
• SOA 6.0 = RPC + EDA + ERP + "Semantic" + Agents + Business Service Modelling (I hope to god this bit arrives earlier)
• SOA 6.0 = RPC + EDA + ERP + "Semantic" + Agents + BSM + Service Portfolio Management

Now I might be wrong on the list, but you get the idea. With things like Netweaver and Fusion already looking to put ERP into the mix and the rise of the term Semantic we risk descending into a continual stream of updates on what is fundamentally a conceptualisation challenge.

So SOA 2.0? No thanks, not until the technology allows me to create a proper business service architecture and then drive that through my projects and organisation, that really would be something worthy of a full revision number.

Technorati Tags: SOA,SOA 2.0, Service Architecture

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

SCA and JBI, match made in heaven?

A while back Edwin made a post about SCA and JBI and the differences between them. I won't bother repeating what he said, and explained, around the differences between the two. Applying this to the previous post on treating IT as a business domain, where its important not to get bogged down in these technology discussions made me think about how JBI and SCA work very well together in terms of mentally helping people to separate the technology challenge for integrating products (JBI) from the development challenge of invoking multiple business services (SCA).

Having this clear architectural, and mental, separation between these two areas is liable to make architectures based on them much clearer than those who adopt a single approach. SCA wasn't designed to do infrastructure (IMO), while JBI was 100% not aimed at helping developers! Currently IBM and BEA are SCA only in their strategy, while Sun are only JBI. Microsoft of course have neither... its a bit of a hint to the folks in Redmond, don't you think you need a component/deployment approach?

I should put my hands up to a vested interest as a member of the JBI group, that said at work we were also heavily involved in the IBM Process Server beta programme which is where SCA made its debut. Both are good technologies, SCA IMO is brilliant for development, and it will be interesting to see how SAP and Oracle (who have both said they will support both) develop their products in the coming 12 months.

Technorati Tags: SOA, SCA,JBI,Service Architecture

SAP and Oracle - what do you own, what do you rent?

One effect of the package vendors, mainly Oracle and SAP, taking up SOA has been the relentless charge in the number of "services" these companies claim to deliver. Thousands of services are being claimed already by these folks and they both have effectively the same strategy namely:

Middleware on a package, not the world's most advanced architecture but its certainly a start. Both are talking about moving processes into the middleware layer and both are talking about the package becoming the basic services which are then orchestrated in the middleware layer.

What this does mean is that package development is shifting already, and will shift even more in the coming years. If you take something like Salesforce.com as a model in this area, and think about what these packages normally represent then there is another way to think about the diagram, namely that packages represent the capabilities and the real services will live in the middleware. The reason that SAP and Oracle are claiming thousands of services is that they are taking a fine grained approach to what a service is, namely just exposing what they have. This means that to create a proper business architecture on top of these things will require you to moderate access to the package via the middleware.

With SAP pushing Process, and Oracle always struggling to get beyond data, its important that businesses look at how the represent these packages in a way that suits them. Central to this is the idea that the capabilities of the package should be left untouched (as package modification is always a dangerous thing) while your business service architecture should be realised in the middleware.

So don't think of buying Services from Oracle and SAP (at least not yet) think of buying capabilities from them that you can construct into Services. In this way you can get the advantage of standardisation and commoditisation without having to completely adapt your view of the world to the package. A package should commoditise the capabilities of an organisation where it is used, the service should provide a business correct view onto those capabilities.

What all this means of course is that the real value in this world is clearly split. The package represents the reduction of cost by selecting commodity capabilities, while the middleware represents both services the package delivers and the higher value services which undertake orchestration across those services.

So as with Salesforce.com, it begs the question with Oracle Fusion and SAP. Why would you own the package? If you aren't modifying these capabilities but just want to access and orchestrate them in your own way (i.e. provide services) then the only bit that is unique to you is the middleware.

ASP models have been tried before with SAP and Oracle and had variable success (to be kind) mainly because both the capabilities and the configuration was done in the same environment, this made the work harder. With these new models we are able to think about having a clear split, with the package being about capabilities and the middleware being the piece that provides access to it. In that world you don't need to own the package you just need access to the package's capabilities. And if you can drive towards accepting those capabilities as they exist out the box (i.e don't tweak the package) you can reduce or eliminate the traditional upgrade challenges.

As Oracle and SAP move more of their orchestration and (hopefully) start creating proper service functionality within the middleware the dynamics of package development will have been radically altered instead of being a single great big blob it can become a question of:

Rent the capabilities, own the services.

Technorati Tags: SOA, SAP, Oracle, Service Architecture

Services aren't about reuse

One of the often trotted out reasons for SOA is that it enables reuse, now a while back Neil Ward-Dutton blogged about this being wrong. Its this view I'd like to build upon here, with one minor change, instead of thinking of sharing services I think of it as using services.

So what is the difference between use and reuse? Well in the spirit of well known thickie Albert Einstein lets use examples.

• When you finish the christmas biscuits in those big tins that they come in and then reuse the tin to store your receipts, this is (clearly) reuse.
• When you demolish a wall, take the bricks and build a shed you are reusing the bricks.
• When you take a library file and import it into a project you are reusing the library.

Reuse is about taking something and moving it into a different context. This will either change its purpose (the tin) or use it as a piece in a bigger solution (bricks and library).

• When England beat Paraguay on Saturday they will be using the pitch in Frankfurt. When South Korea play Togo on the same pitch a few days later they will also be using the pitch.
• When you order a pen from Procurement you are using them to get the pen. If someone else wants a pen they also use procurement.
• When you include GoogleMaps in a Mashup you are using their functionality.

Use is about using capabilities in-situ, this doesn't mean you can't get to them but that they are left where they are and you invoke them. Mentally the shift is away from thinking of "re-using" a service in a project or "re-using" some code towards using something that already exists, where it already exists.

You don't reuse phones, knives, cars, roads or football pitches, you just use them, so it should be with a well realised service architecture. Don't think about bringing the capabilities within your bounds but of invoking capabilities that exist elsewhere.

Mentally this should also change how you think of building services, it is not the responsibility of the consumer to worry about food, water etc, which is what reuse is about, its the responsibility of the provider to make sure that these elements are catered for. Reuse encourages people to leave such issues to others because it makes consumers understand the lifecycle and make changes based on what they want. Use should be about providing an interface and a mechanism to request change that applies to all, and having all of this managed behind the boundaries.

Reuse tends to focus on functional activities only. Use needs to focus on functionality, the full lifecycle and providing the service to all.

Technorati Tags: SOA, Service Architecture

JavaSE 7 a formal request (sort of)

Okay its time to be clear about what I think Java SE 7 should look to do:

1. Have a standard jar dependency management approach (Ivy or Maven would do)
2. Have a standard mechanism for defining additional elements to download (might that be JNLP?) and where they can be downloaded from
   
3. Have a standard deployment file that indicates the specific elements required for a given application
4. Have the ability to not require/deploy those elements not specifically included

I think that is it for the mechanism, then the second bit is as follows

1. Have a core set of required libraries (maybe as little as java.* maybe as much as everything in Java SE 5)
2. Define a set of standard profiles for three common usage scenarios (server, user desktop, developer desktop) and the ability to dynamically apply profiles (if we can co-host multiple applications then they should each have profiles)

In this way J2EE vendors, and the Spring, Struts, Jini, etc crowds could all define profiles for their applications for different usage scenarios that complement their other deployment efforts, these profiles would indicate what facilities (jar files?) are available to the developers. In this way we could specify SERVER profiles to indicate the facilities available to all, and maybe in time have application profiles to indicate those things that are available to only a specific application.

Now I know some people will argue that in part you could do this using security, but the reality is that most projects work on jar files and then choose what jar files to deploy where, also security means that the jar files are already loaded. So if you think about grid deployments and hydration/rehydration then this gives you the ability to check the deltas that require shifting rather than having to take the whole application context in one go.

Simply put,

• I want to define that my Java Desktop application uses Matisse, Swing, Axis 2.0 (rather than JAX-WS), Log4J and doesn't include Java2D, MIDI support or any form of scripting.
• I want to define that my server application uses EJB 3.0, JAX-WS (the one provided by the app server vendor), Log4J, JSF, MyFaces and no Swing, AWT, JAX-WS (as provided in Java SE 6), scripting, MIDI or Java2D
  

This way Java continues free to innovate (as Bill Joy was famously fond of saying "Most of the smart people in the world don't work for you" something that Sun would do well to remember) while enabling officially endorsed "profiles" and standard mechanisms to enable end users to remain in control of their environment in the way that they need.

For the consumer market sure fine keep pushing the ever bigger bloat out, it will keep the slashdot crowd happy too. But Java is big enough, and professional enough, now and its much bigger than just the JavaSE platform, its time to have a formal recognition of the fact that (to paraphrase Mr Joy) "not all of the best jar files come from Sun".

Technorati Tags: Java, JavaSE 7, J2EE, Spring

SOA and Web 2.0 - not one or the other

There have been some posts out there in the blogsphere and wider world questioning whether SOA is heavyweight or lightweight (and as ever a nice rage against the machine by Dan) the bit I'd disagree with is that its a "Web 2.0 lightweight approach" or an "SOA approach".

Admittedly I'm talking about SOA here as a business concept rather than a technology concept, but that said I think the two go rather well together in fact. Thinking about defining services and then categorising them for delivery might mean that a Web 2.0 with AJAX, monkey nuts and side trimmings of agile could be the right way to deliver a particular service. I've used a 3D grid to try and explain to people that different services require different delivery approaches and to try and break the "one ring to bind them all" approach to project management that often exists.

I like PovRay.... But anyway, part of the aim here is to identify the right software practice (as Dan says one size doesn't fit all) to deliver a given service. For something that is highly visual, interactive with users and needs to integrate multiple external services in a "mashup" type of way then guess what... Web 2.0 with AJAX, monkey nuts and side trimmings of agile could be the way to go.

Equally if one of the services is a package solution that needs almost no configuration and for which the requirements are already known and fixed by the package then you probably don't want to go down the XP route. And if its a business process centric solution like "employee take on" or something with big compliance concerns then again you probably want to pick a more formal method (but naturally one that has iterations).

One size doesn't fit all, and taking an architectural and particularly a business view of SOA helps you pick the right delivery approach for each service rather than trying to shoe-horn one method onto everything.

Its not SOA v Web 2.0, its about understanding the wider problems and understanding what works best where. SOA v Web 2.0 is like arguing Linux v VI, it doesn't make sense. Unless of course its the one that's "vendor bulls***" (how does Tim Bray talk with *s? Must be an XML guru thing) then there might be more of a point, but that is to concede that SOA must be defined solely by marketing hype and never by an actual Service Oriented Approach which is a shame.

Technorati Tags: SOA, Web 2.0, Service Architecture

SOA tools...

I get asked regularly what tools can be used to define a service architecture, and the problem is that most of the big tools in this space are too complicated, too big and fundamentally don't have strong concepts of service in them.

This means I'm afraid that the only tool I can really recommend at the moment for the creation and sharing of a service architecture is a Wiki. Pathetic really but I've not yet come across anything that matches it in terms of flexibility and the ability to navigate the information. It really comes into its own when you start thinking about how process and Service work together as the process elements can link to the service elements via the Wiki.

To draw the images I use Open Office mostly, Visio occasionally and to do the 3D movies and images I sometimes create its down to PovRay. SOA at this level really is a new field from a tooling perspective and while XML, WSDL and BPEL tools are improving there still hasn't been much of a desire to create a business service modelling tool that puts all of those things into context.

Unless anyone can say different?

Technorati Tags: SOA, Service Architecture, SOA Tools