IT is a fashion industry

You know when people laugh at the fashion industry for saying that 'blue is the new black' and because of its ridiculous amount of fawning over models, designers and the like?  Is that really different to IT?  We've got our fashion houses - Google, Facebook, Apple.  We've got the big bulk conglomerates IBM, Oracle, SAP, Microsoft and oh hell the fawning that goes around...

I'd say the comparison goes even deeper however.  EAI, Web Services, REST... what are these?  They are all integration approaches.  EAI was going to save the enterprise and create a well managed estate that the business could use and could be changed easily and enable integration with external companies... Web Services were going to save the enterprise by standardising the interfaces enabling a well managed estate the business could use and could be easily... REST was going to save all of IT by enabling interfaces that could be dynamically changed and enable integration...

The point is that the long term challenge is the same, system to system integration, yet we have fad based approaches to solve that challenge.  Its like the fashion industry and dress lengths, it goes up and down, but its still a dress.  The real difference in IT however is that the fashion industry does this better, sure they change the hem, but it still works as a dress.  In IT we concentrate so much on the hem length that we don't even bother with the fact that system to system integration appears to be as hard in 2013 as it was in 1999.  We even know why, the Silver Bullet tells us that technology won't solve the problem on its own.  But do we listen?  No because we are followers of fashion.

This analogy to fashion applies to the age discrimination in IT, we love the young and shiny, and age discrimination against new entrants is wonderfully not present.  However the flip side of that is there is an over emphasis on the new in IT, so we prefer doing things in 'new' ways rather than in 'working' ways, and unlike in the fashion industry we don't actually learn from sales what is successful.  If we've got a fad (hello REST) that works in some places but not in others we'll keep on pushing that fashion even as it fails to set the world on fire.  Its the emperor's new clothes effect, and in IT we do the equivalent of the beauty industry.  In the beauty industry you'll see adverts for 'age defying creams' advertised by 16 year old models.  In IT you'll see enterprise solutions pushed by using Google as an example.  We love the new, we love the young, and we really rather hate facing up to the fact that IT is quite an old industry now and 90%+ of the stuff out there is a long way from new and shiny.

The analysts and vendors are the Vogue and Fashion Houses in this world, the pushing of the new as the 'must have' technology and dire warnings if you dare to actually make the old stuff work.  The concentration on the outfit (the technology product) and little about how it actually works in the real-world (operations).  You know when you see outfits at London, New York, Milan or Paris fashion weeks been shown on the news under the 'what madness do designers think we will wear next' section.  Is that so different from an analyst or vendor pushing a new technology without explaining at all how it will fit into the operations of your current business?  We will see things like people declaring the end to SQL... and then a few years later those same people championing SQL as the approach, now that they've realised people can operate their technology if they do that.

The final place I'll talk about IT and fashion is in the 'rebadging' that we see.  In the fashion industry you see old ideas rehashed and pushed down the catwalk as being 'retro'.  There is at least some honesty in the fashion industry as they talk about it being inspired by an era, when we all know what they mean is 'I didn't have an original idea, so I copied one that was old enough that people will think its original to copy'.

In IT we don't even have the honesty of the fashion industry, what we do is see a new trend and claim that old technologies are actually part of that new trend.  We'll take an old EAI tool and slap on an SOA logo, we'll take a hub and spoke broker and call it an ESB.  This re-badging of technology goes on and on, sometimes you'll be in a meeting and suddenly realise 'hang on, I used that 12 years ago... how the hell is it now new?'. This would be fine if the focus was on building a robust product, but too often its just about how to get on an RFP and shift a few more units with actual investment in new approaches being few and far between.

IT and the fashion industry are miles apart in many ways, but the faddish nature of our industries make us very similar.  The problem is that fashion is allowed to be faddish, its not expected that a business will rely on something made 20 years ago but with IT this faddish behaviour is a big problem.  We are meant to be constructing systems on which a business can rely, not just today but 5 years from now and still be leveraging in 10, 20 or even 30 years time if its well constructed and does the job well.  There are mainframe systems out there doing exactly that, and why haven't they been replaced?  Because the new stuff didn't do the job.

IT needs to stop being like the fashion industry and more like the aircraft manufacturing industry, sure they have 'fads' like an all composite aircraft, but that is based on sound data as well as strategic vision. Its not just based on it being what the cool kids do.   We can do the cool stuff, we can do the new stuff, but we need to recognise that there is lots of stuff out there that needs to change, we can't just use Google or Facebook as references or examples, that would be like Boeing selling a plane technology based on what people did in movies, its just too far removed from the enterprise reality.  We need to stop blindly following IT fashion and start critically appraising it and shouting 'emperor's new clothes' when its bullshit.  Most of all we need to look at enterprise technologies based on how they improve the 'now' not based on 'if only we could replace everything', evolution is the revolution in IT.

Its time for IT to grow up and take responsibility for the mess we've created.

Dumb IT: We've already got some licenses for this

There are certain phrases that fill me with dread. 'We are using Agile so we don't need to have a vision, we'll just iterate', 'there are no data quality issues', 'We're the first people to use this' and 'The vendors roadmap says they'll do X in 2 years so it will be fine by the time we need that'. One however is completely variable in the fear it introduces because it comes in three clear flavours, one good and two bad.

'We've already got some licenses for this'

What this means is one of three things

1. We need to do something and a technology we know well is ideally suited where we fortunately don't have to buy anymore licenses
2. We bought an enterprise agreement when we bought product X and the vendor allows us to have a few licenses for Y and Z as well
3. I've spent a load of money on licenses for this and we are damned well going to use them

Now clear the first one is fine, this is for example where new functionality is being delivered for a website and the number of CPUs has to be increased.  The later is of course clearly dumb and often is the driver behind IT centric projects that burn money.

The middle-one though however is the most dangerous.  I've seen this over, and over and over again.  A company buys the flagship product from a market leader in a specific segment.  That market leader also has some other products which are either early to market, non-strategic or just plain a bit rubbish and to 'sweeten' the deal they include a bunch of licenses for them and offer this up as value.

A few weeks, months or even years later a project comes along which needs to do a specific thing.  Suddenly someone remembers, or most often pushes, that there are some licenses on the shelf that do that sort of thing so brilliantly money can be saved.

Let me recount a story of just such a decision....

In 2001 I was working with a company who had bought a enterprise package solution from one of the market leaders in the CRM space.  As part of this 'deal' the company was allowed to use up to 4 CPUs of any other product from that vendor.  We had to produce a website to enable consumer to interact directly with the package and this was well before .com front-ends were normal practice.

'Fortunately' the vendor had a new product to do just this, it was new, it was shiny and it was covered by the 4 CPUs.  The alternative was to spend about 6 months developing something custom with about 5 people and despite some heavy cautioning from me on adopting a brand new, unproven technology that looked rather rubbish when I investigated it the company decided that it would be cheaper because of those 4 CPU licenses....

18 months later and with an average team of around 15 people and much hacking, cursing and challenge the site went live with a fraction of the envisioned functionality.

So that 4 CPU 'saving' had in fact delivered a 20 man year cost increase and less functionality.

Want another?  How about the company who used some old EAI licenses and found out half-way through the project that the vendor was discontinuing the product?  How about the company who used the limited number of Web content management licenses and found that 10 years later it was a drain down which millions had been poured... seriously I could go on and on.

The point here is that lots of IT seem to account for license costs in a completely different way to people costs.  Something that saves [£€$]10 of license cost is good even if it delivers 10x that in additional people costs.

The solution is simple, when you look at a programme evaluate the total cost of ownership of the solution not just the immediate cost of buying licenses.  Cheap today is liable to be expensive tomorrow and potentially extortionate the week after that.  TCO is all that should count in these decisions but normally the lure of 'free licenses' outweighs the rationale of 'that isn't the right tool for the job'.

Now that really is Dumb IT

Technorati Tags: SOA, Service Architecture

2010 the year of flexible packages

Lots of people make predictions but I'd like to make one that I haven't seen around.

For quite a few years there has been Package + Middleware but people have still been running it as middleware + package. So the middleware folks do CI and the package folks... well the package folks don't. This is a generalisation and a few, very few, people are doing full CI with a package infrastructure but its still two worlds.

Here I'm talking about SaaS or traditional package it really doesn't matter. What matters is that I'm beginning to see more and more people actually concerned about how to do things like CI and TDD in a package environment. Now what would help with this would be a few things

1. Package vendors to ship their unit tests
2. Standard VM building tools integrated into package suites
3. End-to-end deployment tools
4. OSS support for packages (i.e. Hudson, ant, etc)

The point is that SaaS and packages need to start having the development rigour that custom development packages have and they should have this more explicitly as they have already developed end-user functions.

So its a little question: Why don't vendors ship their Unit and SIT tests?

2010 is going to be a year when hopefully a bit more technical professionalism comes into package delivery and maybe the business professionalism will rub off on the middleware chaps.

Technorati Tags: SOA, Service Architecture

Supported doesn't mean you can get the same support

When you are down and dirty with a delivery project it becomes clear that there is a difference between when a vendors says something is support and the actual ability of that vendor to support you when you have a problem.

You often see this when a vendor supports "interoperability" with solutions from another vendor, even if they have a competing product. Sometimes this support is genuine and other times its what I'd call "sales supported" in other words you'll be able to get it running in the sales evaluation process but if you have a real nasty operational problem the level of support is going to go off a cliff.

So as a few "theoretical" examples.

Lets say Vendor A produces a product which is some sort of middleware thing and while they have their own rules engine product they also support products from a number of different vendors through "standard APIs". The demos work fine in sales and you choose an engine from Vendor B but in operation you start getting a really tricky problem

Vendor A says "its a rules engine problem, speak to Vendor B"
Vendor B says "its an integration problem, speak to Vendor A"

The problem is that you then waste a huge amount of time proving whose problem it actually is.

Next example would be where Vendor A produces a COTS package and says it runs on 20 different operating system environments. You have some older kit hanging around and its on the supported list so you go for it. Again the demo works fine and the first release is fine, you then try to upgrade and it goes horribly wrong.

Vendor A says "errr the support person for that is on holiday, he'll be back in a week"

The point here is that "supported" technically != "supported" operationally.

When evaluating products you need to be aware that there are preferred products that the vendor might not tell you about as they are worried about losing the sale, so they stand their saying "yes it will work" with a smile on their face.

Technically this is known as "grin fucking" as the smile is to cover the fact that they know in reality its going to go horribly wrong.

So when looking at product to product integrations and the level of operational support that you can get start asking questions

1. What proportion of the support staff are dedicated to this product to product interaction
2. How many people is that globally
3. How many people is that locally
4. Will you sign off on our operational SLAs around this supported product, including penalties

The objective here is to get to the stage where you have something that is as supported in operation as it is through the sales cycle.

do not believe supported product lists they are there to make you buy the product, what you want to know is what it takes to operate the product.

My preferred approach is to ask the following questions

1. What OS do you develop on
2. What products do you use to develop your product
3. What are the standard integrations that the product developers use as a normal part of their day job

These are the things that will really work and which have the largest number and highest quality of developers ready to fix your operational problem. The less gaps you have between the people who code your product and the runtime in operation the better.

The best support you will ever get is when the product development team can come straight in because your environment matches theirs. This means your future requirements are more likely to match their thinking and your current problems are easier for them to recreate.

So again, don't believe supported product lists and find out what the product developers are using.

Technorati Tags: products, vendors

In praise of vendor shipped AMI's and virtual machines

Roman Stanek is one of those guys who consistently gets things right and his point around AMIs and Virtual Machines not being SaaS is absolutely 100% spot on. These aren't SaaS solutions they are PaaS solutions and they do indeed leave a huge amount of work for the developer to do. Part of the problem is of course that the name Software as a Service is of course wrong its really Service as a Service that you are buying.

So that said I do disagree with him that shipping AMIs is just the same as shipping DVDs for one very very big reason

AMIs and Virtual Machines must run

This for me is a big leap forward from vendors as while it still means that I have to build my application I don't have to spend days or even weeks trying to install software that quite clearly has never been tested from the DVD or downloads that they have on the site. Some wonderful pieces I had in the past include

• A software & hardware manufacturer whose software worked on competitors operating systems but not their own
• A software vendor whose instructions for connecting their two products had never been tested... I know this as it did not work at all
• Spending 2 weeks installing from DVDs and downloads from a vendor and eventually having them on-site trying to do it for themselves, failing and then "getting back to us" a week later with an installer than actually worked
• A single software vendor whose two products that were required to work together required two differently patched versions of the Java runtime
• A vendor whose installation DVD was missing some core jar files, which they denied at firt but the old "Class not found" exception was a bit of a give away

So I'd like to praise AMIs and vendor delivered virtual machines for the basic progress that at least now it is spectacularly hard for a vendor to ship a non-working image. It might be an ugly image with lots of hacky patches required, but at least they've had to do all that dirty work and not you.

So don't con yourself that you are doing SaaS, you aren't you are doing PaaS at best. But do rejoice in that vendors are at last forced to prove that the software runs before shipping to you. Having a vendor delivered AMI or virtual machine that doesn't run really would set a new low bar in the sorts of quality that they expect customers to put up with.

So I say hail this new move away from DVDs and towards images, because personally I'm sick and tired of debugging their installers.

A note to vendors on the Church Turing Thesis

At work I regularly get vendors throwing about words like "unique", "revolutionary", "game changing", while of course promising to reduce costs, increase agility and pretty much everything else bar world hunger.

I normally ask standard questions in reply at this point, mainly about what it build upon. What really annoys me is when people then say "its completely new".

No it isn't, its an evolution of something, it might be a clever idea but its not going to be a completely and utterly new solution that no-one in the whole world has ever done anything like it before. Let me introduce you to the Church Turing thesis

Every effectively calculable function (effectively decidable predicate) is general recursive

In other words just TELL me what you are building on and I will have a lot more respect and a lot more interest than just telling me that it is 100% new and original. Snake-oil salesman try that approach a decent vendor should know the roots of their product and be able to explain the previous things that they have built upon. If Isaac Newton was admit standing on the shoulders of giants then a software vendor had better be standing on shoulders of something if they want to be credible.

Your product might be great, but if you can't say from where it comes then I'll just cry snake-oil and ignore you.

Technorati Tags: SOA, Service Architecture

Will the Credit Crunch kill the hype?

At the Netherlands Java Night 08 I moderated a discussion on Java futures and chatted with a bunch of people doing real, and large, Java projects. The overwhelming plea was "please stop the hype and the crap, lets make it work properly first". Now with the credit crunch this got me thinking about what a credit crunch could mean to IT spending.

Now apart from the obvious of more outsourcing there is the impact on technology selection, namely not as much new product being bought and a focus on the TCO more than just the development time. Now this could be a very good thing for SOA programmes out there as it helps them focus on what really matters and away from technology bells and whistles and helps them to upgrade slower and thus have more consistency and thus reduce their governance and overheads.

The other bit could be its impact on things like scripting and the various other language developments going on at the moment. These are great if there is loads of cash to spend on investigating new things but not so good if you are interested in keeping your TCO down (which is aided by consistency more than by technology) and don't want to spend loads of cash training people in something new.

Clearly the credit crunch isn't a good thing, but there could be some advantages in terms of its impact on IT spending and in particular its impact on practicallity over hype. Less of the big software purchase and random building where there is no value and more of a focus on repeatable and measurable reduction in TCO.

I can hope anyway.

Technorati Tags: SOA, Service Architecture

IT Hype and the valley reality distortion field

One of the problems that I have in my job is the problem of IT Hype, most especially the huge distortion field that appears to fall over Silicon Valley. When I'm working with companies who are going through a procurement phase its amazing to see this field spread across the globe via the blogosphere. Its the sort of field that tends to ignore companies like IBM or SAP because they just can't be encompassed within this idea that everything must come from the valley. So how do you get around that problem and make sure you make a smart decision?

Now its certainly true that the valley does have a disproportionate impact on IT, its a pretty small strip of land to have given birth to the likes of HP, Sun, Oracle, BEA, eBay and Google. That is damned impressive. The problem is that when you are looking for really good small companies to work with I'd argue that the bullshit to content ratio is never higher than in the valley.

Recently I've been looking at companies in a few spaces recently, which unfortunately I can't go into, and I've started to come up with a valley weighting system of how to score a company before you even go and see them, this is for the small guys not the established guys

1. Current Revenue
2. Current Customers

These two numbers give you the base line for the company, divide revenue by customers and this gives you an average spend, what you are looking for here is companies that appear reliant on a single customer. i.e. if they are talking to you about $40,000 spend and the average is $100,000 then either everyone loves it, or they've got a big marque client who they care the most about. Very common in finance this problem.

1. Projected Revenue
2. Projected Customers

This gives you where they are expecting to get. Again divide the two to see what the future spend per customer is, also look at current/projected for revenue to see the growth path.

Now we factor in the valley factor

1. In the valley - Bullshit factor = 5 year growth projection * 0.5 (i.e. if its 10x growth in 5 years, bullshit = 10)
2. West Cost - BF = 5 years *0.3
3. Mainland US - BF = 5 years * 0.25
4. Europe - BF = 5 years * 0.2
5. India - BF = 5 years * 0.15

This gives you a basic financial BF which should then be weighed against the hype. Basically for each post on Digg or Slashdot add another 0.1 to the BF. Then look at the length of time the company has been around and not cash positive, add 0.2 BF for each year, finally look at the length of time the company has been around and not grown at similar rates (i.e. they are predicting a hockey stick graph after ten years of solid 5% growth), add 0.3 for each year of growth that just doesn't fit the projection.

The final BF then gives you the amount of convincing you should take in order to believe anything they say. If they have a BF of 1 then they need 1 reference for every point they make. If they have a BF of 5 they need 5 references.

Part of the reason for doing this is that these new companies often look shiny and its important not to get caught up in the hype. As an example of hype v reality its quite funny now to look at transmeta and ARM now. Back then in 2000/2001/2002 they were the darlings of the Slashdot crowd and when I went to the valley the talk was about how they were going to completely dominate then chip market. Meanwhile a tiny company in the UK which had been doing chips for years and growing strongly continually had made a move into licensing IP and moving into the mobile phone market. Now in 2008 their results look a bit different, revenue for transmeta in the 2nd quarter failed to break $400k revenue while expenses nearly hit $2m, ARM meanwhile struggled by with $128.1m revenue and a healthy pot of cash.

What has this to do with SOA? Well really its to do with T-SOA, WOA and all the other things out there. When you are looking at companies as part of a long term strategy you need to know that they are going to be around in 10 years time and still helping you evolve, otherwise you are doing something as a point solution and will accept that support and maintenance is your own problem. You also need to figure out whether that wonder technology really is amazing or is just some empty hype, the more amazing the claim, and the growth predictions, then the more evidence you should be asking for.

The other point is that what you are saying is that if you think their business model doesn't stack up but the technology does that you will need access to the technology when they go bust. This is why lawyers invented escrow if you want the tech but don't trust the model then make sure you get the rights to access the code (or other tech) for your own purposes if (when?) they go bust.

This is part of that shift about moving IT away from technology and into a business frame of mind, it means not following the hype but following the numbers.

Technorati Tags: SOA, Service Architecture

Reminding vendors of previous statements

I had a call the other day where the vendor said something that made be bork. They were talking about what "non sophisticated" IT users (IT literate business people) can do. During the course of this the vendor (who sells quite a bit of stuff) said that "Web Services" were usable by end users in their BPM product as they hide the XML because XML is too complex and its easy for these users to "string together" Web Services to build new applications

The next chap then came on talking about some stuff that accessed databases and said that "Web Services and XML are too complex" for this type of user group. What these users want is access to the database and the ability to query and filter the information, its all about the information for these users.

The next chap was then talking about ATOM and said that "Web Services are too complex" and that "people don't want to see databases" but that XML was a "natural" way of thinking about data. What the users want to see is the relationships between information not just the data and filtering. They don't want to build new applications they just want to re-purpose what they have.

In the area of "business users can use X" its the biggest lie that vendors push out. SQL was that thing and so was COBOL when it kicked off. I pointed out on the call that they'd just undermined each of their other products with their statements.

You could have heard a penny drop.

The reality is that different products work in different areas and different tasks require different solutions.

Its also fun to remind vendors of when they told you that X was the best thing and that the right approach was to do Y with that X. Now they are saying that Y (and maybe even X) is wrong, point it out to them. If they want to sell you something they should have a good answer as to why the world has changed and it shouldn't just be about buzzwords.

Technorati Tags: SOA, Service Architecture

SOA Vendors 2008 - A survey

For the last couple of years I've done a vendor assessment on what I thought of the various vendors. This year I've decided to do a Web 2.0 style ;) of thing as well. I've put online a survey form at http://spreadsheets.google.com/viewform?key=pz8YmsABxikMi-h8lTZTuQA where anyone can add in their assessment of vendors and how they are doing. What I will do once there is a reasonable bit of data in it is start publishing the graphs in summary form first and then at the end I'll release all theinfo so anyone can have a look at the raw stuff.

If there are any vendors I've missed off who matter let me know.

Cheers for the help

To be clear on the scoring - 1 = Rubbish or zero functionality, 10 = PERFECT and could NEVER be improved

The odds on a ten are pretty low.

Technorati Tags: SOA, Service Architecture

Vendors move away from SOA, can we get on and do some work now?

Over the last few months I've seen a very nice shift in the focus of software vendors away from SOA & Business Process towards their next piece of string, Complex Event Process (CEP). Now this is being pushed as "part of SOA" but this is really great as it really focuses the vendors as being in the technical SOA space over the business SOA space. Oracle are focusing on the Grid infrastructure for scalable and reliable SOA infrastructures. These are all very positive things as they more firmly underline the difference between the technology enablement of SOA from its business definition. This is a very good thing^TM as it highlights the missing area much more effectively than the confusion that was caused by the Web Service and BPEL focus that claimed to be business oriented but in reality was not.

This represents a real evolution of the T-SOA market, in particular with Oracle focusing more on the operational side of the technology over the bells and whistles approach.

Now the question is can SOA as a business concept be revived and establish itself as the way to think and deliver SOA with the vendors providing simply the platform on which it operates.

Technorati Tags: SOA, Service Architecture

Boothware

I'm doing some reviewing of JavaOne presentations at the moment (SOA/EAI) and the number of vendor presentations that are basically a booth demo where they'd like a bigger audience is just staggering. Sometimes they are dressed up as an "investigation" but most of the time its literally a standard booth demo (even including "how to install" on occasion).

Death to Boothware.

Technorati Tags: JavaOne

Why corporate IT means something

Over on Joel on Software there is a post about his talk at Yale where he warns people not to go into "in-house" corporate development because its soul suckingly bad. Why?

Number one. You never get to do things the right way. You always have to do things the expedient way. It costs so much money to hire these programmers—typically a company like Accenture or IBM would charge $300 an hour for the services of some recent Yale PoliSci grad who took a 6 week course in dot net programming, and who is earning $47,000 a year and hoping that it’ll provide enough experience to get into business school—anyway, it costs so much to hire these programmers that you’re not going to allowed to build things with Ruby on Rails no matter how cool Ruby is and no matter how spiffy the Ajax is going to be.

"No matter how cool Ruby is", "Spiffy"?!?! this just about sums up why vendors don't understand their customers. Now most companies I've been in are doing just those sorts of things and are doing it when it makes sense and the people doing this tend to the leading IT lights of those companies. Having worked with lots of product companies as well I can safely say there are legions of developers in those companies who certainly don't have the ability to choose a new programming lanaguage and who are never going to lay their hands on Ajax. So maybe the issue isn't corporate development but the sort of development that Joel did when he was in a corporate.

You’re going into Visual Studio, you’re going to click on the wizard, you’re going to drag the little Grid control onto the page, you’re going to hook it up to the database, and presto, you’re done. It’s good enough.

Now apart from the last bit (which after all is just smart engineering over turd polishing) this does sound frighteningly like average development. There is a bit around never having time to do quality and refactor to your hearts content but that really does miss the point as I've never met a good developer who ever thought what they had produced couldn't be improved.

Now, at a product company, for example, if you’re a software developer working on a software product or even an online product like Google or Facebook, the better you make the product, the better it sells.

Ahh I know Joel is talking to students here, but is lying really the option? The best software sells the most? Only if you define best as sells the most. The history of software is littered with examples where better software was ignored for inferior fare. Hell in IT it often seems that we deliberately go for the worst option out of some sort of perversion (C v Ada syntax for instance). The implication here is that product software is the best quality. My experience has always been I've never met a piece of commercial software I couldn't break. Things like having a messaging product, Java VM, Operating system and hardware all from one vendor and it wouldn't work at all not as in a slight issue but as in they could never have tested it because it didn't work in any way whatsoever. Things like vendors shipping software products without decent test tools being available. Things like evil class loader work arounds due to vendor stupidity. Things like Rational XDE which came exactly from people "optimising" (the new stuff is soooo much better and started from a different place IMO).

Corporate in-house software on the other hand is designed to do a specific purpose and when it does that thing it works. There are less edge cases to worry about and you have a defined reason for doing it. Now there is indeed lots of crappy inhouse software in the same way as there is lots of crappy vendor software the question should be really about comparing the best of corporate IT with the best of vendor IT. Now excluding the "found your own IT company" which is always the best if you can pull it off the question is which is better to work for?

Now the problem is that Joel clearly worked at a crappy job in the crappy part of an corporate company. He complains about the pay and conditions and seems to think that software companies always have the best perks. This isn't true for several reasons

1. Societal balance - by which I mean women. Tech companies are male domains and the male/female ratio is normally completely dreadful. If you work in a corporate then the odds are this will be much more balanced. This makes for a better social life
2. HQs of corporates are better than tech companies. I've been to lots of the supposed "best" tech company offices and the HQ of a pharma, bank, oil company, airline or even traditional manufacturing company tend to be miles better. Now only the best in IT get to be at HQ, but were you planning on being average?
3. Flying - The policies at most vendors appear to be "coach unless a VP" whereas in corporates it tends to be "we are in business so we fly in business".

So a clear win for the corporates on that one. The next up is the worry that you can't become the CEO if you work in a corporate in IT. Now this is pretty fair, but you can become the CIO and be responsible for a multi-billion dollar budget which doesn't seem too bad and given the choice between that an CEO of a small product company then I have to say I'm with the CIO of a large corporate. Lets be generous here and say that the vendors win this one.

Next up Joel talks us through his hell hole job at Viacom. It really does seem that he was a completely unempowered programmer and this is a crap job at any company, where he makes the mistake is thinking that these people don't exist in vendors. They absolutely do and they have many of the same issues. Field sales engineers are good examples, often very talented but having to put up with whatever is thrown at them from the mothership. The point here isn't corporate v vendor but empowered v munchkin, and you don't want to be a munchkin.

So the question in terms of what is best is what sort of impact can a good and empowered person have on a corporate or a vendor? In this day and age I'd say that the impacts are pretty similar. The key is finding what matters. With a vendor company you could take them into a new market and you can do the same in a corporate, with a vendor you could create a competitive advantage over the field, something you could do at a corporate. The point is that these days when decent companies look at changing the game they make sure IT is in that decision. Its a good place to be.

The real reason to me that corporate IT is a great place to work, if you are good and have good communication skills, is that you can actually see what you do make a difference. I'm incredibly proud that I wrote software that means air traffic controllers can do their jobs and be alerted quickly to any collision risks. Now sure the folks who wrote the graphics library and the OS, the software vendors, had a part in it but it was me who brought it together and gave it purpose.

Corporate IT is the point of vendor IT. Vendor IT is there to make money and its the corporates that it predominately gets this from. This means that while as a vendor you can say "look at our shiny app server" or "look at my bug tracker" the only point to your software is if some corporate people turn it into reality. Thus its corporate IT where the real achievement is. Software Vendors provide the bricks and mortar, they quarry the stone and provide you with the rough hewn pieces for you to carve and give purpose to.

The key in corporate IT is to be one of two things. Firstly you could be very talented and looking at real edge challenges (for instance forecasting in retail & supply chain) where you'll have to push the boundaries of technology to the edge in order to stay ahead of the game. Secondly you could be the person tasked with sculpting a result out of all the raw materials of people and the software the vendors provide to create a new solution to a business problem. This is where, IMO, the greatest challenges and talents in IT are. People who can understand technology, people and process and bring them together. Making people think in different ways, using technology in ways the vendors hadn't expected and doing this all successfully to a properly formulated business case. That takes talent.

The majority of the hardest technical challenges I see in IT are in the corporate space. There are of course challenges in the vendor space, especially where the sale is direct to the customer (but is Amazon really IT company or a next generation retailer?) but the challenges in the corporate space are just as large and hairy and often just a lucrative. The hardest challenge in IT however is the same as it has always been, how to take multiple technologies and large numbers of people and deliver a system, changing the business as you do so to make the adoption of the system successful. These are the people who give a point to all of IT and who can point to things in the real world and say "I made that happen".

So vendor or corporate? If you are talented and have good communication skills I'd say go for the corporate. Especially when it comes to the Christmas party.

Technorati Tags: SOA, Service Architecture

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

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

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

How vendors view SOA

I'm picking on this post from MSDN around Where to start with SOA not because its completely wrong (it makes a reasonable point) but because it nicely encapsulates the vendor mindset of SOA. The basic point is that you can't purely have something enforced from the top as it becomes a complex management challenge and that starting from the bottom creates poor SOA is pretty much spot on. His argument that the top should provide the framework and reference and then have it filled out by tactical projects is something I'd really endorse.

The challenge is what the view is of what the "top" does and what constitutes direction.

Middle out - central group provides key elements of the interface, including numbering schemes, message exchange patterns, standard communication mechanisms, and monitoring infrastructure, and encourages the dev teams to use it to build services that can be shared.

Now these are all laudable elements, and things that should indeed be standardised on, but fundamentally they are about the technology and delivery of SOA, and not about its architecture and definition. There is nothing here about understanding the business or laying down the governance approach, its all just about the technology.

This is the big challenge when it comes to talking to any vendor about SOA, because they don't have the challenges of operating in a business environment and are focused purely on the technology delivery side it is practically impossible for them to put their products in a broader context, so they just pretend there is no broader context.

Remember this when you talk to vendors, put out an RFI for SOA or ask for some project delivery help. For a vendor every problem has a technology solution, one that requires license fees, any problem that doesn't have a technology solution will result in them pretending that there is a technology solution or ignoring that problem completely.

The post I've referred to is, as I said, not a bad view of the world from a product and technology perspective, but it is firmly constrained to that domain.

Technorati Tags: SOA, Service Architecture

SOA Vendor Ratings - Q1 2007

It was back in May last year that I did my first assessment of the "main" SOA vendors, so first up I'm going to revisit that list, then I'm going to add in (and I really will this time) assessments from some of the smaller players and open source. As ever the following is my view, nothing to do with who I work for and can't be assumed to come close to reality etc, etc, etc.

This assessment has the same summary info as the previous one which means

1. IT Vision - What are they going to do in IT, implementation of applications, integration with backends, sort of the technical end of SOA
2. IT Implementation - Great powerpoints guys, but what about the products...
3. Business Vision - What are the doing for the business, what is the content and how will it work for the business
4. Business Implementation - as before, what exists beyond the powerpoints
5. Standards - SOA implementation is massively about standards, how much does this company implement and drive standards
6. Stability - How stable is the current product set and roadmap, will they be shifting strategy and leaving you in the lurch, or going out of business and doing the same

This time however I'm going to go a bit deeper on the actual vendor reviews. So first off here is the summary


Now you will notice that everyone has shifted quite a bit on the business vision side, this is partly because they have but also because I've broadened out the business side to include the operational challenges of managing SOA at the business level. Oh and you'll also notice there are two IBM assessments... which probably makes that a good place to start

N.B. The blue line is my assessment of "now", the redline is my prediction for where they will be in 3 years time.

IBM
So why are there two IBM assessments? Well the first one is based around the roadmap that IBM tell everyone, the one that still includes MQSI, sorry "Advanced ESB". The second one is based on what I think is the real roadmap and this comes from bitter experience of watching clients with MQ Workflow and WebSphere Interchange Server believe that they would continue as well. I don't buy the Advanced ESB line, and I don't buy the "you've got to use a proprietary product that is a bugger to install" rather than a single standards based platform and I really don't buy the "There are things that MQSI^H^H^H^HAdvanced ESB does that just can't be done in J2EE". Hence the reason there is the IBM assessment based on IBM
and my view on their "real" roadmap
Lets be clear here, J2EE is the way forwards for IBM. Having something that has a completely different development, deployment, management and versioning approach makes no sense and what is left that is important can't be done in Process Server et al today? A bit of multi-protocol support and the ability to do COBOL Copybook? The shame is that IBM do have in their J2EE based stack a really good set of products for developing applications. They are still pretty weak at the business and pan-enterprise level but they have added the registry and of course have one of the broader tooling suites out there. Oddly however this tooling support doesn't appear to extend to testing where the async testing support appears to be limited to JUnit, which isn't exactly great as JUnit is poor at async (as I know from testing an MQSI infrastructure using JUnit). With CBM they actually have a business modelling approach, but unfortunately that still looks like its considered "special" so isn't yet in the tool suite so everyone can use it. Good suite, good for applications, good vision (where it isn't subverted) but they are a bit weak across the enterprise they really need to start being honest around their roadmap so people can start planning for the Java based solution that is bound to come.
BEA
Well they've bought a few more companies and the Aqualogic and Weblogic brands are really beginning to take shape. They still don't have anything in terms of methodology at the business service level and this really is going to be an issue in the coming years. They've started talking about the situational applications (Aqualogic area) and this split of backend handling and business focus really does make a lot of sense.
They really need to beef up around the governance and testing side though, it really isn't good enough to have a "preferred" partner, its either "use what ever you want" or its "in the box". Testing especially is an issue, they don't have any async testing which isn't great for projects and future viability. The current messages around Tuxedo as a very expensive Adaptor for mainframes is also a bit odd, hence the knock down there. Great product suite, great stack, good split of business and technology, but they need to focus more around the operationals for SOA in the same way as they have previously done around the application server.
Oracle
You really have to give the folks at Oracle credit, this time last year they had no ESB (except if you believe some of the analyst reports) and to be honest I thought it was going to take them a long time to get something that is properly separated. Sure there is the continued huge focus on "BPEL" as the answer to world hunger but there is certainly something coming together. This year is a big year for them as its the release of version 11 of the stack, with their membership of both the JBI and SCA/SDO camps its going to be very interesting to see the quality of what comes out in that new version.
Weak in the "business side" particularly around the modelling piece (and a great big EA tool is not the answer IMO) the operational side of the tool is okay but where they really shine out is around the testing, they actually have some async testing that can be linked back to a continual build, see it is possible. Integration is okay but a bit basic right now and the designer elements of the tool aren't really up to snuff from an SOA perspective. A good stack, an amazing rate of acceleration but its fair to say that there are still plenty of areas for improvement for the 11 AS release.
SAP
The gap between Oracle and SAP continues to widen in terms of the independent viability of the middleware stack. They've had some good thinking around the futures of all of this and the visioning is strong, the question is whether they can ever separate the Packaged application futures from the demands of the middleware, its a similar problem to the one that Microsoft have, but at least with SAP they are binding it to actual business value and business information.
Basically if you are doing SAP then its worth doing, and indeed its probably the only way, but if its a choice as a broad technology stack across the enterprise then this probably isn't the one you are looking for.
Sun
Will Sun deliver on the vision that was put forward last year, or will an EAI centric view of SOA emerge? There is lies the basic dilemma for Sun at the moment. They have a good EAI centric product in JCAPS (the old SeeBeyond stuff) and a great set of future tools (As demoed by Charles Beckham for me at JavaOne last year) the challenge now is to make that tooling shift while keeping the solidity of the underlying platform. At least with SeeBeyond and JCAPS its all based around J2EE so they don't have the mess that some others have.
The thing that knocks Sun down from an application development and operational perspective is that the current tools are very "me" centric, by that I mean that they assume that everything runs on JCAPS, the other knockdown is the debacle that is JavaSE 6 which really doesn't help the perception of Sun as a company that wants to solve enterprise problems. I really hope Sun bring it all together and start focusing up at the business problems where they currently aren't really involved at all. Great integration stack, really good for doing interfaces onto systems, needs to broaden out (using the tools that they actually have) into being an application stack and from there on towards the business.
Microsoft
Microsoft's progression around SOA since last May? Well they've released an operating system which has a proprietary async process model in it and they have a decent client side development model for web services.... Linking technology so directly to an operating system release is just plain bonkers, its as dumb as putting a Web Service stack into the JavaSE 6 release.

BizTalk remains the "heart" of much of the SOA messaging but its essentially the same product as 2004, which isn't great. Everyone else has moved on and it will be interesting to see if Microsoft come up with something equivalent to SCA, or even adopt it now its going into OASIS. With the Longhorn release due this year its really time for them to step up the focus around the enterprise and particularly improve their lifecycle and design support tooling. Microsoft Motion is a good business focused way of creating views on an enterprise, but unfortunately it appears too often to have been subverted into a "buy product" pitch. Either Microsoft want to play in the enterprise software space or they've decided that its not worth the effort, this year should outline which of those it is.
The ratings and categories explained
Now a quick summary on what the ratings actually mean, first off this is an assessment against what "perfect" would be today, rather than all time perfect (i.e. if someone stays at the state of the "now" then they'll always be a 5. The numbers are as follows

1. Very very basic, not really functional
2. Basic, meets some powerpoint and demo needs, but not much else, might be via a 3rd party to make it actually work.
   
3. Can be used by the skilled
4. Actually a pleasure to use and helps you move forwards
5. Cooking with Gas

So really its an exponential scale rather than linear.

Now for the categories

• BSA - Business Service Architecture, the ability to model the enterprise as services
• BSB - Business Service Bus
• BPM - Proper SOA and business centric Process Management
• Registry - A service registry
• Management - Ability to manage and configure operational services
• Monitoring - SLA and monitoring of services and interactions, independent of the vendor
• Testing - Testing of services at all stages of the lifecycle, especially async testing
• App Design - Ability to develop applications that consist of multiple services
• App Dev - Ability to develop services and applications that co-ordinate them
• App Process - Application level process models (where BPEL sits) and its ability to work in a proper SOA way
• App Model - The overall conceptual model of SOA applications that the vendor pushes
• ISB - The integration service bus, getting things out of older systems
• Adaptors - How easy is it to get things out of old systems
• Int Model - Integration Model, the conceptual model that the vendor pushes for integration
• Standards - How well does the vendor implement and support standards
• SCA/SDO - How well is the vendor progressing down the SCA/SDO path
• JBI - How well is the vendor progressing down the JBI path
• WS-* - How well is the vendor at supporting WS-* (WS-TX excluded)
• J2EE - How well do they support J2EE (standardised operating environment = lower support costs, no matter how much people bleat)
• Roadmap Honesty - How well (IMO) does the published roadmap reflect what will really happen

As ever comments welcomed, particularly in this case in terms of what I should assess next.

UpdateTo be clear this is about the Technology vendors, for those looking to start SOA the this is the secondary thing the most important is knowing what the actual services should be.

Technorati Tags: SOA, Service Architecture

Church Turing reduction - the vendor way

I'm sitting at QCon today getting some work done and I've overheard a bunch of vendors brilliantly apply the Church Turing Thesis to their products. The bit they use is the "any solvable problem can be reduced to a previously solved problem" and the conversation goes a bit like this

Vendor: So what are you looking at?
Customer: We are currently trying to solve the grand unified theory of everything/build a web-site/integrate our ERPs
Vendor: Well of course the most complex part of that challenge is the clustering/framework/distribution/deployment/management and its that bit which everything else relies on to work.
Customer: Well isn't that just a technology piece of the puzzle?
Vendor: Oh no, its what everything relies on, its basically the central part of everything.
Customer: Why is it so important?
Vendor: Well without clustering/framework/flying monkeys/deployment/management then nothing else will work and you will have complete chaos
Customer: But my last project worked and I didn't have your product
Vendor: But did you have problems?
Customer: Of course there are always problems
Vendor: This would remove all of those problems
Customer: But the problems had nothing to do with what your product does
Vendor: Well how you see the problems isn't where our product works, but not having our product is what manifested itself in the issues you saw
Customer: Errr sure.... give me a leaflet then.... errr I don't have any business cards on me at the moment....

Its amazing how so many things are the "central" part of IT, hell the centre of IT appears to be so big its where everything is, like a great big black hole that sucks in all the light. Sure I know they are just trying to make a living, but do they really think that claiming to be the cause of the big bang is really going to help their sale?

Technorati Tags: SOA, Service Architecture

If I can't test my app, you don't have a product

One thing that is really beginning to irritate me with the pace of "progress" in Service Oriented Development technologies is how much is made of the new bell or whistle, and how little time is dedicated to making that facility actually operational. So we see a new tool that can only be deployed with an IDE, or a process engine with no async testing tool or a deployment process that has no audit trail.

What this leads to is great demos, bad projects and woeful operation. There really is no excuse these days to not have the basics done this means

1) Scripting of deployment, ideally with a supplied ant task
2) Test generation "answer", ideally as part of the suite, again this must be executable outside the IDE (e.g. from ant)
3) Security on deployment and logging

Having a "partnership" with someone who does these bits is fine, as long as its bundled and I don't have to pay more money for it. Having a "user" testing product isn't acceptable as that is UAT (the most expensive form of testing) and I'm after unit and system test.

If I can't professionally build, test and deploy my application on your product, then your product isn't professional.

Technorati Tags: product