SOA 2.0 comes back... now with added schwaz

Via the Tibco blog I came across this post which referred to a pdf which.... well you get the picture. There is a box which talks about "2nd generation SOA" in there which sounds oddly like SOA 2.0.

The challenge is that these "advances" are still focused on the next set of technologies that people want to sell you and not on making the structural and mindset changes that will actually deliver the benefits.

So not so much 2nd generation as the 2nd set of SKUs.

Technorati Tags: SOA, Service Architecture

Nodding dog alignment - the perils of aligning to people not business

I've seen a several organisations over the years that boast proudly of their business alignment but who still have an unsuccessful IT department. The litany in these IT departments is always the same

We are aligned to the business because we deliver what the business wants

When you delve deeper however what they are actually doing is aligning to business people rather than to the business goals. In effect the IT department just turns into a nodding dog and says yes to all requests made by anyone who can claim to be a business person. This is what leads to hideously configured packages because "the business said so" and to a fragmented IT estate and ever increasing IT spend for ever decreasing business value.

What alignment should mean is actually aligning to the Business Value and then making the tough decisions based on that. If there isn't the business drive to differentiate in an area then don't. Almost no-one will ever admit their area isn't actually strategic so doing what business people say is not the same as IT being aligned to the business. IT is there to govern and manage how IT is implemented and operated that means saying "No" as well as "Yes" and it means understanding the business objectives rather than the personal goals of individuals.

Business alignment isn't about people alignment.

Technorati Tags: SOA, Service Architecture

REST scales? Only if you make it

Last night the "Ramsey's Kitchen Nightmares" programme dealt with The Priory Restaurant and what a mess it was in at the start of the programme..... the website that is. Prime time programme, their URI flashed onto the screen in the first five two minutes and what happened? Oh straight into the not responding territory the website went.

Now this was using a "GET" and we all know that REST scales, so what was the problem? Mr Creswell summed it up when he talked about common sense architecture. So sure REST can scale but it isn't magic. It does various things around state management that can help but it still requires basic fundamentals to be done, its not magic and its not a silver bullet for scalability.

So does the Web scale? Yes. But when Google is allegedly the 4th largest server manufacturer in the world, maybe its not REST but hard work and brains and an awful lot of hardware....

Technorati Tags: REST

Why Unit Tests don't help with crap programmers

I had an entertaining chat a few weeks ago with a rather fundamental agile proponent. Now we agreed on lots of bits where "agile" could help (with me mainly point out that "iterative" and other practices have been there for a while) and then we found a point of real contention. He state that TDD (test driven development) would improve the quality of code for all developer, while I maintained that muppet developers would produce muppet unit tests.

Fortunately we had some empirical data to test this on as we had access to the code base for the project he was running. He had TDD going through out the system and although there were "minor" coverage issues in terms of branches the unit tests were all green and there were lots of them so everything was fine.

find . -name *Test.java -exec grep -A 4 catch {} \;

Ohhh dear the look on his face, very entertaining, the screen began to fill up with statements that looked a lot like this

catch(Exception e){
System.out.println("Test failed");
}

Yes folks a number (4) of his developers didn't have a scooby-doo how to write a decent unit test or how to write decent code and were just "going for green" by trapping the exceptions. The point is that the poor chap had been so used to having a good quality team that he had naively assumed that things that had helped graduates from top line universities improve would also help muppets improve. The problem was that the muppets pair programmed with the other muppets and no-one else in his remote team would pair with the muppets so the four of them ended up regularly changing partners but within a very small, and in bred, gene pool.

The point of this is that there are very few things that automatically find muppets for you and getting them to write more code to check their own code isn't one of them. You still should be doing things like code reviews and you should always be looking out for System.out if you are doing Java.

Anyway he has caught the issue early enough, extended the build to have some more checks and has instituted a weekly code review hour where two developers a week will have to present their code for critique and improvement.

Technorati Tags: Java

Automagically

Reading the Wiktionary definition for automagically left me feeling a bit cold. To me its not a replacement for the term "automatically" its actually one of two things

1. Its something done by IT that the business doesn't need to care about. As in "don't worry we will do that automagically" this means that actually (as in magic) there is an awful lot of work to be done behind the scenes to make the trick look simple.
2. Its what vendors REALLY mean when they say "automatically" with respect to upgrades. What they mean is that you have to do a huge amount of prep, it makes massive assumptions on what you have done previously, including often placing impossible constraints and normally it will fail. In other words (like magic) its actually a lie.

These are two very different uses of the term that I've heard and both are explicitly not "automatically" in the true sense of that word. The point of automagically is when its not automatic at all and either you don't care (case one) or its a lie (case two). Now if people agree I'll update the wiki entry but I thought I'd first check what others had seen.

Technorati Tags: SOA, Service Architecture

Professionalism v the consumer view of Java

Sometimes I read vendor views on a market and just groan. Over at El Reg I read just such an opinion from a Sun employee on Java's future and he is advocating that Java SE 7 should leap down the same road of bloat and anti-enterprise thought that caused Java SE 6 to be an enterprise class dud and not think about upgrades. Chet Haas seems to think that this was a good road to go down and we should lob more into the core including "I said I would also like to see further improvements in the platform libraries, to offer increased functionality and easier programming paradigms." which sounds idyllic but of course he isn't proposing that we remove anything to enable these new, improved(?), paradigms but that we just add more functionality.

The reason for this, and the reason he demonstrates a lack of understanding of real enterprise computing is his comment "Java is what it is and you cannot now start taking things out of it. If you do so, you will break existing applications.". You see here is the issue, people like myself who are advocating removing stuff and creating a minimal core for Java (see this presentation) isn't that we are saying "delete all the libraries from existence". What we are saying is that in an enterprise computing environment where there are billions (tens of billions) of dollars spent on people, education, software and planning that we really can decide what we need and what we don't.

What I want is a minimal core and the ability to add only those libraries and features that I want because I know what I'm doing. Sure if someone wants the full bloat, or as the consumer platform, it makes sense to have the full kitchen sink edition (Java KS?). In the former case because the person can't be arsed to work it out and in the later it gives an assured platform for execution.

This is the problem. People of this mindset seem to see the consumer platform as being the ultimate Java environment the one that really matters and the ones whose problems should always been addressed to the detriment of all others.

Quite frankly it was ridiculous in Java SE 6 the justifications that were trotted out to explain why having things like JAX-WS 2.0 in Java SE 6 and a lightweight webserver made sense. The systems I work on have teams of professionals on them who are better able to decide for that problem whether they need a basic Java SE environment with a web service implementation or whether they are going to use an application server. Forcing these people to undertake hideous class loader workarounds just sums up how divorced from enterprise reality the Java SE 6 decisions were.

The problem is that like many vendor employees Chet doesn't have to cope with the myriad of issues that "everything in the box" creates for organisations. The "just don't use it" line doesn't work when you fall victim to Meyfroidt's Law or to the issues of wanting to use something different to that which comes in the box and suffering the pain of ripping it out (no vendor worries about that). The reality of enterprise computing is that the minimal set of functionality that gets the job done is what you want and you want to restrict people to that as it makes support (where the cost is) easier.

If Mark Baker wants to use REST then let him, if Paul Fremantle wants to use Axis 2 or Synapse then so be it, if someone wants to use JAX WS 2.0 on Java SE 6 their funeral (if they want to upgrade to JAX WS 2.1 then that should be easier than using the older version), if Dan Creswell wants to use Jini then so be it and if lots and lots of people want to use a J2EE application server then fair play to them. The point is that all these people (baring the Java SE 6 muppet) have made an informed choice about what works for them and that doesn't mean we want to see all the stuff that other people are using, if we did we'd download the stuff and use it. This is how professionals work, they make informed choices about what they want to do and then select the right approach for the long term. This is good architecture and good engineering, picking the core of the solution, making it architecturally consistent and then enforcing that consistency. Hey its Mythical Man Month territory again, yes Java SE is that wrong.

For the consumer market Chet has a point, for the enterprise market he does not. One of these is worth several billion dollars, the other is not. Its about time that Java Enterprise users got the standard platform that they need rather than the one designed for Joe Sixpack.

Technorati Tags: Java

What is it with vendors view on time?

There is one fascinating thing that I've seen from vendors over the years and that is their different perspectives on time when the talk about their products. I call it the "Temporal Perception" of a company. The basic challenge is that vendors talk about time as if the only important thing is their release dates and they have two different views on whether that date is in future or in their minds represents the present.

As an example I was talking to a vendor recently about their strategy and they kept talking about their next release (due in 2009) in the present tense. Clearly the development and marketing chaps need to be focused on that release but they were talking about it as if they'd already done everything, boxed it and shipped it to customers. Every question around the current issues and challenges was met with a "We've solved that in X" as if that would help me in the next EIGHTEEN MONTHS before the product shipped. Quite a few companies fall into this group and its easily the worst.

Another group of companies talks about their products in the future tense all the time saying "we haven't done that yet but it is on the roadmap" and then you find out they are shipping it next month but their perception is that anything that isn't already out the door is vapourware. They talk about a month as if its a distant possibility and even next week is just too far out to assume that it will happen. They have a long term vision of what they want to achieve and they'll talk about what they want to do but always in the distant future. This is a very small group of vendors.

Another one just refuses to recognise that there is a world beyond the next six months. Products are either shipping this quarter, just going into Beta or simply don't exist. They won't talk about the strategy and direction and won't admit to anything that hasn't been formally announced and passed through about a million lawyers first. They certainly won't admit that the product they are selling you today will be dead in 12 months. This is sadly common as well and doesn't help customers plan for the future.

I could go on and on about the different views on time and product that vendors have, fundamentally it comes down to their culture and perspectives and tends to fit into these three groups.

This really causes issues for companies when they work with software companies because the one thing that these vendors (except sometimes the ones in the middle group) are never focused on is the time frames that make sense for the customer and understanding the actual issues and challenges of the customer's present. So when you speak to a vendor make sure you understand their temporal perspective and recognise what that means to your relationship with them and what it will mean.

Technorati Tags: SOA, Service Architecture

SEATAC or how monopoly makes service delivery a pain

Sometimes when I look at SOA infrastructures and there are a couple of single points of failure or bottle necks. Security is normally one and often its an ESB or a registry. The point is that all requests go through these elements. Now if they are scalable this can be alright, the challenge however comes if the funding and the KPIs for these areas aren't aligned with the overall goals or even compete with the individual service goals.

What do I mean? Well last Monday I had one of those nightmare travel days going into SEATAC from LHR. First off I wasn't in business, secondly we had a delay due to issues in Iceland so it took longer... then we landed.

The US Immigration folks are a great example of the problem that comes when something, whether in government or in business, has a monopoly over a gateway or access to other services. While the service provision goal might be to get out out the airport as quickly as possible and make it as painless as possible this is nothing to do with the objectives of the immigration (and customs people). Two 747 planes landed at the same time from Europe, to handle the several hundred Europeans getting off these flights there were.... THREE people assigned by immigration to handle the volume.

Seriously THREE people for two 747s full of europeans. This was followed up by customs people who turned the simple task of taking a piece of paper off people into something that generated three queues that were over 50 people deep each. The point is that neither immigration or customs (gateway services) are tasked with helping to deliver the end-to-end QoS that either the consumer or the service provider (airport) wants. This creates a contention point that has no resolution because the actual governance is set up to create the problem. Immigration are tasked on letting through only desirables and don't care if you stand in a queue for an hour (or TWO hours in the case of the unluckiest person in our group).

This challenge is replicated in businesses when these gateway elements are put under IT management and are charged with cost reduction and costed as a single element. This means that their focus is on being cheap and therefore being poor.

What is the solution therefore? Well for the US immigration its probably to notice that European flights tend to have lots of Europeans on them. For businesses its to think of these gateway elements as utilities rather than as cost elements. This means that the cost for them is based on the usage and is linked back to the original consumer/provider interaction. If you want good service as its important then you need to be able to pay for a better SLA, if you don't care about the performance then you get a worse SLA.

Infrastructures need to be linked to the SLAs of the consumer/provider not have a generic SLA that attempts to cover everything and be viewed as a purely cost item in the equation, otherwise they become blockers to change and experience and you end up taking 2 hours to get through an airport and a load of pissed off users.

Technorati Tags: SOA, Service Architecture

How to create customised Business Services on a package

Having said Change the Business not the Package, something I will stick by, there is the problem of what if that package only implements part of a business service? What if you have legislative elements that need to be done or local policies that need to be enforced? What if you need to add in Decision Support? Now the first thing to do if you think this is

STOP

Seriously, right now. Are you really sure that this is special to your business? Because the odds are that what you are really doing is just adding in some customisation for the hell of it. Can you change your business to fit the way the package works?

Now lets assume that you actually do have a good reason to have some differentiation in this area, how do you add in customisation? The answer isn't rocket science its simply

• Treat the package as an integration point
• Put customisation in.... a CUSTOM application

This is why SAP has Netweaver and Oracle has Fusion Middleware (I'm still surprised SAP aren't going after BEA) and of course why lots of other integration and middleware stacks exist.

So what you look to do therefore is to use the interfaces that exist on the package as the integration points for these new customised applications. A basic rule of thumb is always use mediation when communicating with the package, or between different services. Another good idea is to think of the business services that are exposed to the enterprise as not always being straight one-to-one mappings to those definitions from the package. This might be due to data schemas but most normally will be because the package has lots of interfaces that are fine grained and you only want to put some coarse grained services out there for the world to use.

The other bit on the diagram is that business service areas may combine information and function from a package with that from other applications either via a composite application or just by creating a facade over different applications to create a single consistent business view for the enterprise.

So the basic rules for package customisation are

1. Don't
2. No seriously don't
3. If you have some differentiation then put it outside the package
4. Consider the package as an integration point
5. Don't customise the package itself
6. Think of the business services to be exposed
7. Remember that a business service can contain information and function from multiple IT systems.

So customise in the middleware, this is what these platforms are designed to be good at.

Technorati Tags: SOA, Service Architecture