Creating Sound and Credible Strategies for your Integration and SOA programs

I’m not really surprised to see the love-hate relationship between senior executives who own the integration portfolio and the ‘strategy consultants’ in my observation. Its love-hate dynamics because on one side where senior IT leadership strongly believes that a ‘strategic’ view is needed for creating the reliable roadmap for their initiatives, at the same time, there is really no reliable methods today to evaluate the appropriateness of the so called ‘strategy’ deliverables that consultants deliver. From the observation of the legacy in the enterprises I worked with, I find something very fundamental missing in those mysterious and high-end strategy documents: ‘Life’. Lack of life means that these strategies are more or less used as ‘initial requirements’ for certain programs/initiatives and as time progresses, strategies are not updated/maintained in line with changing state of the organization.

I have not seen too many of ‘good’ strategies in as far as integration/SOA is concerned for many large enterprises. So I thought I will put together a perspective on creating sound strategies for integration/SOA portfolio. To start with, I would like to share my view on what I found lacking in the strategy documents that I reviewed/audited for my clients:

• One of the big disappointment has been the ‘lose’ purpose and meaning of the strategy. Many of the strategy documents didn’t give me confidence if they had been developed being so particular about ‘strategy’ as such. So people who developed the strategy deliverables may have not paid attention what’s really needed in a strategy and might have limited the strategic view to just few principles/vision statements. It is quite evident when I see plethora of basic introduction to fundamental concepts like EAI/SOA/ESB/Architecture patterns etc in the strategy document. Will talk about it more in the next bullet.
• Next big issue I found in the strategy documents that really distracted the whole purpose of the strategy document. I find many of these strategy documents providing huge documentation around technical concepts, product capabilities etc and even the architecture blueprints in some of the cases. In my view, architecture blueprints and design guidelines need to be looked as separate elements and not mix them up in the strategy. Prime reason is that it dilutes both the purposes, strategy as well as architecture.
• Another key aspect that is critical for sound strategies is the clear understanding of the elements that drive and influence the strategies. I found it very difficult to figure out why a particular strategy was the ‘right’ strategy for the organization. Strategies need to be driven by the well defined drivers (like IT strategies, existing challenges) and the expected strategic results where number of strategic options need to be evaluated to arrive at a strategy that sounds ‘better fit’ for the organization.
• Almost in all the cases, I didn’t find any significant focus on the ‘strategy implementation’. Strategies were written mostly like ‘knowledge documents’ where implementation was not much of concern. So while strategies were interesting to read, my discussions with document owners revealed that organization really struggled to figure out how to implement these strategies and as result, most of the strategies kept sitting in the document only and find their way to real-life.
• Again, almost in all cases, there was no consideration of impact of these strategies on the enterprise and no aspects of ‘readiness’ of the organization to be able to roll out these strategies. I don’t find such strategies very ‘real’. Point of strategy is not to gamble but to strengthen the chances of success.

List doesn’t end here but let me stop here. If I were to suggest how integration strategies need to created for the enterprise, here is what I will recommend to be considered in the strategy formulation based on my experience:

• Team that is creating the strategy should not look at the strategy articulation as a template that need to be filled. If that is how it is being done, that’s first sign of the disaster. Team needs to clearly understand the ‘strategy engineering’ process where set of information (like vision, issues, expected outcomes etc.) are taken as input, processes and based on certain hypothesis, strategy formulation needs to happen.
• As I said, strategy starts with getting clarity into what is driving the strategy. It helps defines the goals that need to be put forward as a ‘result expectation’ for the strategy. For example, enterprise could say that one of the key goals of the strategy should be to reduce the our TCO by 10% in 12 months.
• Team needs to consider the major influencing factors for the strategies that could be recommended. To arrive at such factors, SWOT analysis of the integration portfolio is must. Further to that, team should consider the possible scenarios that the strategy implementation could be facing and from there analysis must bring out how these strategies are anticipated to perform in those scenarios. This will help kicking out the strategies that sound exciting but can’t perform to the results in most realistic scenarios.
• Before strategic options are identified, we must identify all the strategy areas/themes where strategies need to be built. For example, for integration portfolio, it could be Architecture/Technology, Service Delivery model, Sourcing model etc.
• While formulating the strategies, there are 3 elements that need to play a role in defining a credible strategy. First: Input – something that is given and cannot be changed. Second: choices – to meet the objectives with what is given, what strategic options are available. Third : Action – how selected strategies need to be deployed.
• Once set of strategies are defined, a prioritization needs to happen based on the feasibility. Input of scenario performance of the strategies will be a good input.
• It is very important to analyze and details out the impact of the strategies on the exiting eco-system of the organization. That makes the strategies real and practical.

Unlike technology and architecture, unfortunately we can’t have one standard solution for strategies. That makes it very vulnerable for enterprises in terms of their ability to judge a strategy. But I also believe that process of strategy development itself in many ways a revealing and learning experience both for the client and the consultants. Hence in area like integration where strategy may not have been playing so much critical role so far, it must be taken very seriously as move in the next-generation enterprises. I would keen to know how my experience aligns to other practioners in field. So drop your view-points on this topic if you are here.

'What Next' for Integration Competency Centers? - Part 1

Factually, that’s the not the most popular question being asked by my clients so far. Potential reason could be that most of the enterprises are still catching up to establish an operational competency center capability. ‘What next’ has been the idea that I have been tossing every year in my mind since last 8 years as far as evolution of competency center is concerned. And I’m sure same had been cases for many more analyst and consultants across the globe. This global appetite to discover ‘what next’ and to materialize it in real life has helped the industry to progressively evolve a concept like Integration Competency Center. Result is that while 8 years back we were exploring the concepts of ICC together with our clients, 5 year back we were driving our clients into ICC and some of our clients were driving challenging ICC designs from us and in recent 2-3 years to our deep satisfaction clients have been demanding transformation to superior ICC designs and we are stretching our abilities/innovation to meet the demands. I believe that global economic dynamics that we are seeing today will soon start pushing the enterprises in medium to long term and in turn driving consultant like us toward ‘what next’ very seriously. So that’s about why I’m writing about it. I will be running a series of blogs on this topic to cover the end-to-end story over a period of time.

Let us come back to this ‘what next’ for Integration competency Centers. Integration competency centers that exist today are varied in their service capacity as well as organizational positioning. These competency centers are somewhat centralized body of service groups with a charter of providing services required for enterprise integration. This group has good subject matter and technology expertise to be able to service enterprise integration specific requirements. Most of the basic processes and guidelines are in place that are used by this factory (another way of looking at ICC) to operationalize the integration life-cycle functions. These competency centers are able to meet the scale and demand of business with good service level performance. So what’s up for these competency centers as next big thing that they are going to transform to?

So as I see, there are set of next-generation views on the horizon:

1. Next generation competency centers will make it lot easier to execute and manage the changes than how it is today. That will transform the role of 'change' from 'threat' to 'opportunity'.
2. High degree of collaboration of the ICC across stakeholders that allows more transparency in the engagement and leads to co-creation of methods of delivery/operation of ICC with stakeholders like business units, application teams etc.
3. Though current ICCs are operational but there is good likelihood of presence of what I call 'eco-system fat' that makes the entire ICC as a organizational system slower, less effective and costly to improve. With current acute economical cost pressures, a system like ICC will need to reduce this fat significantly by adopting lean methods in terms of people, processes, systems etc.
4. Another important shift that can be bring into ICC is clear identification of value added functions and 'operational' functions. This will help, one to automate, standardize and accelerate the operational functions; second it will give opportunity to channel the investments, thought leadership and innovation effort more toward value added functions. One of the strongest feature of such ICC will be availability of 'self-service' capabilities in many facets of the ICC
5. Many of the ICCs don't leverage high-maturity sourcing models. Next-generation ICCs have opportunity to create strong sourcing model to leverage the strengths of SI vendors and drive focus of in-house staff toward more value added contribution. In essence, engagement model of sourcing will shift to 'outcome driven' and not 'activity-driven'.
6. Gainful utilization of the social networking systems like Facebook, LinkedIn, Blogs etc. has huge potential to change the face of knowledge management in the ICC.
7. 'First-time Right' effectiveness will become important to ensure that wastage in rework and 'fixing' that should not have been in very first place becomes an important metrics in the ICC.

Now, while these changes might be exciting, they are not very easy to come by. I will start getting into details of these in subsequent blogs. Meanwhile, if readers believe in another other next-generation changes for ICC, I will be glad to hear about that and possibly include it in my subsequent blogs.