Placing Your SOA Bets: Making Architecture Initiatives More Than Just a Gamble
Reading this great post the other day spurred me to blog about the 'SOA lottery' that seems to be all too common.
I don't think I've ever met a decent project or delivery manager who would take on a remit without knowing what it took to be successful at it. However, in IT strategy and architecture the opposite can often be true. Once intellectually wedded to the elegance or abstract value of a new approach or principle it seems that for some the architectural approach itself becomes the goal, rather than just a means. And in many cases, the 'remit' to make this happen is taken on blindly. And by implication, without knowing what it will take for an initiative around it to be successful. It becomes almost a gamble ... will it pay off ... will it work ...
I don't believe that it is knowledge of the technologies or standards that is lacking, and it's not knowledge of the architectural frameworks or methods that is lacking either. It is a lack of knowledge of what it takes for an architecture or strategy to be perceived as being successful by all the people whose role is affected by it, or who otherwise have an interest in it. Without this it won't actually deliver anything. It will just be a good idea. And as one of my clients had on their whiteboard last week - good ideas + no results = bull....
Look at SOA for example. Even when its value is defined well (and that is rare) it is still not equally valuable to every type of project or requirement. In addition it changes the game for various IT and business people who probably don't care much about architecture. For example, IT operations, IT project delivery management and IT business relationship stakeholders to name just three. It introduces new processes, risks and dynamics into their roles that change the way they need to behave, and what they will need to prioritise.
Anybody who's been involved with traditional IT-enabled business transformations will recognise that stakeholder and change management are two of the most critical activities in making the initiative successful. However good the objectives of the project, or however clever its design, without stakeholder and change management it will not be a success. Without participation from the stakeholders it won't be delivered successfully, and without transformation of the working practices it won't be used successfully.
And yet it's actually more complex than that for an architecture initiative such as one based around SOA to be successful as the value proposition applies across programmes, rather than within one. For them it isn't about a 'direct' business case (like most business transformation programmes) whereby the cost savings or new functionality delivered by a project realise the value proposition. Instead with these types of architecture initiatives the value proposition is indirectly delivered through the effect it has on other projects, or more accurately the effect it has across an organisations portfolio of projects, systems and technologies.
Of course this makes the success of such architecture initiatives dependent on stakeholders who are not architects, and whom likely do not appreciate the ways that the architecture will affect what they do. Moreover, they will probably resist the way it will likely affect their own initiatives' business cases.
Rather than make this post longer I'll blog separately on stakeholder and change management for architecture initiatives, but a good start is to consider which horses to bet on so that the chances of success are maximised. The key question there is where the architecture style (e.g. SOA) is independently valuable, where is it marginal, where it can be used implicitly, and where it's positively unjustified. This needs to balance the conceptual strategy viewpoint that IT architects are often strong on, with the pragmatic viewpoints of the delivery stakeholders, the maintenance stakeholders, and the business ownership experience.
On that topic I was interested to see Nick Malik's recent post on 'JABOWS' that suggests it is to do with which business process the solution is related to. In particular how often the business process in question occurs, and how often it changes. I like this model but I'd suggest there should be a couple more variables beyond these first two to give the level of practicality that can help you differentiate and plan - but it's far from an exact science at this stage.
Without meaning to overuse the gambling analogy, I believe that knowing this is the key first stage to placing the right SOA bets in an organisation. And as if by magic (!) it's also the topic of a session I'm running at the Open Group's Enterprise Architecture conference in Paris on 24th April - I'd welcome any views of what would be the most important aspects to work on.
Technorati Tags: Enterprise IT Enterprise Architecture EA Service-Oriented Service Architecture SOA Open Group The Open Group Open Group Paris 2007
I don't think I've ever met a decent project or delivery manager who would take on a remit without knowing what it took to be successful at it. However, in IT strategy and architecture the opposite can often be true. Once intellectually wedded to the elegance or abstract value of a new approach or principle it seems that for some the architectural approach itself becomes the goal, rather than just a means. And in many cases, the 'remit' to make this happen is taken on blindly. And by implication, without knowing what it will take for an initiative around it to be successful. It becomes almost a gamble ... will it pay off ... will it work ...
I don't believe that it is knowledge of the technologies or standards that is lacking, and it's not knowledge of the architectural frameworks or methods that is lacking either. It is a lack of knowledge of what it takes for an architecture or strategy to be perceived as being successful by all the people whose role is affected by it, or who otherwise have an interest in it. Without this it won't actually deliver anything. It will just be a good idea. And as one of my clients had on their whiteboard last week - good ideas + no results = bull....
Look at SOA for example. Even when its value is defined well (and that is rare) it is still not equally valuable to every type of project or requirement. In addition it changes the game for various IT and business people who probably don't care much about architecture. For example, IT operations, IT project delivery management and IT business relationship stakeholders to name just three. It introduces new processes, risks and dynamics into their roles that change the way they need to behave, and what they will need to prioritise.
Anybody who's been involved with traditional IT-enabled business transformations will recognise that stakeholder and change management are two of the most critical activities in making the initiative successful. However good the objectives of the project, or however clever its design, without stakeholder and change management it will not be a success. Without participation from the stakeholders it won't be delivered successfully, and without transformation of the working practices it won't be used successfully.
And yet it's actually more complex than that for an architecture initiative such as one based around SOA to be successful as the value proposition applies across programmes, rather than within one. For them it isn't about a 'direct' business case (like most business transformation programmes) whereby the cost savings or new functionality delivered by a project realise the value proposition. Instead with these types of architecture initiatives the value proposition is indirectly delivered through the effect it has on other projects, or more accurately the effect it has across an organisations portfolio of projects, systems and technologies.
Of course this makes the success of such architecture initiatives dependent on stakeholders who are not architects, and whom likely do not appreciate the ways that the architecture will affect what they do. Moreover, they will probably resist the way it will likely affect their own initiatives' business cases.
Rather than make this post longer I'll blog separately on stakeholder and change management for architecture initiatives, but a good start is to consider which horses to bet on so that the chances of success are maximised. The key question there is where the architecture style (e.g. SOA) is independently valuable, where is it marginal, where it can be used implicitly, and where it's positively unjustified. This needs to balance the conceptual strategy viewpoint that IT architects are often strong on, with the pragmatic viewpoints of the delivery stakeholders, the maintenance stakeholders, and the business ownership experience.
On that topic I was interested to see Nick Malik's recent post on 'JABOWS' that suggests it is to do with which business process the solution is related to. In particular how often the business process in question occurs, and how often it changes. I like this model but I'd suggest there should be a couple more variables beyond these first two to give the level of practicality that can help you differentiate and plan - but it's far from an exact science at this stage.
Without meaning to overuse the gambling analogy, I believe that knowing this is the key first stage to placing the right SOA bets in an organisation. And as if by magic (!) it's also the topic of a session I'm running at the Open Group's Enterprise Architecture conference in Paris on 24th April - I'd welcome any views of what would be the most important aspects to work on.
Technorati Tags: Enterprise IT Enterprise Architecture EA Service-Oriented Service Architecture SOA Open Group The Open Group Open Group Paris 2007
posted by Sam Lowe at
10:37 pm
0 Comments:
Post a Comment
via Haloscan
<< Home