Why your IT strategy failed or why the business hates IT

One of the most depressing things in IT is our inability to learn.  From the 'Oh look our massive waterfall project ran over budget' to the 'I really can't maintain the code we wrote that doesn't have a design or documentation' we do the same things as an industry over and over again.  Most depressing however is the phrase 'The IT Strategy would work if the business would just change'.

To illustrate this I'd like to tell you a tale, the names will not be used to protect the guilty but it sums up nicely the lunacy of many IT strategy efforts.

Many moons ago I was working for the business side of a large and very successful company.  This company was seen as a genuine market leader and I was working on some very complex mathematics around predictive analytics that the business folks wanted to make their supply chain run better.  There were two highlights through the process from the IT department.

The first was when discussing how such a solution would be implemented and integrated into the operational systems.  IT had a strategy you see and by strategy I mean they had picked a couple of vendors, the solution I was working on had some very specific requirements and wasn't available from those vendors.  An Enterprise Architect from the IT department said in a pretty well attended meeting

'It doesn't matter what the business wants, if we say it isn't going in, it isn't going in.'

The project continued on however as the business saw value in it and wanted to understand what could be done.  One of the key pieces was that we'd need some changes in how operational processes worked, not big ones but more we'd change the way people worked within the existing processes by giving them better information.  To this end we had a workshop with the business and certain key IT folks and worked out how we'd have to design the interfaces and processes to work within the current business environment and culture.  It was a good workshop and the business folks were very happy.

Then came IT, IT you see had a big strategic project to replace all of the existing systems with 'best of breed' solutions.  I'd always assumed that given the massive budget for that program the business was fully engaged... then this happened....

One of the IT folks chirped up and said : "We need to have a workshop so we can tell you what your new operational processes are going to be"

Note the 'tell'... to which the most senior business guy there (a board member IIRC) said

"How do you mean tell us?"

IT Guy: "The new systems have new processes and we need to tell you what they are so you can change."

Business Guy:"Have you done an impact analysis against our current processes?"

IT Guy: "No we've just defined the Best Practice To-Be processes, you need to do the impact and change management.  We need the meeting so we can tell you what the To-Be processes are"

Business Guy in a voice so dripping with sarcasm I thought we'd have a flood: "I look forward to our IT department telling the business what Best Practice is for our industry."

IT Guy, completely failing to read the sarcasm: "Great we'll get it organised"

This is one of the most visible examples of my career on why IT strategies fail.  I've said before there is no such thing as IT strategy its the job of IT to help automate and improve the business strategy, that means thinking tactically and taking strategy from the business model.

"Culture eats strategy for breakfast"

This is the reality and an IT approach that seeks to drive over the culture and dictate from a position of technology purity will fail.  You can change the culture, its hard and its not a technology thing, but you always need to be aware of the culture in order to succeed.

IT Strategy, if such a thing exists, is there to make the business better not to make IT better.

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.

IT has made its self redundant through technology

There are lots of stats out there about CMOs (Chief Marketing Officers), CFOs and COOs now spending more on IT than the IT department.  Lots of this spend is on SaaS solutions and information centric solutions.  The previously powerful IT department has dropped out of contention in many cases because its not seen as adding any value.

And what is the main reason for that?

Well the IT department, its traditional vendors and analysts really aren't about offering business value, they are about positioning technologies, and of course re-positioning new technologies that do the same things as the old ones but in a 'better' technical way.

But lets look at some business apps for a second and ask some questions

SAP - Is SAP ECC the 'best' technical solution?  I think even the most ardent SAP fans would admit that this isn't the case, but it doesn't matter because what SAP does have is the operational processes the business wants.

SFDC - Is SFDC technically the best?  Is the Force.com development language the best development language?  Are their integration interfaces the very best that they could be...  again I think everyone could point to areas of improvement but again the business doesn't care.

What about the various marketing engines out there?  Indeed what about those things such as AWS or Google AdSense that people point to as technically excellent.  Do business people care about that technical excellence?

No, and No.

The market is changing, people want to get value and that means we need as an industry to concentrate on delivering that value and not on arguing about pieces that no-one cares about.  I talked about this before in Christmas SOA the fact that our job in IT is to deliver the outcome to the business without worrying them about the details of technology otherwise they will buy those outcomes from somewhere else, bleating about the technical imperfection of that other approach carries no weight when you've not demonstrated an ability to understand and deliver the right outcome.

IT needs to switch its focus to the 'I' (Information) and the outcome and stop this obsession with technology.

How to weed out bluffers....

Following up from the concept of thinking being dead I'd like to talk now about one of the biggest challenges in IT.

How do you spot those people who are bluffing?

And here I mean people who don't really think they are bluffing because they are rubbish, or those that are bluffing because they think you are rubbish, its related to the challenge of Terry Pratchett Architects (PArchitects?) where how do you tell someone who distaines technology through knowledge v one who distaines through ignorance? The point is this:

95% of people interviewing senior IT people don't understand enough to weed out bluffers

This means that regularly I come across people who have a senior position based on a level of buzzword knowledge and general ignorance of reality that causes me to step back in amazement at the ability of the person to hold down a job. Normally of course these people are in jobs 12-24 months and often are contractors where such variability is almost seen as a benefit rather than an indication of being found out. So here are the top tips on weeding out the bluffers, and I'm assuming here we are at the Architect level and you can weed out bad developers...:

1. Don't do it in a phase 1 Tech, phase 2 HR interview process - add in a middle phase which is set up by phase 1. 
2. In Phase 1 ask the following 
1. When was the last time you coded into production, what language, what plaform? 
2. When was the last time you created a conceptual and logical data model? What platform for? 
3. What is the difference between Regex, Regular Expressions and Perl in string handling? 

The first two are the real set-up questions... the last one is something that stunned me once when someone I was interviewing kept saying "I did Regex" and then later on said 'On that project we used Regular Expressions', I asked him the difference and he said that Regex was a language, Regular Expressions was... a different language. The point here is that you are after an understanding of the languages and platforms for which this person claims some level of expertise.

Lets be clear here, I'm of the opinion that an architect, whether Solution, Enterprise or Business who claims to sit within the IT domain should still know how the platforms work and especially should remember how their last platform worked. In the second interview you should include real deep developers, get them to ask real deep developer questions. You aren't looking for 'this person is a bitch ass programmer in language X' but 'not brilliant, but seems to know his stuff generally'. What you are looking to avoid is 'I don't think this guy has ever used X in his life' or similar statements.

Similar approaches, but more abstract should be used for PMs and BAs where you should get PMs and BAs who have done similar technical projects to ask the questions. I'm stunned at how many times I meet someone who is a 'Functional' SAP BA and then when you introduce them to someone who really is a functional expert in that area they fall to pieces... sometimes not even knowing the acronyms of the SAP modules they claimed to have used ('We did supplier management, not sure what SAP called it') The point here is that you need a first stage to find out where the bluffer claims to have depth and then a second stage to rip the hole if it exists.

Bluffers florish in a world where thinking doesn't exist.

Thinking is dead

Anne wrote a reasonable blog a while ago on why SOA was and wasn't dead but I'd like to go a bit further today and say that generally the concept of thinking appears to be dead.  The value of 'thought' and thinking in IT has diminished, in a way that mirrors society at large, to the stage where design, planning, architecture and anything else other than just banging away at a keyboard appear to have been relegated behind opinions and statements as fact.

REST was a good example of this.  It was going to be the revolution, it was going to be the way that everything worked.  Two years ago I called bullshit on that revolution and I still say its bullshit and the reason is simple.

IT values technologies over thought

So people genuinely, and stupidly, think that how you shift packets from A to B will have a massive impact in how successful IT projects are at delivering their objectives.  What impact has this had on the massive spend of ERP packages out there?  Nothing at all.  What has impacted that?  Well folks like SFDC because they've shifted the business proposition and in so doing have moved the way business people think about IT systems.

The same goes around with Hadoop and Big Data.  The massive amount of information growth is complemented by an equally large amount of bullshit and a huge absence of critical thinking.  What is the major barrier to things like Hadoop?  "Its lack of real time ability" I hear people cry.  Really?  You don't think its that we have millions of people out there who think in a SQL Relational way and who are really going to struggle thinking in a non relational non-SQL type of way?  You don't think that the major issue is actually in the acquisition and filtering of that information and the construction of the very complex analytics that are required to ensure that people don't go pattern matching in the chaos and find what they are looking for.

We are currently seeing a rush to technology in IT departments that is focused hugely on bells and whistles while the business continues to look at outcomes.  With the business looking at SaaS, BYODand self-service applications the importance of thought and discussion in IT is acute. What I often see however is statements of 'fact' like 'you don't need integration its SaaS' or even worse a statement on a specific piece of API based technology as being important.

Planning, architecture and design are being seen in parts of IT as bad things as a mentality develops around a concept that some how basic fundamentals such as TDD, contract design and doing things that actually proven to work are in some way wrong.  Adoption of unproven technologies is rife as is the surprise when those technologies fail to deliver on the massively over hyped expectation and indeed fail to even come close to delivering at the level of dull old technologies that do the job but don't currently have the twitterati in thrall.

'Experts' in this arena has come to mean 'people who shout loudly' in a similar manner to US politics.  Facts, reason and worst of all experience are considered to be practically a disadvantage when being an expert in this environment.  I was recently in formed that my opinion on a technology was 'tainted' as I'd used multiple other technologies that competed with it and therefore was 'biased against it'.  I'd also used the technology in question and found that it was quite frankly rubbish.  Sure the base coding stuff was ok but when I looked at the tooling, ecosystem and training available from those competitors I just couldn't recommend something that would actually work for the client.  Experience and knowledge are not bias, thinking and being critical of new approaches is not a bad thing, thinking is not dirty.

When I look around IT I see that design is a disappearing skill and that the ability to critically assess technologies is being replaced by a shouty fanaticism that will ensure one thing and one thing only:

IT will no longer be left to IT folks

The focus of shiny technology over business outcomes and the focus of short term coding over long term design will ensure that IT departments get broken up and business folks treat IT as a commodity in an ever growing way.

Thinking, design, planning, architecture and being skeptical on new technologies is the only hope for IT to remain relevant.

Preaching to the Choir: the bane of IT

Sometimes I get asked why I bother debating with people who clearly have a different opinion with me and are unlikely to change their mind. The reason is that sometimes, rarely I'll admit, that sometimes I will change my mind and occasionally I will change theirs.

The other reason is what is the point of debating with someone who agrees with you? Unfortunately in a lot of IT we have two types of discussion

1. Religious discussions based around IT fundamentalism
2. Preaching to the Choir to re-enforce the message

These two are very closely related.  Effectively a group of people talk to each other about how great something is and how fantastically brilliant that approach is and how the whole world should bow down before their joint vision of the future.  These folks then head out to 'spread the word' and are just plain shocked when people fail to accept what they say as the gospel truth and normally either result to insults, making up facts or just plain ignore any comments or questions.  Quite typically this later bit includes doing farcical comparisons like

Q: Where are your references?

A: Same as yours, personal experience

Q: Err but mine are published on the web, here are a bunch of links...

A:

This is a conversation I've had many times.  The reason for this post however is that on Google+ someone replied to a post by Jean-Jaques Dubray (which referred to this post) and after a short discussion where the individual started with a personal insult and moved on to ignoring questions and instead posting their own PoV finished with the brilliant line

Wrong audience and tone

Which of course just means that the person feels that they want to go and speak with people who agree with them unquestioningly.  This mentality is a massive problem in IT and, I feel, more prevalent in IT than almost any other discipline.  Whether its the 'leadership' of the Java group ignoring huge amounts of external input that disagrees with them or the various little pieces of fundamentalism around its a significant issue that folks tend to switch from one fanaticism to another without often pausing between them.  The number of times I've bumped into someone a couple of years down the road who is now a fanatic for another approach is just stunning.

I remember once saying at JavaOne that UIs are best created with tools and was told in no uncertain terms that you couldn't build a single complex UI with tools, it had to be hand coded.  I pointed out that I'd built an Air Traffic Control system where everyone was using visual tools for the UI side building, this was a system that was already in production, the reply was 'good luck with that, it won't work'.  Much back-slapping from his friends for 'putting me in my place' while I wandered away sadly wondering if people really could be in IT and want to learn so little from previous experience and instead just create a small clique that backs them up.

I've come to realise that this is sadly exactly what lots of folks in IT prefer to do, they prefer to create an 'us v them' mentality and form small groups of 'evangelists' who preach to each other on the brilliance of their ideas and the stupidity of others for not understanding them.

Its this fractured nature that leads to groups denying any benefits from 'competiting' approaches or even from historical ways that have been proven to work.  Often things come from first principles and sometimes (and this is the one I find most scary) is tied to a single published work which becomes 'the good book' of that clique.  The choir preaches to themselves and sees success when none exists or defines success purely based on their own internal definitions.  The debate that is engaged in works on a very poor level as no challenge is allowed to the basic assumption that they have found the 'holy grail' of IT which will work for every sort of approach.

Preaching to the Choir is at the heart of this issue.  Talking and debating only with those who agree with you is a bad way to test ideas.  The Oxford Union is what debate is about, two sides trying to convince the other and the audience deciding who won.  Argumental has built a programme around people being made to debate on a topic they might not even agree with (although in the linked video Rufus Hound doesn't make a very good job of that).

If all you hear is 'that is great, brilliant, anyone who disagrees is an idiot' then I'm afraid that you are an idiot as you are in danger of wearing the Emperors new Clothes and are clearly taking the easy way out. If you can't convince other people of the power of your argument this is most likely to be because there are flaws in your argument that you don't understand or know, not that the person you are debating with is an idiot (sometimes this will be true of course).

The basic rules should be

1. Facts count - if you can reduce things to quantative assessments then you are doing better
2. Ladder of Inference - you need to build from the first point of the debate, not start at the end
3. Answer questions - if someone asks a question, answer it
4. Think about where the other person is coming from
5. Read opposing views, learn from them
6. Accept when you don't agree - sometimes people will differ and that is okay, accept it

I find it quite depressing when people say 'I'm not talking to X as he can't be taught about Y' when I know that the reality is that X has a very good point of view that the person saying this really should listen to as they'd learn something even if it challenges their current IT religion.

So please can we stop preaching to the choir and start having actual debates, it doesn't matter if the tone is a bit disrespectful or sarcastic as long as you are challenging and responding to challenge.  It should be a fierce debate on occasions and that is fine, but what it shouldn't be is just preaching to the choir and denouncing all those who disagree as heretics.


Technorati Tags: SOA, Service Architecture

There is no HR/Business divide, which is why its IT's fault

The IT/Business divide is something that exists in most businesses I've worked with. I think it comes from a few different drivers, one of which being that IT is often the smartest set of folks in the room academically if not socially. But one piece I can't agree with is that the fault for the divide lies on both sides.

Lets flip away from IT for a moment and concentrate on other "support" parts of the organisation. HR and Finance. These aren't the front-line of the business but they are critical support functions. Now I've regularly heard people in the business moan about Finance being too conservative or too controlling but I've never heard people talk about a Finance/Business divide or that the CFO is disconnected from the business. The perspective might be that Finance has a different view on the current opportunities or issues but not that the business and Finance are disconnected. HR even more so, the HR Director who is disconnected from their business is a fired HR director.

In IT however I've regularly seen CIOs who are disconnected from the business and seen architecture communities who have said classic phrases like "it doesn't matter what the business wants, if we say its not going in, its not going in". IT continues to talk technology rather than business and optimise things (programming languages) that add zero business benefits. IT regularly bleats "The business must realise how important this is" rather than actually working out what is important to the business.

The business/IT divide is the fault of IT because IT doesn't make the effort to communicate the value in the language of the business its like the worst kind of tourist who thinks that shouting louder is better than learning the local language.

Its time for IT to stop looking inwards on optimising wheels and start focusing on how to communicate about IT with the business in their own language.

Technorati Tags: SOA, Service Architecture

Theory v Practice - the opposite view

There is an age old saying

In theory, practice and theory are the same thing, in practice they aren't

This is true 90% of the time, but in Engineering it isn't always the case. I was speaking to someone a day or so ago about interviews and they were nervous as the job they were applying for required a specific programming skill and they had only done "a bit" of it.

What I told this poor young fool was that as they had talent (and they do) this lack of experience was just a minor element. Could they learn more in the week before the interview? I asked. "Sure" came the reply.

Well there you go. Any if they ask questions about threading and deadlocks can you answer them.

"Well I know the theory but not the syntax"

And it was here than I imparted the knowledge... Its actually the theory that counts not the syntax. To this end I'll tell two tales.

My first job interview was for a start-up company. They had some interesting bits around Eiffel and were trying to create a meta-language on Eiffel that enabled multiple different GUIs and Databases from a single code base. Part of this would require me to know C. I was asked

"Do you know C"

"Sure" I said.

"You'll have to take a coding test next week to check" they said

This gave me 7 days to learn C, a language I'd never coded in before. By the end of that week I was coding with pointers to functions which took pointers to arrays of functions as arguments. The reason was I understood the theory and could quickly apply it to the new syntax.

I got the job..... but they went bust 6 months later owing me 2 months wages so it wasn't the best story.

Now for another story, a good friend wanted to shift out of his current IT job which didn't do coding into a coding job. He had a bunch of theory and brains but no experience. I boldly said that I could coach him through a C++ interview in a couple of weeks. For 2 weeks we talked about classes, STL, friends and lots of other things.

He got to the interview, chatted for 30 minutes about computing in general and was asked the killer question

"So you know C++"

To which he quickly replied "Yes".... and the interview was over. He got the job and was pretty bloody good at it, despite the level of bluffing (although the single word "Yes" isn't the strongest bluff in the world).

The point is that if you understand the theory of programming languages and computing then individual languages are just a set of syntax that implements that theory in a specific context. Unfortunately in IT very few people understand the theory and are therefore condemned to badly implement software in the manner of an orang-outang who doesn't understand English but has a dictionary of English words to point at.

Lots of times Theory is less important than practice, but in IT if you don't know the theory then the odds are you'll be rubbish at the practice.

Technorati Tags: SOA, Service Architecture

It doesn't have buy-in? Then cancel it.

I thought I'd share a little story with you today. Speaking with a friend the other day he told me a great experience he had with a project... he cancelled it.

Why was this so great? Well he looked at the project and saw that the business wasn't really committing the people to it that it needed to properly succeed. This would mean that the project would drag on longer than it needed to and would most likely fail. His response was to pull the technical resources off the project until the business could focus on it. It wasn't there the budget didn't exist it was that the budget looked like being wasted.

The end result was a bunch of saved money and a project that has slipped by over a year because actually there was more important stuff to do.

All to often I hear the complaint in IT that a project failed because the business didn't engage. The question is why did they try and deliver if the business wasn't interested?

Technorati Tags: SOA, Service Architecture

Chairman Mao and the problems of IT

Reading the economist over Christmas (oh and seriously get a subscription) there was a great article about how Chairman Mao is an ideal "role model" for the poor quality manager. Reading it however it became clear that 90% of IT also appears to follow the way of Mao when approaching their jobs.

So if you aren't actually any good at IT then here is how to bluff your way using the Mao guide to IT. This applies to Architects, Managers, Vendors and even developers who just don't feel they have the talent to get anywhere

A powerful, mendacious slogan

For Mao it was "Serve the People", given that he "... lived like an emperor, carried on litters by peasants, surrounded by concubines and placated by everyone. this really was an impressive slogan. The point here is that the slogan is an outright lie, but its an outright lie that is talked about honestly and with conviction but doesn't bear any relationship to reality.

In IT things like "Business Focused", "Customer Service" and "Delivering value" can be used to mask what is essentially a continual drive to use new technologies and to avoid talking to the business or customers if at all possible. In fact its a case of business as usual with everything being now justified as "required" by the over arching vision.

Ummm looking at all those vendor slogans makes me think that Chairman Mao's PR department is alive and well in IT. Huge massive friendly slogans backed by software that makes you cry and costs a fortune.

Ruthless media manipulation
Have posters printed, set up a web page, have an award in fact do anything that makes it look like you are doing this while in fact doing nothing of the sort. This tends to be a real management favourite, a new initiative, a new name and the same old behaviours and thinking. A big internal email campaign, possibly even some external press and most of all controlling all of the communication that goes between IT and the business.

Ever had a manager tell you "you can't talk to the business"? Or how about "tell me what you want and I'll find out" and then become convinced that they haven't talked to the business at all? What about architects who claim to "understand the business" and therefore don't let anyone else go direct?

Other bits here are in the creation of fake statistics and successes is another area here. The classic "well it was fine when I left it" and claiming improvements in areas where there aren't any metrics being formally gathered. This is where people claim "we've improved quality/productivity/time to market by X%" when all the evidence seems to show that in fact its got worse. The key is that the person manipulating and broadcasting the stats is the person responsible for them.

In IT departments the media manipulation tends to be internal rather than with the press but its the continual planting of stories and broadcasting of success (and others failures). A few other good ones here are where a project fails but its "all the fault of the vendor" or where a technology turns out to be rubbish and that is "down to the implementation team" the key is spinning and there are lots of people in IT who seem to think that spinning is as important as delivering.

Vendors are truly the best at this in terms of their external marketing. The product might be a bug-riddled piece of crap that won't even install from the CDs but thanks to some smart marketing, demoware and presentations its lauded as being a market leader.

Sacrifice of friends and colleagues
Now here is where IT often moves away from Mao in that I tend to see Cabals and cliques being the dominant factor with competing groups battling for supremacy. But then again isn't this exactly what Mao was about? Basically using different groups within the organisation as the scapegoats? Project fails because in reality the architecture was completely rubbish? Blame the project manager, the development team or India but never, ever allow people to point out that the architecture was unimplementable.
This is something I see over and over again as IT projects fail. The finger pointing starts and the "winner" is the one who gets the least blame and places the most blame elsewhere. Again this isn't actually about reality its about using other people to take the fall for you so you don't have to admit to failure yourself.

With Vendors I guess this would be how they stab each other in the back, but I'm not sure its as good an analogy.

Activity substituting for achievement
Now this is the area where IT, and in particular Architects, come into their own. Those constant internal meetings, those document reviews and those endless process improvement efforts that never improve anything. Its hard to imagine a group of people who create more noise for little achievement that those found in IT. In 2007 I saw people proudly demonstrate how they could use WSDLs in their tools... 2007? That was done in 2001. There are all the various frameworks out there, something IT developer love to do. Don't develop the solution, develop a framework and never get around to the solution.

With vendors this is all about adding new bells and whistles to the products, and to be fair to the vendors this is what the Chairman Mao impersonators in corporate IT and the blog world are asking them to do. Its not about making it better its more like "Pimp my product" with lots of new bling being added on to the same old crap in the mistaken belief that this actually makes it better.

Part of the problem is that the talent gap in IT is ridiculously huge. There really are a huge number of people who are, when all is said and done, just bluffing at their jobs and who follow (unknowingly) Mao's plans for success on a daily basis.

IT and Chairman Mao, maybe the required reading shouldn't be The Mythical Man Month but the mass murders' Little Red Book.

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

Why thought is more important than action

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.
- Fred Brooks - No Silver Bullet

Now that essay is in what I think of as the entrance exam to a job in software, if you haven't read it you really shouldn't be working in computing.

I thought it was worth bringing up again as there have been some bits recently around SOA v BPM which have been misunderstood as me bashing BPM. This isn't the case at all, what I'm saying is that you need to think first before implementing BPM and that SOA represents the best way to create the conceptual construct for BPM, and that BPM is about the labour of representing that construct.

The key here is that the important piece is the thought and planning of that initial piece, not the implementation of the ideas. It is much more valuable and powerful to have the correct conceptual framework before you start on the implementation.

This is why I say that BPM screws up SOA because BPM does not create a conceptual framework, it creates an implementation approach which is a set of steps linked together. There are people who practice true Business Process engineering who create the conceptual framework for process, and to me that looks much like the Business Service approach I try and do in that it considers the parts of the business and their boundaries before worrying about any simple issue of steps.

Hell don't stop at Fred though, Adam Smith apparently has some good ideas as well.

"A journey of a thousand miles begins with a single step" is another famous saying, of course its not actually true, the first thing to work out is exactly where you are going and how to get there otherwise you could spend 40 years just wandering across a pretty small desert.

SOA is about thought, and thought makes better action.

Addition: It appears to be a bigger meme today than normal, someone else is bigging up the book

Technorati Tags: SOA, Service Architecture

Narcissistic IT, same old challenge, same old idiots

One of the wonders of the web is RSS, its one of those things where people used to say "how do you keep up to date" and the answer was I use a large amount of RSS feeds, but unfortunately they don't have the sophistication of Emacs' newsreader. Well today I saw that brilliant old IT challenge of "If I can do it in less characters, then it must be more effective" now there are only two problems with this argument, firstly its bollocks, and secondly its... bollocks. Now I know that strictly speaking this is only one problem, but its such a big one I thought I'd point it out twice (name that TV programme?).

I came across this challenge in two guises, the first "impressed me" that a library call in Ruby could do lots of things and the second went for the traditional Java sucks angle against scripting languages.

Now these would be wonderfully astute calls if they hadn't been made every year since I entered IT. The only problem is that the ability of the people arguing has gone massively down. When I first got into IT it was the LISP people arguing that they could do anything in less characters than anyone else, and they were right. This was because they used a functional programming language and really understood IT. They never ever thought that a scripting language was the best way, and indeed nobody did because a strongly typed and formal language had much better performance and that meant performance in project teams which is what is important after all.

IT suffers from a massive dumbing down, people make arguments based on out right stupidity, a stupidity based on little or no understanding of the principles of computer science. The complexity of IT is ever increasing but the average intelligence is plunging. Things that were plain dumb 10 years ago are now being promoted as "best practice", not because they have become good ideas but because there is a volume (as in barrel) of people who think that their mickey mouse experience is all that anyone ever needs to know.

This is one of the most depressing things about IT. When the LISP boys used to show off at least you could stare in wonder at what they'd done. Having a library that does time conversion isn't exactly the most impressive thing I've seen, its not even the most impressive thing I've see my dogs do today, and the "I can write code really quick in this scripting language" is a great lesson in the "I don't have a clue about TCO" problem that IT has always suffered from. Just for once it would be nice to see people shout out about "I used this and 5 years later people were still able to make changes" or "I wrote this code and the developer sitting next to me understood it".

Maintenance is the hardest part of IT, writing code that survives for 5, 10 or even 20 years should be an achievement, not writing something 20 seconds quicker than the bloke sitting next to you. It would be nice to see people laud languages because of the features they have that make support easier, facilities that make monitoring easier or just pieces that make deployment easier. There is something seriously wrong in IT when every new generation comes along and makes exactly the same mistakes that the muppets of the previous generation made, but worse than that where previously the muppets were small in number they now appear to be pretty much the majority of IT.

This is a major challenge for IT, and in particular the current challenges of SOA and participation based systems. Sure someone can knock up a glorified FTP site with a GUI (YouTube anyone?) but what about doing real, active, participation and creating real business value on existing systems?

As long as IT is dominated by people whose perspective is I can code in this quicker, like really cool dude then it will continue to be perceived as a profession dominated by an obsession of itself rather than an obsession with improving what it does.

Technorati Tags: PHP, Java, Ruby

IT fundamentalism - The Technology Delusion

I've been reading The God Delusion recently with its rather nicely argued points about theism, deism, atheism and the like. Reading it made me think however about how a clearly designed environment, like IT, operates and while reading some of the chapters around monotheism it became clear.

IT loves to proclaim the "one" truth of IT and burn at the stake all those who do not agree. It is a professional of many fundamentalist preachers who preach "the one true way" of IT and proclaim that all others are damned. It is a professional of followers of those preachers who deride others for "not understanding the truth" rather than seeing that maybe there is another side that they don't know about. Now clearly I'm open to this charge around SOA, I pretty much think that viewing businesses as services is the only practical way I've seen so far that works and right now I'm preaching that gospel.

And here comes the other bit, we may proclaim to be fixed to "the one true IT god" but we will switch as easily as pie to the next "god" that comes along. Sometimes this is in the guise of a powerful preachers (e.g. Microsoft) who convince the followers that all that had been said before (e.g. VMs are slow and not the way to go) is true and that all that is said now (e.g. VMs are the way forward and the only way to work) is true and sure enough the gullible followers develop with this religion and rarely look for solutions outside of their creed.

Consistent in all of these beliefs is that all problems are, at their route, an IT problem that needs an IT solution. Thus the battle will rage on WS v REST and Java v .NET, Spring v J2EE, ESB v ESB, BPEL v BPMN, lazy loading v pre-fetching, OO v procedural, Netbeans v Eclipse and for all of these there will be people who take, in effect, religious convictions as to the "right" of their side in being the one true way to solve the problem.

The history of IT fundamentalism has taught us that one answer has pretty much never been the sole right answer that will be true for all ages and that just as the religion of EAI has pretty much died so the religion of ERP is liable to falter in the coming years. The history of IT fundamentalism has also taught of its immense dangers to projects and even businesses, the .com bust is a great example. WS and REST will be looked back on as a footnote in the debate and we will all have moved onto a new religion with new fundamentalist preachers proclaiming its truth.

Maybe however we should look to what has caused these IT debates and what is driving these changes. The answer, in reality, is that the big changes have not been made from the fundamentalist preachers of IT they have been made by people who saw a problem that needed fixing and provided a solution that hadn't existed before this means that they key to IT is not the solution that drives but in fact it is the problem which is important, and each generation has new problems that are now required to be solved.

The Church-Turing Thesis sums up this dilemma that in fact all current problems are reducible to previously solved problems or by definition is unsolvable. This means that the only question is on the efficiency of the latest IT cult rather than on it being genuinely different. This presents the IT preachers and their followers with a problem, how to push their new cult when in reality it is going to be short lived and is in fact just a different view on the same old problems. The answer is of course denial and fixation. We hear, most often from the followers rather than the preachers, that those who do not follow the true path are doomed to failure and (a common refrain) "do not get it". The failure to accept this new religion is placed straight at the doors of the non-converts.

Just like with religion this places the burden of proof in the wrong direction. If you are saying your new "miracle" truly is the Silver Bullet we've all been looking for then it is your responsibility to educate and accept the challenge. It is not enough to claim that "you don't get it" for as Albert Einstein said "If you can't explain it simply, you don't understand it well enough".

The reality of IT however is that these religious fads are, like religions in the real world, just things that give us false comfort about the real underlying problems and challenges that we face. It is better to have a religious rod of conviction that "REST" or "Agile" or "SOA" or "Web Services" or "PHP" or ".NET" etc etc is the best way rather than having to actually sit back and think that maybe it might be better to use something different on this problem because it is different to the previous problem. The current approach of "The answer is X, now what is the problem" and then blaming the problem is just plain madness.

The only rational position in IT is to be a political agnostic, that is you should accept that different IT religions are required in different areas and you should be skeptical about new religions that come along. When you find something that works for a given set of problems you should believe in it, but you should do so in the knowledge that something else might come along. Fundamentalism should have no place in IT, nor should the "believers" seek to condemn the heretics who dare to question their preacher or "bible". The political agnostic is one who chooses to believe for a period of time because right now that belief works for them, you could also refer to them as the slutty polytheist if you are of the fundamentalist monotheist persuasion.

One size doesn't fit all, one solution will not be the answer to all problems and there sure as hell isn't a Silver Bullet. Its fine to have certain beliefs on things that help but these should be backed up by data and should accept that these may not be true in all circumstances. Beneath it all should be the recognition that the true challenge is not what is the "one" IT solution, but what is the current problem you have and what is best suited to solve that problem. The problem is that the preaching of reason never generates the same degree of noise as that generated by the truly fanatical. So the messages that are heard in volume are not those of reason, debate and discussion but rants about technologies and the continual almost maniacal obsession with "the developer".

IT fundamentalism is a reaction to the fact that most IT challenges are created outside of new IT projects whether by customers, business, markets or the existing estate. It is a reaction to those who aren't assured in what they are doing and need some technology deity to cling to., IT fundamentalism dictates a "technology truth" as above everything as it is just too scary to admit that IT not only doesn't have all the answers but...

IT rarely even asks the important questions.

Technorati Tags: IT