Recently I was looking at the stats for this blog from 23rd January to 22nd February and looks like most people are interested in SOA and a post where I was venting my frustration on WSE & MTOM has hit a sweet spot (must be a common problem).
Sunday, February 24, 2008
Interestingly the very day I blogged about lack of skills when it comes to Financial Modelling, Chris Potts over at CIO.com blogged about the importance of Scenario Planning; for those who are interested following are the links to that post.
Tuesday, February 19, 2008
In my work often I am asked to go in and setup Enterprise Architecture within organisation or help existing Architecture function. The sponsors of these projects tend to be CIO or Managers of Strategy and Architecture. In most of these engagements over past few years I have seen a consistent message being repeated over and over again. "We need Enterprise Architecture and there is no need for you to speak to the business while developing one." Some time they may have a sound reason; such as they have done lots of workshops with business already and don't want to repeat it or they have Business Process Improvement team in place who can supply most of the information.
It is when they make statements like "We can tell you all you need to know about the business; as our operational/business people don't know what they are doing" or words to that effect. It does surprise me in this day and age when most CIO's priority is greater Business to IT alignment they or their direct report can practice such disdain for a part of the organisation they are supposed to serve.
In my opinion some of this arrogance can be attributed to lack of common communication language and view point. Let me explain viewpoint before I delve into language issues.
IT like finance, human resources and other shared services interact with the entire organisation (wide viewpoint) rather than a department at a time. Business people working within a department want what is best for their department (narrow viewpoint). While shared services people who interact with multiple departments see the duplication of effort going on and feel frustrated by in-efficiency. All this can be eliminated by proper governance and management structure, the key here is trying to educate an average business user that their organisation is system with inter-connected parts. Now to the language question.
Most IT people like to live in a world of jargons, in which they find great comfort as it to some extent provides them with sense of belonging. IT is not alone in this sin; Defense Forces take great pride in conjuring up acronyms the length of a sentence that no sane person can ever hope to interpret. To some respect it is their way of weeding out anyone "not in the know" out of the conversation. IT Departments practice the same art quite effectively in confusing and bamboozling their business counterparts. Business on their part have held technology at an arm’s length and tolerated it as a necessary evil. There is rising awareness among business leaders on the strategic importance of IT and the impact it can have if used properly on bottom line growth.
Business deals in language of numbers; business scenario planning which then leads to business strategy is based on financial models. These complex financial models tend to answer questions like "should we expand into Asia what will be the impact on product development, sales staff and so on..". IT on the other hand tends to more visual and use complex diagrams (network diagrams, use cases diagrams, component diagrams..) to communicate their message. When most business people look at these diagrams they can’t comprehend how what the IT people are showing them will impact their bottom line growth or top line growth. The only way out of this debacle is for IT to understand and have the ability to present their models in numbers. Match IT investment decisions to organisations internal rate of return and so on.
Un-fortunately this trend has yet to catch-on, at least in Australia I see job adds for Enterprise Architects which calls out for experience in Microsoft .NET, Java, SAN technologies or MPLS networking. Never ever ask for the ability to read balance sheet or retain the ability to do financial modeling to match IT investment program to organisational investment parameters (it will be too much to expect business to learn IT's visual communication techniques as they are the clients IT is expected to serve). Till such time we will always have some form of divide between business and IT. I would like to close by saying there is a little ray of sunshine out there. Sometime back while speaking at BTELL conference I met Chris Pots who calls himself IT investment strategist rather than an Enterprise Architect, he shares some of the views expressed above.