BI change is coming, time to get over it and get on with the job

One of the things that always stuns me in IT is how people don't appear to like change.  Whether it was the EAI folks pushing back on Web Services in 2000 in favour of their old-school approaches.  The package guys pushing back against SaaS or now the BI guys pushing back against the new wave of BI technologies and approaches the message is always the same:

We are happy doing what we are doing, its great, I've done it for years, I don't want to change

That really isn't a long term career plan in IT.  This is the industry where revolution happens on a regular basis.  That doesn't mean you shouldn't be a skeptic, everyone in IT should be a skeptic and really ask for new approaches to prove themselves.  Its why I still don't think REST is 'the answer' to integration, I just haven't seen it proven to work at scale in the enterprise.

Sometimes however you can see the wave coming.  The Internet was one obvious wave and its impact on the enterprise was huge.  Now however there is another wave that I feel is equally obvious.  The wall between operations and analytics, between transactional systems and BI systems is being smashed down.  Its a wall IT put there as its been cheaper and simpler for us to have it there, but the business doesn't want these worlds separate any more.

This means that change is inevitable.  This is a change in the information space which is analogous to the desktop PC impact over the previous mini and mainframe computer era.  The change is going to be large.

Its going to require

• Joined up thinking between applications, transactions, processes, analytics and information
• Its going to require thinking in the local context while enabling global governance
• Its going to require new governance models that better match the business
• Its going to require all speeds of analytics, and the ability to change the speed as the business demand evolves.

This is a big wave and you cannot stand Canute like on the beach wishing for it to go away.  Much better to embrace the change and start planning for it as that way you won't be washed away.

IT changes.... its why its useful and its why is an interesting business.  Right now BI is at the centre of one of the most exciting changes in 20 years, we should celebrate that and get on with making it happen because otherwise we will wake up in 5 years and find our company has either struggled to compete or fail, or has succeed despite of us.

When to shout, the art of constructive destruction

I've always believed that sometimes teaching is about the stick as well as the carrot but there are very clear rules on when to use the stick and how to use it.

Its not good enough to start with shouting, that marks you down as an idiot and a prat.  If someone has done something that you don't want but have never explained to them then its your fault as the person in authority.

Rule 1: You have to have explained first before you shout

The stick therefore is something that should only be used when someone has deliberately gone against advice or guidance.  If people have followed what you said and it didn't work... its your fault.

Rule 2: It should be obvious to 'the average man on the Clapham Omnibus'

By which I mean that the fault should be obvious to a person of the given level and experience, if its a junior person who has made the mistake then shouting is not appropriate.  If its a self-proclaimed expert who has screwed up then a kicking is in order.

Rule 3: Pick on the leader not the team

If there is a team of people who have screwed up, don't share the blame equally, that person is accountable to you for the team so they have to take the responsibility for the failure.  Their team will know its a joint thing and that the leader has taken the heat for them and this should improve the situation if there are any team dynamic issues.  If you flame the whole team it basically says that you don't accept that they have a leader so you should be managing them all directly yourself.

Rule 4: Be specific, be constructive in your destruction

'You are a moron' is not a constructive statement.  'If you don't explain to me how what you are proposing addresses the two key use cases then I'm going to have to kill you' is constructive destruction.  The point here is not to hide the anger but to make clear that your challenge is very specific and targeted and gives them the opportunity to respond.

Rule 5: Make perfectly clear you are pissed off

You should only be doing this when its got really bad so you have to underline that it really is bad.  This doesn't mean you have to swear or throw chairs about but it does mean everyone should leave the room knowing that they are in your bad books and that if they don't buck their ideas up then chair throwing might be in their futures.

Rule 6: Give specific ways they can get back into favour
Before the team breaks up be specific, give them a short time frame on how they can recover the situation.  These need to be actions you can, and will, track of the next few hours or days on how the team can show you they are getting back on track.

Rule 7: Be honest when you get it wrong, congratulate
If it turns out that you were wrong and in fact the team had been going the right way but you didn't have all the information then apologise and congratulate them.  Shake the hand of the person who stands up and says 'you got it wrong, here is the proof' and deal with it as you should, with humility and possibly donuts.

Rule 8: If things don't change make a sacrifice
If the team keeps working badly and avoiding advice its time to make a public sacrifice, this could be kicking them off the project or even out of their job or it could be as simple as public humiliation.  Putting a small statue on their desk saying 'Crap Architect', check with HR first on what you are allowed to do.  Use your companies formal processes to underline it.  The key is that you want everyone to think 'fuck I don't want that to happen to me'.

Rule 9: Be inconsistently angry
The penultimate rule is to not use anger and shouting as a 'what happens at level 10' thing.  Sometimes use it as an opening gambit, sometimes use it as a final twist, sometimes use it through-out a process.  The point here is to use anger and shouting sparingly with the team.

Rule 10: shouting isn't about volume
'Talk quietly and carry a big stick', shouting for constructive destruction in a project is not about raising your voice, its about the impact that an attitude carries.  Talking more slowly, deliberately and quietly can be significantly more threatening than shouting loudly in many circumstances.  The key here is the effect, occasionally you want people to change their ideas and give them a jolt, don't think volume, think impact.

Lets be clear, I don't think that shouting and constructive destruction is a thing to use all the time, but sometimes the stick is required these rules help me ensure that I don't just shout like Shakespeare said 'Full of sound and fury signifying nothing' but direct that anger and use it to save the situation.

Constructive destruction is about tearing down bad behaviours and providing a way to rebuild them in a positive way.  There are lots of touchy feely ways to do that, but sometimes fear is the right way.

Why MDM and SOA are shifting out of IT

Now I've said previously why MDM is required for successful SOA but there is another important piece around MDM and SOA that is happening at the moment and explains both why MDM and SOA haven't historically gone together and, crucially, why the new trends are liable to help bring them together next year.

Why SOA and MDM didn't go together

The first question is why historically MDM and SOA projects tended to not go together. Sure organisations would "do" SOA programmes and would "do" MDM programmes but rarely would the SOA programmes and MDM programmes be tightly joined. There are I think three reasons for this

1 - Different bits of IT

The first challenge is that MDM and SOA were normally done by different bits of IT with different mentalities. MDM was done by the "data" folks who worried about data warehouses and saw data as the most important thing in the world. SOA was done by the enterprise integration and architecture folks who worried about operational processes and integration. The MDM folks tended to have a post-transactional view of the world where things were "true" or "false" while the SOA folks tended to view things as "in processes" or "completed".

These different communities in IT have very different backgrounds and focuses. ETL, Data Warehouses and big databases rule in the MDM/Data side while fast transaction throughput is the key for the SOA folks.

2 - Different bits of vendors

The next challenge is that the vendors have exactly the same split in their view of the world. Look at IBM for instance. SOA is in the WebSphere brand while MDM is in the InfoSphere brand, two very different parts of IBM Software with independent management structures and teams, sure the idea is that they should co-operate and work together but we all know that different divisions in companies like to do things differently. This also means that you often get different sales people for the different pieces of software. Oracle for instance put MDM in the Applications area while SOA is in the Middleware space, if you want to use their MDM products with their middleware products (for instance using the MDM PIP) this means you have to deal with two different sales people to get what you want.

3 - They've been IT projects

The final reason is that MDM and SOA have traditionally been internal IT programmes owned and managed by IT and largely invisible to the business. This means that the two cultural elements above are then hard-baked into the solution which ensures that the SOA and MDM programmes are kept distinct.

Why its changing

So why is it changing? Well the first reason is that people have started finally realising that SOA is a business thing and needs to be viewed from a business architecture perspective. This has been a long time coming but finally it appears people are thinking about the challenges of business services, service value and the business architecture. At the same time MDM is shifting as well, firstly its shifting away from post transactional into an operational space which means it needs to consider operational processes and performance in a way it hasn't before, this means that the MDM/Data folks now have to not only talk to the SOA folks but they have to... shock horror... actually become MDM/SOA folks.

MDM is also shifting in that business people want to do more active information management, both in terms of newer analytical tools and secondly in terms of including that mastered and high-quality information into core operational processes. This means that the business realises that the old "data landfill" approaches which were poor before are massively hindering the analytical models and have a direct impact on the efficiency of the operational processes. By taking control recognising that Information needs Mastering the business is now actively taking over those processes and thus MDM is moving out of the background into being a key part of the corporate information strategy.

So that is why MDM and SOA are shifting out of IT, its because being within IT made them technically centric programmes that often failed to deliver the promised value. By enabling the business to more actively own its IT estate, through Business SOA, and its core information, through MDM, it suddenly ceases to be a question of competing IT cultures but a simple question of how to present a consistent operational and analytical view of the business.

SOA and MDM are made to be together.... that fixes the enterprise culture... but will it fix the vendors?

Technorati Tags: SOA, Service Architecture

The Clint Eastwood school of change

Change is hard, change against people who don't want to change is extremely hard bordering on impossible. In any change programme therefore you need to be clear about what you are up against and what success looks like.

This is where Clint Eastwood can help. Sure Chuck Norris can run around the world and punch himself in the back of the head but Clint Eastwood has many more lessons on delivering change in difficult circumstances and presenting different approaches.

This isn't for the collaborative occasions when you need to work with people, Clint isn't very good at that. This is for the occasions where you need to overcome people who are actively working against you and the objectives of change.

So what does Clint teach us? First off he teaches us that there are different types of people who we need to overcome.

There are people in authority who are abusing their position to make sure the change doesn't happen and are instead driving their own competing change agenda(Pale Rider).

There are people within a given group who are working against you (Gran Torino)

There are people who operate in a different management structure and are using that independence to try and prevent change (Unforgiven)

And sometimes there are people who need to be run down and shot because they are never going to be part of the new world (several films)

The point here is how does Clint deal with these challenges? The answer is that there are some obvious similarities and a few key differences.

Firstly the similarities.

Clint never gets angry, at least not against the people who are targeted as the blockers to change. This is a really important lesson. If people are blocking change you really can't just shout and scream at them, it doesn't work and just makes you look impotent.

Clint is focused. Clint doesn't have a huge number of approaches to deal with the situation and he never runs into the situation without significant amounts of planning and thought. This means that when Clint decides to take action he has already determined what the outcome he wants is, and then makes sure that it happens.

Clint is talented. Clint makes sure he is the big guy in any engagement, this doesn't mean shouting his head off it means making sure that he knows exactly what he needs to do and making sure he has the skills and resources to deliver against it. Clint makes sure that what ever the other guy is doing that he has the skills to adapt to the situation and make clear that he is in control ("Do you feel lucky? Well do ya punk"). The point here is that Clint backs his ability against his competition and this is a core way that he ensures the right outcome.

Clint is clear and concise. Why say 100 words when a stare or a grunt will do? Don't waffle, don't prevaricate , just make it absolutely clear what you want and how you will achieve it.

Now the differences

There really aren't that many, its really about how the similarities are applied differently.

The point here is that these key Clint lessons are how anyone should be looking at difficult change where you have a group of people who are adamantly set out against you.

Know you facts, know what they know, know what you want and concentrate on achieving that.

The lesson of Gran Torino is also that losing a battle can also be winning the war. I've had a number of experiences where you pull people into a "Road Runner" moment, i.e. you draw them to a point where they think they have won, then as the dust clears they realise they have stepped off the cliff and are about to fall.

The lessons of the "Dollars" films is that sometimes you just have to face it that people won't come on the journey and they need to be sidelined or exited. Don't try and get them on-board, its pointless, just work out the easiest way to eliminate the,

The lessons of Unforgiven are that people in groups often act in an uncoordinated way if you attack them individually. Don't go for the overall group, work out individual weaknesses and use that to drive the group apart.

The lessons of Pale Rider are that coordinating those that do support change behind you (also known as the Magnificent Seven approach) and using your focus and talent can overcome the larger but over-confident blockers.

Change programmes come in lots of guises but often you'll find yourself come to a moment where you realise that there is a group of people who just won't be coming on the journey with you. Then you've got to ask yourself the question

What would Clint do?

Technorati Tags: SOA, Service Architecture

Driving IT from the business

A short post here just to once again go over the basic principles of Business driven SOA. The goal here is that IT should be driven from the business this means

1. Understanding what the business is about
2. Understanding where and how IT can help the business
3. Letting the business interact and drive IT on its terms
4. Not thinking that the latest buzzword is the important thing
   

Now the goal is of course the same as before, you want to deliver an IT estate that

1. Looks like the business
2. Is costed based on the value it delivers to the business
3. And evolves like the business

This therefore is about understanding where to apply new technologies and where to just cut costs and cope with what you have, or even move towards outsourcing it because it just isn't important to your business at all.

Business driven SOA is about using the right tool for the right job in the right place in the right way. Its fundamentally got to be about the delivery of technology inline with the overall business. This means it must be constrained by what can be delivered and must be inspired by what could be delivered.

As we hit the down-turn this becomes more important. Taking a technology approach is just burning company money and applying new technologies where they don't deliver the benefit is just intellectual masturbation, but worse as you are wasting the business' money doing it.

So look at the business model, look at the business services and think

"If I had half the budget what could I do and what would really have an impact"

Then look at the saving areas, look at SaaS, look at outsourcing and mainly look at how you measure and reward people to cut costs. After that think about the top line

"Now that I've saved that 50%, where can I invest 25% to drive the company upwards"

That is where you look at impact and look more at modern technologies and approaches.

To do this you have to shift your mind out of IT for a bit and look from the business side. Use your experience and knowledge to frame the approaches and answers but don't forget that the goal here is for the business to be driving.

Business SOA is hard, it requires a real breadth of skills, this isn't delivery to PowerPoint its delivery to live. The business doesn't want to drive a video game, its a real business and it needs a real solution.

Technorati Tags: SOA, Service Architecture

Tool and reality blindness

There are ways of developing robust distributed applications that don’t require code-generation toolkits, piles of special code annotations, or brittle enterprisey frameworks.


Is the view of Steve Vinoski. Its a general rant against RPC (its really really bad BTW) and in praise of the wonderful programming language renaissance we’re currently experiencing.

Ummm I'm finding it really hard to think of something that doesn't require code generation as this is what any compiler does and as for "special code annotations" that is exactly what all "higher order" languages are about rather than the register shifting and low level elements of assembler and as for the brittle enterprisey frameworks... we all know how brittle the likes of SAP, Oracle and IBM mainframes are let alone the J2EE and other application servers that power the worlds largest industries and indeed the world economy.

Its really rather sad when people get Technology fundamentalism and think that a technology shift represents a genuine silver bullet.

One size doesn't fit all and no technology change will get IT out of this current mess. People have built robust distributed applications for years even decades which suggests that maybe this current trend isn't the only way of getting things done.

Technorati Tags: SOA, Service Architecture

Change is where the technology isn't

Over the past bunch of years I've seen a consistent thing about SOA "change" programmes, namely that they actually look at only two things.



The green bits on the slide, the technology and the IT architecture. Sometimes the architecture change is only aspirational and its a focus on the technology alone. The point is that the real change is in the purple and blue bits. This is where change actually matters. For an IT organisation to transform itself it needs to really change the purple element and shift away from a technology focus and towards a business focus. This change will have a greater impact on the success of the IT architecture and the technology than any change that is made lower down.

For a business to really capitalise on SOA it needs them to treat SOA like a successful ERP programme, namely to think of the business change needed to leverage the new solution.

If you are focusing on the green bits then all you are doing is an implementation project not a real change programme. Change means changing the way you work, not just the tools that you work with.

Technorati Tags: SOA, Service Architecture