Getting Process to work with Service

One of the big questions that comes up over and over again is how to get Process and Service to work together. I tend to find that there are a few keys. Firstly to understand that process is one of the possible "how" languages for defining the implementation of a service. Some services are best defined in process, others can be defined by their KPIs (for instance "increase forcast accuracy by 1%) or by their behaviour (e.g. by using UML). Where process (or any approach) is used there are some key rules

1. Service boundaries are absolute they "how" techniques can
1. Alter internal state
2. Invoke external services
2. They cannot
   
1. Contain activities that are internal to another service

Now for Process this means that the objective of a process is to deliver a capability for the service and an activity in a process is the invocation of a capability on another service or the alteration of the state in a service.

In this way there is no Process to Service mapping, but Service acts as a container for process, and process is the mechanism via which the capabilities of that service are realised.

The next challenge is how to model these processes within a service context. First challenge is the current tools aren't set up to do this, they like to model process as the ultimate goal and they haven't yet got to modelling business as services. This means we have to do a few work arounds. The first option is to use service models, as per the methodology, to indicate the orchestration of services to deliver capability.


If using BPMN rather than modelling the whole end to end process model the overall execution process (the numbers on the diagram) and model EACH of the invocations as individual process. Do NOT try and model this has a massive process with lots of swim lanes. This will make the transition to services harder as these process models will cross service boundaries within one process model. The challenge is to be able to create these end-to-end processes as views rather than as models, again the tools don't really help here at the moment as they are process oriented rather than service oriented.

All this is at the level at which process is a series of activities. This isn't the only level at which process and service need to interact, the other level is where process describes a broad area like "buy" which means all of those processes releated to buying. At this level the terms service and process can be reasonably interchangable because they both are used to describe broad areas. The key therefore is to identify the points at which process stops being about broad areas and about stringing activities together.

In an enterprise model this often occurs between level 2 and 3, but this isn't a fixed point so you need to be careful.

So in summary : Broad area process is pretty much interchangable with service, activity and orchestration processes are contained by services and implement capabilities of those services.

Technorati Tags: SOA, Business Process, BPMN, Service Architecture

Keep the crap out of JavaSE 7

Okay I said that JavaSE 6 wasn't for the enterprise, but hoped that JavaSE 7 would be. Well guess what, it turns out that Sun's JavaSE team want to create an even worse version of Java with the Dolphin release. Yet more multilanguage support, hey why not use Basic... BECAUSE ITS A RUBBISH LANGUAGE, yet more bells yet more whistles and nothing at all for the enterprise customers. The basic idea seems to be that if you lob enough stuff into the basket that it some how becomes better. This basic idea has a fatal flaw, namely that it is bollocks. Its aiming for the "cool" and Joe Average, to tick the boxes and generally create a steaming pile for professional developers and architects.

What do I mean by professionals? People..

1. who have learnt how to search for libraries that do what they need
2. who like to control what the platform their application sits on does
3. who like to make absolute choices in what should be done
4. whose applications are rarely 100% purely the core Java platform
5. who build things for lots of other people to use
   
6. who plan for applications to be supported, not just developed

What I mean are people who use Spring, J2EE, Jini, Rich Client Platform, Swing and are able to make the right choice about the technologies on their project. I'm not interested in more bells and whistles, I'm interested in the following

1. Turning off the stuff I don't need, this means not having to install it in the first place
1. No Midi, Java2D etc in the core. If we need it we'll install it
   
2. No JAX-WS, if we want Web Services we will select how we want to do them
   
3. No scripting - if we need it we'll tell you
   
2. A standard way of describing both the Java standard and 3rd parties libraries I want, and where to get thefromalalala Ivy and Maven)
3. A core platform that is just that the
   
4. few standard profiles that provide a standard base for different uses of Java
   
1. Core Java
   
2. Basic Desktop - no comms
   
3. Full Desktop - comms, video, everything desktop
   
4. Kitchen Sink Java with the whole shebang for those who admire only size and where the JavaSE team can dump the new crap they seem to be so keen on.
   

Right now I'd settle just for having 1 and 4, although I think 2 also has merit. The problem is that big companies, of whatever sort, don't tend to complain about things like this. There is a reason for that, they consider (quite rightly) the technology to be something to use and assume that given they are paying billions for it that people would be trying to deliver what they want.

Unfortunately with JavaSE 6 and it looks JavaSE 7 Sun have decided to go after people with no money, or talent, but lots of noise, and make the world worse for professional developers. So the rally cry starts here, I've already posted to the JavaSE 6 list at my wish and desire for 7 to have a clear split between enterprise and the bells and whistles. There are some supporters but of course nothing as yet from the JavaSE 6 team.

Java is pretty much baked for the enterprise, a few extra things like reflection of parameter names would be nice, but mainly its about the choosing right libraries and frameworks rather than adding more crap into the language and base platform.

So the campaign for Straightforward Java starts now. What we need is LESS in the core not more, but a standard way of getting in those pieces that we need. This is why enterprise people use Maven and Ivy, not Basic.

Technorati Tags: J2EE, Java, JavaSE 6, JavaSE 7, JavaSE

Google Analytics isn't reentrant

Recently I've lobbed Google Analytics onto this site, it started when Andy Hedges put me on his profile, which was nice. Later the same day I received my own code and decided to see if there would be any difference between what the two recorded.

Just slightly, the first one records everything, the second records nothing. Google Analytics thinks that both are set up correctly but just isn't recording anything for the second call. Now clearly this is an edge case, and there is very little point to what I've done. But it does highlight one of the problems with services, namely the assumptions that people make on the consumers. I've no idea how Google do the recording, but assuming that a page only has one report to remove duplications, refreshes et al doesn't seem to unreasonable. Until a muppet like myself comes along.

This is part of the reason I'm a big fan of contracts as it can be used to place constraints on the consumer as well as the producer. In this case the constraint would be "only one tracker per page". Consumers are going to use the service in ways, some stupid, that you didn't expect without a way to define functionally what is acceptable its liable to result in support calls or a loss of confidence in the service.

Remember, consumers won't know its them that's wrong.

Follow-up
Only a day later from the folks at Google....

Installing multiple instances of the tracking code on your site is not a supported implementation, as it may result in incorrect reporting. We are not able to guarantee the accuracy of reporting with this kind of implementation.

So yup it isn't reentrant. It would be interesting to understand what the paticular implementation problem is. Now I have no clue at all how they've coded it but I do know that

1. There is a unique profile ID set before each call
2. The page information is only collected once on the successful stats page (no double counting)
   
3. Google thinks that both analytics elements are working when you check

So therefore I'm going to take a punt that the first thing that analytics does is take the profile ID and map it to a specific site, this is then used to remove duplicates that occur for what ever reason and then the information is passed on. Because the second call however maps to the profile ID it is assumed to be a duplicate and therefore ignored.

I'm not complaining about the service which is superb, but using this to give an example of how consumers do things you don't want, and currently have no way of stopping other than after the invocation. In effect Google is filtering out the data after the fact meaning that the second call has no real world effect, hence by the SOA RM definition is not considered a capability.

This gives an interesting point, is a capability always a capability or is it only from the perspective of the consumer. In this case a non-reentrant capability only exists for a single call and then ceases to exist. Not sure quite how you'd model that.

Technorati Tags: SOA, Google, Service Contract, Google Analytics

There is no such thing as IT Strategy

Its been a rant of mine for a long-time that IT strategy should be consigned to the scrapheap. Unless your companies business is truly just IT, in which case IT = business, all there should be is business strategy and then IT should work out the best way to implement it.

IT Strategy is the thing that decides to build the big "EAI Infrastructure" or "SOA Infrastructure" or basically "cool stuff we'd like on our CV".

If you are thinking about embarking on an IT Strategy project, just stop and ask yourself a simple question:

Is this a strategy for IT or a business problem that needs solving?

If its just for IT then stop, you are about to embark on the traditional waste of money in the creation of Powerpoint, at best, or the spending of millions, or tens of millions, of pounds in pointless IT solutions.

A critical point of the business driven approach to SOA is that it needs to be driven by the business view. This means that its time for the Powerpoint to take a backseat and IT to ask the simple question

What does the business what to do?

All that IT should be doing is looking to solve this problem. This means that IT should be feeding back opportunities for the business that matter to them and not bother with great big strategies that start with the premise that everything can be solved with technology.

IT strategy is for people who want to do Powerpoints. Business Strategy Delivery is for people who want to get the job done.

Technorati Tags: SOA, IT Strategy, Architecture, EA

BEA to solve world hunger

A beauty from the register

BEA to go organic on SOA tools The Register: "Aside from a common look and feel, BEA needs a single composition environment that is simple enough for line-of-business managers to build applications and services that wrap up security, data integration and messaging functionality buried in BEA's AquaLogic middleware layer."

Now I know the folks at BEA relatively well and I doubt that their aim for Aqualogic is quite so high as being the mythical "business people can build IT directly" solution.

Previous claims to this throne include the likes of COBOL, SQL, Business Process tools, UML and lots of other elements. Its undoubtably true that new tools are helping the business get better control over IT systems and make certain, controlled, changes to workflows and paticularly business rules. But using a quote my father was told when he got into IT

"The end to programming is 3 years away, thats as true today as its always been"

The mythical world where business people start doing system mashups to create new organisational dynamics and deploy them into production at the flick of a switch is the philosopher's stone of IT. Its a great sales pitch, but don't bet the business on it becoming a reality. All that happens every time is that IT moves up a notch of abstraction and the business demands ever more complex and dynamic solutions.

Nice marketing line though.

Technorati Tags: SOA, BEA, BEA Aqualogic, The Register, Myths

Selling SOA to the business - its selling

One of the most common questions about SOA that I get is how to "sell" it to the business. Well the first point here is that selling SOA isn't different to selling anything else and certain things apply.

1. Look and act professionally
2. Present clearly
3. Have a clear message that your audience cares about

Its hard to imagine presentations that are worse than some of the ones I've seen in IT. Some of the low-lights I've seen include

1. Lots of words on a slide - then just reading them
2. XML documents on a slide - and reading them
3. Lots of woeful colour use - clashing colours
4. Animations that take ages to build
5. No actual messages - or far too many

And that is just the powerpoints used to explain things, in terms of presentations styles I've seen

1. Heads down and mumbling
2. Dressing like the IT geek
3. Reading from the slides and POINTING and LOOKING at them from a distance
4. Disappearing into a rat hole talking about things that don't matter
5. Talking so quickly that they finish in 1/4 of the time
6. Running over by MULTIPLES of the allocated time
7. Repeatedly saying "I'll answer that on a slide in a moment"

The point here plays to something that Peter Quinn said at the OASIS event, I paraphrase from memory but it was sort of

"If you want to be taken seriously you need to dress seriously and lose the pony tail and sandals"

Now clearly I'd disagree about the hair comment :) and I guess that Jonathan Schwartz might have an issue too! But the basic point is simple, if you want to sell to the business you need to play the game on their terms and approach it as a proper sales campaign in the same way as anyone else in the business has to sell their ideas. If someone from Marketing, Finance or whatever was asking for strategic investment and changes in the way people work they would be crucified if they presented the way most IT people do. IT people don't get crucified, its worse, they get ignored, patted on the head and told to go away.

So if you are looking at selling SOA to the business start by ignoring the fact that its SOA. Think about how you'd sell ANY idea to your business, think about what they want and how your proposal addresses those problems. You need to link your SOA sales campaign to the challenges of the business as they see them and explain how SOA will help solve their problems.

Then when you get that sorted start crafting the presentation, and I mean craft. Don't just lob it together and remember a few key points

1. Pictures not words - reading words off slides is rubbish
2. When you present you are allowed to TALK about things that AREN'T on the slides, the slides should just EMPHASIS certain points
3. Present to them - Heads up, clear voice and look them in the eye like you believe it.
4. If they ask a question - answer it, if you have a slide on it soon then answer it briefly saying "and I'll cover what that means in more detail in a second" and if its the next slide say "I'm very glad you asked that because....", "good question.....", "exactly...." IF THEY ARE TALKING THEY ARE ENGAGED AND LISTENING... don't dissuade them.

There are lots of resources out there to help with crafting presentations (here, here, here, etc) so there isn't much of an excuse. And if your company has a training budget I'd strongly advise that you think about taking your part of it to help you present better rather than learning about that new shiny technology. After all if you convince the business that SOA is the way, you should be able to convince them that the new way needs more training.

Selling SOA is selling, remember that needs it needs to fix your client's (the business) problems, not be about you asking for what you want.

Technorati Tags: SOA, Selling SOA, Steve Jones, Presentation