Breaking Down the Walls: For Business-IT Alignment you need Joint Business-IT Teams!
What is required to drive the much sought-after and much talked-about Business-IT alignment? Not an easy question of course as it includes many aspects including organisational, governance, skill-set and architectural factors. But one factor that is part of the answer and I often find gets under-played is something much softer – the way that IT works (or doesn’t work) with the business in the early phases of their business change analysis and design exercises.
I spend quite a lot of time working with the business strategy & business change practices of my organisation (a large business and IT consultancy), and it often strikes me that the challenges in getting the IT consultants of a large consultancy working effectively and harmoniously with the business consulting parts of the same organisation are uncannily similar to those in getting the businesses of our clients work with their own IT organisations.
Business and IT people don't naturally use the same language, they have very different ways of working and views of the world, and they can often view each other with scepticism. Above all, they like to stay in their own worlds and throw things over the wall to each other in the form of requirements, or specifications. But the trouble with this is that for many tasks it is an inherently broken model of the world.
For example, how can the business give you their requirements when they don't know what it is possible to buy 'off-the-shelf'? How are they able to say exactly what they want when they don't know what IT assets they already have that they can use, or what constraints in their IT they have that they should be aware of before they make decisions? And how can they do that design of the business solution required when they don't know more than the superficial systems, data and infrastructure implications of any design decisions they make?
In many cases, decisions made early on with just isolated input from the line-of-business that havn’t involved the party (IT) that is required to progress the design into something that can actually be realised, are building on sand. The later engagement can uncover that the solution put together is actually not optimal after all, or that it is even not viable as a solution. Of course it’s rather embarrassing for all involved to have to rake up decisions made, to reset the communications to all the stakeholders who’ve been led to believe something else, and to revisit the business case that’s been put together on dodgy foundations. This can actually deepen the divisions between the business and IT, with IT feeling hard-done-by that they weren’t involved earlier and generally under-appreciated, and the business thinking that IT is just being awkward again and that they are ‘the tail that is wagging the dog’. So maybe as Dave Welsh has been quoted "The business is from Mars and IT are from Venus" after all and we should all just get used to it?
But this is a fundamental discontinuity of modern business-IT engagement that can further harm an often not ideal relationship, and it's totally unnecessary. Working together and communicating earlier and better can totally avoid it. So why don’t they do so? I guess that the business do not want to involve IT as they think that they don’t add to the business solution, that they focus on technical issues and factor that are irrelevant, unimportant or inappropriate to the task at hand. Fundamentally that they think that they are 'supply-side' focused (on how you build or provide IT solutions), rather than 'demand-side' focused (on how you maximise the value to the business and the wider enterprise).
IT are culpable in this as well as they (probably for fear of being over-exposed or investing their time in something they are not an expert in) often seem to want the business to get their requirements straight before they tell IT what they are (over the wall they come…). Maybe the feeling is that IT have enough to deal with without trying to work from changing requirements. Sometimes it almost seems that IT suspect that the business might try to dupe them, or somehow make them look silly so that they can criticise them more about how they don't deliver. So they seem to react by asking for absolutes, for guarantees, for an audit trail that they can point to later and say "this is what you asked for". But this attitude will always keep those that have it from the top table; how can they move from being a simple service provider, to actually being a key partner of the business with this culture and attitude?
And this is related to where the old-fashioned IT business analyst (BA) role is limited in this regard. Its shortcoming as the sole face-off to the business in design is that the BAs are great at gathering requirements and flushing out micro-level design issues, but they (mostly) don’t have the breadth and depth of knowledge of systems, data, and technology to do collaborative design. It just ends up being requirements capture, which is fine (indeed it’s required), but it’s not all that’s required. There are also issues with relying on IT project managers or particular packaged-application specialists alone in this capacity as well because of their limited breadth of knowledge and strong ‘supply-side’ delivery mindset.
In my experience by far the best solution is to use enterprise architects to bridge this gap and lead the multi-discipline IT team within the business' own early-stage pieces of work. These are not technical architects, systems architects or data architects (although they, like the IT PM or application specialist, may all have a subject matter expert role to play at this early stage), but enterprise architects who have the breadth of knowledge across all the domains needed and the business focus required to add the right value. This business-focus is needed so as to not fall into 'IT speak', or leap to an inappropriate level of detail, or to focus on what technology they're interested in as an individual (all of which cause business people's eyes to glaze over very quickly). They also have the experience of what the common implications of key big-picture design decisions are, and they have the best overview of what is available 'off-the-shelf' or in the existing assets. Finally, they critically have a methodology whereby they can pull in the necessary specialists as they are required, all under a common business-focused framework to ensure you get the right content, but in a way that is coherent and relevant to the business at this early stage.
These concepts when applied to these early-phase business change discovery and design exercises can involve just the right amount of 'down-stream' expertise in the appropriate 'upstream' activities, which maximises the likelihood that the right solution is put together, that it is appropriate, that it is also strategic to the enterprise, and above all that it and its business case are realisable.
(This is all in addition to a massive increase in buy-in and stakeholder-acceptance from having involved all parties in the definition of, and therefore to some degree the ownership of, the solution. It is my experience that there will be far less unnecessary re-questioning and general mud-slinging 'down-stream' if they're already on-board and knowledgeable about what's coming down the pipeline.)
Within the large consultancy that I work for, solving this problem so as to be able to offer joined-up early-phase business and technology services to our clients works really well (even if it hasn't always been easy), and I believe it should also be the de facto approach for the businesses and IT departments of our clients. In fact I believe it will become even more important in the new world of Service Oriented Architecture (SOA) as an enterprise service in your SOA is of vastly more value and significance if you can genuinely say that it as been collaboratively designed between the business and IT and is both relevant and useful to both.
So it's actually very simple, whilst it's not the only thing you need, if you want to work towards business-IT alignment, you're always going to need good business-IT collaboration, and the best way to achieve that is to break down the walls and use joint business-IT teams. It seems so obvious when you describe it like that.
Technorati Tags: Enterprise IT Business-IT Alignment Business IT Alignment Enterprise Architecture SOA IT Excellence Business Relationship Management
I spend quite a lot of time working with the business strategy & business change practices of my organisation (a large business and IT consultancy), and it often strikes me that the challenges in getting the IT consultants of a large consultancy working effectively and harmoniously with the business consulting parts of the same organisation are uncannily similar to those in getting the businesses of our clients work with their own IT organisations.
Business and IT people don't naturally use the same language, they have very different ways of working and views of the world, and they can often view each other with scepticism. Above all, they like to stay in their own worlds and throw things over the wall to each other in the form of requirements, or specifications. But the trouble with this is that for many tasks it is an inherently broken model of the world.
For example, how can the business give you their requirements when they don't know what it is possible to buy 'off-the-shelf'? How are they able to say exactly what they want when they don't know what IT assets they already have that they can use, or what constraints in their IT they have that they should be aware of before they make decisions? And how can they do that design of the business solution required when they don't know more than the superficial systems, data and infrastructure implications of any design decisions they make?
In many cases, decisions made early on with just isolated input from the line-of-business that havn’t involved the party (IT) that is required to progress the design into something that can actually be realised, are building on sand. The later engagement can uncover that the solution put together is actually not optimal after all, or that it is even not viable as a solution. Of course it’s rather embarrassing for all involved to have to rake up decisions made, to reset the communications to all the stakeholders who’ve been led to believe something else, and to revisit the business case that’s been put together on dodgy foundations. This can actually deepen the divisions between the business and IT, with IT feeling hard-done-by that they weren’t involved earlier and generally under-appreciated, and the business thinking that IT is just being awkward again and that they are ‘the tail that is wagging the dog’. So maybe as Dave Welsh has been quoted "The business is from Mars and IT are from Venus" after all and we should all just get used to it?
But this is a fundamental discontinuity of modern business-IT engagement that can further harm an often not ideal relationship, and it's totally unnecessary. Working together and communicating earlier and better can totally avoid it. So why don’t they do so? I guess that the business do not want to involve IT as they think that they don’t add to the business solution, that they focus on technical issues and factor that are irrelevant, unimportant or inappropriate to the task at hand. Fundamentally that they think that they are 'supply-side' focused (on how you build or provide IT solutions), rather than 'demand-side' focused (on how you maximise the value to the business and the wider enterprise).
IT are culpable in this as well as they (probably for fear of being over-exposed or investing their time in something they are not an expert in) often seem to want the business to get their requirements straight before they tell IT what they are (over the wall they come…). Maybe the feeling is that IT have enough to deal with without trying to work from changing requirements. Sometimes it almost seems that IT suspect that the business might try to dupe them, or somehow make them look silly so that they can criticise them more about how they don't deliver. So they seem to react by asking for absolutes, for guarantees, for an audit trail that they can point to later and say "this is what you asked for". But this attitude will always keep those that have it from the top table; how can they move from being a simple service provider, to actually being a key partner of the business with this culture and attitude?
And this is related to where the old-fashioned IT business analyst (BA) role is limited in this regard. Its shortcoming as the sole face-off to the business in design is that the BAs are great at gathering requirements and flushing out micro-level design issues, but they (mostly) don’t have the breadth and depth of knowledge of systems, data, and technology to do collaborative design. It just ends up being requirements capture, which is fine (indeed it’s required), but it’s not all that’s required. There are also issues with relying on IT project managers or particular packaged-application specialists alone in this capacity as well because of their limited breadth of knowledge and strong ‘supply-side’ delivery mindset.
In my experience by far the best solution is to use enterprise architects to bridge this gap and lead the multi-discipline IT team within the business' own early-stage pieces of work. These are not technical architects, systems architects or data architects (although they, like the IT PM or application specialist, may all have a subject matter expert role to play at this early stage), but enterprise architects who have the breadth of knowledge across all the domains needed and the business focus required to add the right value. This business-focus is needed so as to not fall into 'IT speak', or leap to an inappropriate level of detail, or to focus on what technology they're interested in as an individual (all of which cause business people's eyes to glaze over very quickly). They also have the experience of what the common implications of key big-picture design decisions are, and they have the best overview of what is available 'off-the-shelf' or in the existing assets. Finally, they critically have a methodology whereby they can pull in the necessary specialists as they are required, all under a common business-focused framework to ensure you get the right content, but in a way that is coherent and relevant to the business at this early stage.
These concepts when applied to these early-phase business change discovery and design exercises can involve just the right amount of 'down-stream' expertise in the appropriate 'upstream' activities, which maximises the likelihood that the right solution is put together, that it is appropriate, that it is also strategic to the enterprise, and above all that it and its business case are realisable.
(This is all in addition to a massive increase in buy-in and stakeholder-acceptance from having involved all parties in the definition of, and therefore to some degree the ownership of, the solution. It is my experience that there will be far less unnecessary re-questioning and general mud-slinging 'down-stream' if they're already on-board and knowledgeable about what's coming down the pipeline.)
Within the large consultancy that I work for, solving this problem so as to be able to offer joined-up early-phase business and technology services to our clients works really well (even if it hasn't always been easy), and I believe it should also be the de facto approach for the businesses and IT departments of our clients. In fact I believe it will become even more important in the new world of Service Oriented Architecture (SOA) as an enterprise service in your SOA is of vastly more value and significance if you can genuinely say that it as been collaboratively designed between the business and IT and is both relevant and useful to both.
So it's actually very simple, whilst it's not the only thing you need, if you want to work towards business-IT alignment, you're always going to need good business-IT collaboration, and the best way to achieve that is to break down the walls and use joint business-IT teams. It seems so obvious when you describe it like that.
Technorati Tags: Enterprise IT Business-IT Alignment Business IT Alignment Enterprise Architecture SOA IT Excellence Business Relationship Management
posted by Sam Lowe at
1:03 pm
0 Comments:
Post a Comment
via Haloscan
<< Home