Old for New

So, as I settle into my new role, I realise that along with the tag of "one of the UK's oldest companies" comes "some of the uk's oldest technology"! At some stage within this organisation, there was (probably) a rather unspectacular falling out between the Business and IT. The fall out from this situation was a proliferation of point solutions, procured by business users wanting automation and supported by IT people wanting to be left alone (to sulk).

The sheer volume of Access databases (actually, I came across five critical line of business apps running on FoxPro ver 2.6b, non-networked, users share data via floppy disks!! For you youngsters, they're like CD's or DVD's but smaller and less shiney!) and cheap , unreliable custom apps, developed by Chuck in Dallas, prevents anyone from thinking about a refresh strategy simply because no-one wants to have a 5 year long headache (and that's just from considering the data migration strategy).

When we look at the lack of adoption of TRUE Enterprise Architecture (i.e. a representation of a business combined with a realisation of technology produced by the business and owned by the business, NOT a bunch of documents and processes written by Mister Anonymous and owned by Mister Nobody) it is easy to see why, with so many wrongs to right within the technology estate of a large organisation, EA is either overlooked ("we have a 38 year old mainframe application which runs our core line of business functions! We need to replace that, not draw pretty pictures of what we all know!") or seen as "nice to have" ("Yes Archie, we can see you have a point but the Head of IT and the CEO are meeting to discuss outsourcing all support functions and I'm not sure they will want to see your pretty pictures!"). Cynical I know, but this is the crux of the issue. EA is owned by the business! Managed carefully and invested properly, it quickly becomes the realisation of a business strategy. All the technology headaches are eased by having a clear business model / case from which to build systems and solutions.

There is another twist to this folly that has emerged; the proliferation (ooo, twice in one posting) of consultancies who have risen to explain the complex phenomenon that is EA! We now have so many methodologies that it is almost like starting over! You would think that these consultancies have smelt the cash to be made out of confusion and complexity.

Without the slightest hint of cynicism, I say:

Surely not!

New Role

My new role is within the Architecture team of one of the UK's oldest companies. Thank the lord a movement has already been made towards the adoption of Enterprise Architecture. Work is underway on producing a reference architecture along with the modelling of business processes etc. The organisation has a typical IT legacy and has adopted many forms of technology to address ill defined business need. On the surface, business satisfaction with IT performance and agility is poor however, acceptance of joint responsibility for the state of affairs is reasonably good. It will be interesting to see how the adoption of structured thinking and strategic solution delivery over the coming months affects this position.

I will keep you posted!

New Horizons...

I am set to leave my current workplace for pastures new. As always, I'm looking forward to a new challenge and am fervently hoping that I go to an organisation which believes in the benefits of structured thinking and wants to change the 'no time to think, less time to plan' culture that dogs IT within organisations. I am always optimistic at this stage, however, generally, I find that organisations are very much alike across the board and EA gets little more than lip service from senior managers.

Sharing

It does seem to me that there is no real EA community. We all know the poential of EA, and the benefits therein, but apart from a few, I have to say, very sales focused offerings in this area (not mentioning any names) there is no real EA oracle. Where are the communities of practice? Where are the online resources?

To quote Pink Floyd, 'is there anybody out there'? Or, am I missing some great resources out there on the ether?

Answers on a postcard please or post a comment on this blog!

Lack of Confidence in Enterprise Architecture

I don't know about other sectors but, I find it amazing that within some professional services and government sectors that IT consumers and deliverers alike find it much more accecptable to invest time and money in citing the failures of similar organisations in support of their next project i.e. site visits, references, research etc. rather that actually finding out how the operations of their own organisations are conducted.

Is it just the UK that suffers from this lack of insight. You know, that British Scott of the Antartic philosophy that nothing can be properly achieved without great hardship etc.

My advice, ask your own business users what they do, when they do it, why they do it, who they do it with.........

You know the rest!!!!!

Neglected

Sorry world, I have really neglected my blog! I could have been a contender, I could have changed things, made business users see that it is the way they work that is wrong not the systems we deliver!! But no.... What did I do? I went to the pub every lunchtime and after work. I know what you're thinking "that sounds like a splendid way to conduct yourself" and "thanks for the invite, can I join you next time" but drinking copious amounts of alchohol and talking rubbish is not going to get me an entry in Wikipedia is it? I am wracked with guilt as I was browsing the web today and saw a link to this blog!!!! Oh the shame, last updated over six months ago!

I promise that I will concentrate more on waffling on about Enterprise Architecture and less time in the bar! Ok, just a quickie then, seeing as it's your round!

How to Implement a Large Scale Portal Solution

DO your analysis before you decide on a product / solution / concept. So many organisations say "we need a Portal!" without actually finding out if they actually do. I have been involved in many Portal projects where at some stage down the line the organisation realises that what they actually need is good CMS and KM or Enterprise Search Solution.

DO find out how your users work! Many Portal projects fail because IT deliver their "best guess" of what interface a user requires. Sit down with key users and establish what their typical journey is through the multitude of systems interfaces.

DO get a dedicated Portal team organised! When it comes to implementation time, expand this to become a virtual team which includes all of IT and relevant business representatives.

DON'T aim to implement everything at once. The 'Big Bang' approach DOES NOT WORK. Don't just take it from me. The Internet is littered with Portal hard luck stories from those who tried and failed to deliver everything.

DO break things into chunks. Levels of complexity within Portal projects are always high. Abstract this complexity by using work streams or even separate projects.

DON'T promise too much. Portal projects are plagued with 'blue sky' promises.

DON'T treat a Portal implementation as an ordinary project. Portals deliver fundamental changes in the way people work, it is not just another application, it is the road to a single application interface. Treat it as such.

DO market the benefits of the solution. Establish clear business benefits for each phase / work stream, believe me, it will help you in the future. Portal projects regularly 'disappear up their own arse' because by the time they are delivered, no one can quite put their finger on why they wanted one in the first place.

DO use Enterprise Architecture to define what you have already AND what you plan to have.

DON'T expect your users to undersand the interface just because you do! Those close to the project naturally find using the Portal easy. Users will have a much different experience. If you can afford it, hire an interface design specialist and get them to justify and document every piece of functionality in plain English. Include this in a context sensitive help application.

DON'T implement features just because you can. Establish a business case with clear and concise benefits for every application then implement them as separate projects within individual business and technical application owners.