What can ‘Agile’ tell us about how Business & IT could work together better?

I blogged recently about the need for joint collaborative business-IT teams in the early phases of business change or business transformation exercises. Anyone who's had exposure to IT software development will recognise similarities in the criticisms I made about current dysfunctional approaches to the criticisms of the old approach to software development, the so-called waterfall approach.

In this methodology of course, the requirements were gathered by one team before the analysis and design was carried out by another, before the development carried out by another, before the testing by another etc. It was real manufacturing production-line thinking about one group of specialists working in isolation on the task they have expertise in, before passing the work ('over-the-wall') onto the next isolated group of specialists.

It’s now well known and accepted that it never worked very well for IT software development and implementation. My feeling is that this is similar to the logic in my comments on how we need to now realise that a silo-based 'over-the-wall' approach doesn’t work well for business-IT engagement in business change design exercises either.

Of course in the software development world iterative, and more recently 'agile' methods have come into being as the dominant methods. Agile software development techniques are founded on principles like collaborative working, early engagement, iterative design and delivery, and frequent rationalised reviews. Good practices like this have demonstrated that they can help deliver more relevant software solutions that are (for example) more likely to achieve what was actually needed rather than what was initially thought to be needed, to deliver what was desirable to the user rather than the designer, and to deliver what was actually achievable rather than what was thought to be reasonable.

Now I'm not going to repurpose the word 'agile' here to my points on joint-teams, as many have borrowed that word for other domains already. But the commonaility in intention and concept is interesting. And even if (as some would point out) agile didn't really invent these concepts, for me it still illustrates some good practices that we actually need for Business-IT engagement approaches on a broader level beyond just software development.

Technorati Tags: Agile Business Relationship Management Enterprise IT

Sake, Astrophysics, and SOA?

My collegue Steve Jones has been on the sake again and has come up with the rather sci-fi concept of Dark SOA to explain how a lot of the hype and spin out there about SOA is simply not helpful to most of the people to whom it is addressed.

Technorati Tags: SOA Service Oriented

EA 2.0 vs EA 1.0

Brenda Michelson and James McGovern have recently blogged some thoughts as to what the next generation of Enterprise Architecture may hold. It's an interesting topic and one that I have also been working on recently with some of my colleagues, so here are a few of my thoughts as to what I believe 'good' should look like in the short to medium term.

Bad Old EA of the Past	Next Generation EA
Cost Centre	Self-Funding
‘One Best Way’ to do EA	Configurable, based on Desired Outcomes
Reactive	Proactive
Techies in ‘Ivory Tower’	Balanced Views to Release Benefits
Service-Provider Mindset (requirements-based)	Business-Change Mindset (collaborative engagement)
Defining & Evangelising the concept of SOA	Realising SOA (Business as Usual)
Mandating (or trying to!) the Solutions	Leveraging the Asset Base & Adapting

Technorati Tags: Enterprise IT Enterprise Architecture

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